As and when I get bored with SP3 testing and/or IDP4 deprecation (there's only so much fun one can pack into one day) I'm looking at
IDP-1217 . This is "Support for RequestedAttributes AuthnRequest extension" as per the spec .
Before we even get to the IdP I need to add the new stuff to OpenSAML (and that may be as far as we get for IdP 3.4)
The OpenSAML impact of the spec is two-fold:
1) A new element <req-attr:RequestedAttributes xmlns:req-attr="urn:oasis:names:tc:SAML:protocol:ext:req-attr" >
No problems here
2) a new attribute for EndPoint "req-attr:supportsRequestedAttributes" hence:
This is the one I could do with guidance on. Whilst my first plan was to introduce an EndPointEx Interface (with the getter and
setter for supportsRequestedAttributes); The wheels fall off this idea when you consider the cascade of derived interfaces which
would need to get the same treatment.
So my current plan, which I'd like confirmation of, is to add a new Interface ReqattrEndPoint (and probably make it extend EndPoint,
just for hygiene). Then the EndPointImpl (which we can change at will) can implement EndPoint and ReqAttrEndPoint), the marshallers
and unmarshallers follow suit.
I prefer this since it not only saves a mess of derivations, it keeps the extension separate from the core. The downside of course
is that the IdP then need to be aware that not all EndPoints are the same and do an explicit test and cast. But this seems a small
price to pay, furthermore I don't see that it would render the code less understandable. This would be code seadling with a special
case, so it would need to ask about the special case.
Also the new attribute is actually only interesting when you are doing the SP side of things (as guidance on whether you should send
the extension) so the whole "and the IdP gets a wee bit more complicated thing is a non-issue..
> So my current plan, which I'd like confirmation of, is to add a new Interface
> ReqattrEndPoint (and probably make it extend EndPoint, just for hygiene).
> Then the EndPointImpl (which we can change at will) can implement
> EndPoint and ReqAttrEndPoint), the marshallers and unmarshallers follow
You shouldn't need to do that, the base type should be attribute-extensible and just expose the additional optional attributes. I'm pretty sure that's all there already.
We don't generally bake in special support for extension attributes unless it's really warranted, and then I would probably just do it on the actual SingleSignOnService interface directly as a native feature.