Liberty ID-WSF Discover Servce Q/A

An interesting Q/A session about the Liberty Alliance's Liberty ID-WSF Discovery Service...

How would the Liberty ID-WSF Discovery Service (DS) be used for discovery of an Authentication Service (AS), rather than an identity service, as described in ID-WSF 2.0?

This would likely be accomplished by submitting a request to the DS (probably without a security token) and requesting the service type for the AS. For example, the following request could be used:

<disco:Query>
  <disco:RequestedService>
    <disco:ServiceType>urn:liberty:sa:2006-08</disco:ServiceType>
    <disco:SecurityMechID>urn:liberty:secuirty:2005-02:TLS:null</disco:SecurityMechID>
  </disco:RequestedService>
</disco:Query>

This would likely only be done when the client is built with the knowledge of thelocation of the DS and uses that to bootstrap to the AS. Other implementations have been built with the knowledge of the AS and used that to bootstrap to the DS.

I believe that typically the location of a principal’s DS is returned in an authentication response, e.g. as an attribute in a SAML assertion. If DS is to be used to discover the authentication service, how is it envisaged the location of the Discovery Service would be obtained in this context?

The client has to know (or get from the user) either the location of the AS or the location of the DS. In some cases you can get this from an SSO assertion which contains the bootstrap EPR, but that typically doesn't work for the LUAD WSC (e.g. a client running on a user's computer) case -- usually the client would have the knowledge of the location of the AS built in (DLink's radio service client for the AOL Radio Service worked this way).

Could DS be used to discover, for example, a SAML SSO service? If so, what would the service metadata registered with the DS for this service represent?

I don't know what is meant by a SAML SSO service. In any case, the metadata needed for any ID-WSF service is the same. For non-ID-WSF services we don't document what would need to be there so you would have to do it yourself. This might have interoperably issues with other ID-WSF and/or DS implementations that were not built to work similarly with non-ID-WSF services. For example, an ID-WSF DS implementation may require the <Framework> element within the service metadata since that is required by ID-WSF, but likely wouldn't be used for a SAML SSO service.

SAML does have it's own means for providing metadata about the SSO endpoint and I would recommend that the SAML metadata be used by SSO clients.

Who typically hosts a principal’s DS (where it is being used for discovering an authenticated principal’s identity services)? Is it the IdP that authenticates the principal, or some other entity?

In most cases, the IdP and the DS are very close and managed by the same party (although the DS can and have been hosted on different servers in some implementations).

Assuming a principal’s identity service (including DS) can be hosted by some entity other than the IdP that authenticates them, is there typically some mapping of identities between the authentication service and the identity service? If so, how is this normally achieved?

The IDP maintains a mapping of the principal's identities for all locations where that principal has federated their identity (and yes, an identity service provider for a principal (such as a profile service) is considered to have federated with the user's identity at the IdP).

Who typically maintains the service metadata registered with a DS? Who typically maintains the metadata/identity associations? How is access to these operations controlled?

The DS maintains the runtime copy of the metadata in it's internal database and provides administrative interfaces for the WSP to use to maintain their own metadata.  Access is controlled by the DS (in come cases with the user's consent).

Is there typically one DS endpoint for all principals, with the identity of the principal being specified in the SOAP header? Can the endpoint be different for each principal? (Is this what the ‘Via the endpoint’ bullet point in 1.1 of the spec is saying?) The same question for identity services other than DS.

There's two areas to address in that question. First off, there can be many DSs (even one for each principal) and likewise there can be many different instances of the same type of identity service (e.g. profile service). Within a given DS that is serving many principals, the DS may use a single endpoint address for all request (typical) or may use endpoints for groups of users (some basic form of load balancing).  We recommend against using individual endpoints for each principal as this has a tendency to leak information about the user (and can permit correlation if the same endpoint is provided to multiple service consumers).  The specifications allow for the identification of the principal using the Target Identity value (specified in either the ws-security header or the TargetIdentity header -- see the ID-WSF Soap Bindings specification for details).

Assuming the endpoint for each principal’s instance of a given service can be different, how does a DS mint the correct EPR for a given principal?

I would not make that assumption and would strongly recommend against using an endpoint for each principal’s instance of a service -- you loose privacy benefits, you loose the manageability benefits of sharing the same service metadata across many principals. Instead, the service instance should use the information contained with the ID-WSF defined SOAP headers to identify the principal (and therefore the service instance).

However, if you really wanted to do this, you (as a WSC) would simply register a unique Service Metadata for each principal (containing the endpoint for that principal) and the DS would just use their normal EPR minting rules to make use of it.

Tags : identity / discovery / Liberty / id-wsf / Liberty Alliance / aol / dlink / authentication