...
Otherwise, the ECP client has to take the step of identifying where at the IdP it should send the WSP's request message, and how it should authenticate itself to that IdP. In ID-WSF terms, this means identifying the Single Sign-On Service endpoint at the IdP and the "security mechanism" it needs to use. There are essentially three possibilities:
Consume SAML Metadata
The client library could actually rely on OpenSAML to parse and load SAML metadata itself, presumably the same metadata consumed by the SP deployed with the Portal. Having done so, there are conventions for identifying the location needed using a md:SingleSignOnService endpoint with a Liberty-defined Binding attribute.
This does not address the problem of identifying the security mechanism, which could either be assumed, placed into a metadata extension of some kind, or the endpoint element could actually be extended to carry a complete "Endpoint Reference", which is a Liberty-profiled WS-Addressing construct that identifies both where a service lives and how to authenticate to it.
Extend SP to Supply Attributes based on SAML Metadata
The SP could in theory be extended to pull the information needed from the metadata as described in the previous option, and expose it as one or more attribute headers as with the user's own data. While there is precedent for this idea, coming up with a generic way to do this may be complex. The chief advantage is less work for the library, and no need to duplicate the metadata management the SP is performing.
Carry an Endpoint Reference in a SAML Attribute
We have settled on the following approach of carrying an EndpointReference The more typical approach to this problem in ID-WSF is to carry the aforementioned "Endpoint Reference" construct in a SAML attribute supplied in the SSO assertion. Liberty defines a profile for both expressing the endpoint information and it can be placed in an attribute with a well-defined name. The WS-Addressing element would identify the service (in this case the SSOS), the security mechanism to use, and would identify the security token to attach to the request by referencing the enclosing assertion.
The challenge here is that the IdP has to be able to generate that XML-valued attribute (not too complex, probably), but then the information has to be available to the client library. This means the library either needs to parse into the assertion to some degree and access the information directly, or the SP needs to do so on its behalf, leaving open how that information could be "flattened" into one or more headers in a sensible way.
Endpoint Reference Example
For reference, a typical EPR would look like this:
...
.
...