[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [wsfed] Issue PR001: Revise federation metadata document structureto eliminate ambiguities and improve interoperability
This is issue PR001. From: Don Schmidt
[mailto:donsch@windows.microsoft.com] There are ambiguities in the
definition of the federation metadata document structure in section 3 of the
current draft of the WS-Federation specification. Attempts to prototype
an STS configuration tool using metadata published by a federation partner have
indicated that these ambiguities are serious enough to prevent automation and
pose a significant risk to interoperability. Problem Statement Federation metadata is defined
as an XML document that contains elements which describe properties of
endpoints. These elements fall into two general categories: -- service instance elements used to identify a
physical instance of a specific type of web service (e.g. <fed:TokenIssuerEndpoints>) -- service capability elements used to describe a
property of a web service (e.g. <fed:TokenSigningKeyInfo>) Three service instance
elements (<fed:TokenIssuerEndpoints>, <fed:PseudonymServiceEndpoints>
and <fed:AttributeServiceEndpoints) can provide meaningful information in a federation
metadata document without any additional qualification. The remaining service
instance elements, and all of the service capability elements, do
not provide meaningful information unless they are associated with one of the
previous three service instance elements. However, the current
federation metadata document structure defines all elements as peers, and
provides no mechanism for associating them beyond grouping them in a single
federation metadata document section. This leads to the following
ambiguities. (a)
There is no mechanism to indicate the correct association if multiple service
instance and service capability elements exist in the same section
of a federation metadata document. For example, if a there are elements
for two different token issuing services and two different signing keys, there
is no mechanism to indicate which key is used by which service. (b)
There is no mechanism to indicated related service instance
elements. Some types of service instances must be related to
another type of service instance to be meaningful. For example, a
sign-out subscription service (<fed:SingleSignOutSubscriptionEndpoints>) element is not meaningful unless it is related to a
service that enables sign-on, such as an STS (<fed:TokenIssuerEndpoints>). (c)
There is no service instance element for identifying a generic Relying
Party service that is only a consumer of security tokens, attributes or
pseudonyms. There are only elements for identifying services that are
issuers. The federation section construct
allows a service provider to publish distinct metadata for each federation in
which it participates in a single federation metadata document. The FederationID attribute
is provided to enable partners to locate the correct metadata when configuring
federated relationships. The FederationID attribute MAY be included in security token requests to
specify the federation context in which the request is being made by the
Relying Party. (d)
There is no mechanism to coordinate the use of a consistent FederationID attribute
value between the participants in a particular federation. (e)
There is no mechanism for an Identity Provider to determine that a Relying
Party has the right to assert a specific FederationID attribute value in a service request. Proposed Solution These ambiguities could be
addressed by introducing additional structure in the existing WS-Federation
definition for federation metadata. However, this would partially
duplicate work that has already been accomplished in the Metadata for the
OASIS Security Assertion Markup Language (SAML) V2.0 specification
[Samlv2Meta]. The <md:EntityDescriptor> element appears to have most of the necessary properties
to address issues (a), (b) and (c). While the <md:EntitiesDescriptor> element appears to have the necessary properties to address issues
(d) and (e). Re-using the [Samlv2Meta]
constructs will simplify development, and improve interoperability, for parties
that must either implement or deploy products based on both the WS-Federation
and SAML protocols. Please see the attached document for details of a
proposal that will eliminate the existing federation metadata document
structure ambiguities by extending existing [Samlv2Meta] constructs to support
WS-* requirements. Note, the proposal only requires changes to the
federation metadata document structure. There is no need to change
existing mechanisms and protocols defined in WS-Federation for locating or
retrieving a federation metadata document. Key contributors to the SAML
standard have reviewed this proposal for technical correctness. They
verified that the proposed extensions to SAML metadata are consistent with the
schema of [Samlv2Meta]. They also have expressed their willingness to
make any necessary errata changes to [Samlv2Meta] and to foster cooperation
between the SS and WSFED TCs to ensure that this harmonization effort is
successful
Don Schmidt Principal Program Manager Microsoft Corporation 425-703-2655 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]