Page 1 of 2   next page »

Imagine a fresh business relationship between ACME Corporation and Partner. As a result of this relationship, ACME wants to grant Partner limited access to one of its core internal applications. They do this, naturally, by exposing a Web service.

Why Identity Federation?
Boris (an employee at Partner) sends a SOAP request to the ACME Web service along with some password or proof-of-possession type credentials. Because Boris's identity is managed outside of ACME, those credentials cannot be authenticated using ACME's authentication infrastructure.

To circumvent this issue, one could imagine a setup where the ACME Web service authenticates Boris's credentials by connecting to Partner's authentication services. Another alternative might involve some sort of directory replication. These strategies were attempted in the '90s when distributed LDAP references appeared in the protocol to try creating metadirectories.

Although most commercial LDAP directories have replication functionalities, these are not typically used to replicate authentication data across enterprises. For Partner to expose his authentication system to the outside world in any way is not an option: doing so would introduce major security and confidentiality issues.

Ideally, Boris's credentials must be authenticated in the confines of Partner's identity domain before the SOAP request is sent to the Web service. At the receiving end, the ACME Web service will not authenticate Boris's credentials directly; instead, it requires a satisfactory proof of authentication before letting Boris's SOAP request through (see Figure 1).

This mechanism where one entity delegates authentication and/or authorization to another entity is known as "identity federation."

SAML Holder-of-Key
SAML describes different scenarios that allow for identity federation. Let's first look at the holder-of-key approach (see Figure 2).

By now you may have heard of WS-Trust. WS-Trust defines the syntax that Boris uses to request a SAML Security Token. Simply put, Boris sends a RequestSecurityToken SOAP request to Partner's internal Security Token Service. The token service authenticates Boris's credentials according to its own policy and returns a RequestSecurityTokenResponse that includes the SAML Signed Security Token. So far, all of this is happening inside Partner's domain.

A SAML assertion can make different types of statements about a subject: Authentication Statements, Attribute Statements, and Authorization Decision Statements. In this case, Partner's Security Token Service will make an Authentication Statement regarding the subject of the SAML assertion: Boris.

The issuing authority digitally signs the SAML assertion, and this constitutes the basis on which trust is established. Boris binds this SAML assertion to his outgoing SOAP requests. He can reuse the same assertion for future SOAP requests as long as it remains valid (the validity of a SAML assertion is typically very short). The process of binding the SAML assertion to an outgoing SOAP message involves Boris's including the SAML assertion in the SOAP message's header and signing the message with his private key. The SAML assertion includes a SubjectConfirmation element that contains a client certificate for Boris's private key. In order for the receiving end to confirm that the message is sent by the owner of the SAML assertion, it will verify the digital signature of the message using the certificate that is part of the SAML assertion's SubjectConfirmation element.

This process prevents an attacker from sniffing the SAML assertion and using it to impersonate Boris. Similarly, an attacker would not be able to substitute his own certificate inside Boris's SAML assertion, because this would break the issuer's digital signature, and the assertion would become invalid.

Back at ACME, the Web service is configured to trust Partner's Token Service as an issuing authority. Practically, the digital signature that is part of the SAML assertion can be verified using the digital certificate of the issuing authority. The certificate of the issuing authority is what the Web service needs to be configured with to allow trust of the authentication claims and thus, identity federation with Partner.

At run time, the Web service verifies the signature of the SAML assertion, checks that it trusts this particular issuing authority, then checks that the message is received within the validity period of the SAML assertion, then verifies the signature of the message itself (Boris's signature), and finally, checks that the signature uses the same cert as the one specified by the holder-of-key SAML assertion.

SAML Sender-Vouches
The sender-vouches approach's main difference over holder-of-key is that the issuing authority also acts as the sender of the message to the Web service. Boris sends his message to an issuing authority, which also acts as a proxy by forwarding the message to the ACME Web service. In this case, the SOAP message is signed by the issuing authority directly and the receiving end only needs to validate one signer.

Flexible, Centralized Trust
In practical terms, the trust of an issuing authority will require the Web service to be configured with the digital certificate used to sign those SAML assertions. The Web service may also want to keep a list of remote subjects as opposed to blindly letting through any identity authenticated by the issuing authority. You may want to allow Boris through, but nobody else from Partner for now. Alternatively, you may want to federate authorization as you did with authentication so far (refer to SAML Authorization Decision Statements for more details). In any case, these implementation details of the Web service reflect the particularities of a real business relationship.

Back at ACME, a new business relationship may require establishing trust with a different issuing authority, which in turns necessitates a change to the Web service. Suppose there is a new partner (let's call him "Partner B") who uses a proxy-like approach and does not support SAML holder-of-key (only sender-vouches), and our Web service was expecting holder-of-key up until now. Boris may have left Partner for greener pastures, and his responsibilities have shifted to Maurice.

Such events necessitate maintenance on the Web service. Perhaps this means an unfortunate interruption of service. If ACME now exposes multiple Web services, each implementing its own trust and authorization management, any change to business relationships could require maintenance in each of these Web services. In addition to the interruption of service and the potential risk associated with any Web service changes, there is the issue of cost for each cycle of development, quality assurance, and deployment.

Still, just as business relationships are expected to change over time, so too will the implementation details of the Web service that pertains to trust and authorization - or will they? If trust and authorization are not closely linked to the Web service's application logic (as would typically be expected), then they should be abstracted out and handled by a centralized policy enforcement point.

By letting an XML gateway enforce the authentication and authorization rules, changes to these policies become an administrative task that does not require changes to the Web service, nor service interruption. Adding or removing trust of an issuing authority is but a mouse click away. XML gateways that support SAML-based identity federation transform software maintenance nightmares into security manager dreams (see Figure 3).

Page 1 of 2   next page »