Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Multiple endpoint references in a WS-Federation AttributeServiceEndpoint (20070612)
Recently Don Schmidt of Microsoft wrote that the inaugural meeting of the OASIS WSFED WG (charter) discussed
- "the need for standardized claim types and namespaces
- the relationship of WS-Federation to Attribute Services
- best practices for pseudonyms (logically a special type of attribute)"
Mr. Schmidt's post discusses what happens when a relying party requires attributes or claims which are not provided by the identity provider. A relying party could simply return a Fault indicating that one or more of its required attributes weren't provided. Additionally,
"...the target service can retrieve Federation Metadata from the [Identity Provider (IP)] that issued the requestor's token. This metadata can include an AttributeServiceEndpoint statement. If the interface to this service is implemented as an STS, the missing attribute could be obtained through explicit claims transformation using a WS-Trust OnBehalfOf RST/RSTR message exchange.
This discussion led to the observation that the STS model and claims transformation could be used to obtain claims from an attribute service, regardless of whether it was deployed by the RP, by the IP or by some well-known, third-party federation service provider. It appears that existing WSDL and WS-SecurityPolicy techniques, augmented with Federation Metadata documents, are sufficient to locate such federated attribute services."
The last statement is of concern, for while they may be sufficient to locate STS services, they are not sufficient to enable a target service to efficiently determine which or how many endpoint references it should contact to obtain the claims of interest.
According to the December 2006 specification of WS-Federation 1.1, the AttributeServiceEndpoint (defined in section 3.1.8) element of federation metadata includes a WS-Addressing endpoint reference of an attribute service issuer STS, along with its associated metadata (or a pointer to its metadata).
I mentioned the endpoint reference in a post last month on Service Modelling Language (SML), as SML depends on WS-Addressing (WS-Addressing has been in the W3C since 2004). The endpoint reference XML definition contains a wsa:Address URI, which is required to be in every endpoint reference. The endpoint reference also includes the optional elements
- wsa:ReferenceProperties: properties required to identify the entity; opaque to the application consuming the endpoint reference.
- wsa:ReferenceParameters: also assumed to be opaque to the consuming application.
- wsa:PortType: primary portType of the endpoint (port names are unique among port types in a single WSDL document)
- wsa:ServiceName: identifying the WSDL service element defining the endpoint (service names are unique in a single WSDL document)
- wsp:Policy: WS-Policy elements
Two endpoint references match as equal to each other if their address URIs match, and they have the same reference properties. Note that there is no unique identifier or other key to determine whether two endpoint references refer to the same server, as a server may have more than one address URI.
Unfortunately, a difficulty with the proposed use of the AttributeServiceEndpoint definition in WS-Federation 1.1 is, quoting the specification,
"It should be noted that this element MAY occur multiple times indicating different services or different endpoints at a common service." (emphasis added)
Flattening the matrix of services and endpoints into a single list is problematic, and not enabling the receipient of a federation metadata document to distinguish between "different services" and "different endpoints for a single service" suggests that a recipient would need to contact endpoints unnecessarily, and would not be able to determine whether it had received all available attributes if one or more endpoints are unavailable.
There may be multiple endpoint references if there are multiple URIs for a particular server. The server might be multi-homed, might be implemented by multiple clustered nodes with distinct domain names, or the endpoint references might have different transport security properties.
We addressed a similar issue in the definition of the continuation reference in LDAPv3. A continuation reference is returned to an LDAP client when it must progress a search operation itself, by contacting one or more other LDAP servers.
As discussed in Section 4.5.3 of RFC 4511, the continuation reference is returned to the client as a set of one or more SearchResultReference PDUs, and each SearchResultReference PDU contains a set of one or more URIs. The client needs to process each SearchResultReference. However, within a SearchResultReference, each of the URIs will provide the same LDAP result.
"If the client wishes to progress the Search, it issues a new Search operation for each SearchResultReference that is returned. If multiple URIs are present [in a single SearchResultReference], the client assumes that any supported URI may be used to progress the operation."