Scenario w/ WS-Federation to SAML 2.0 interop challenge for Danish public sector The following slides illustrates in a basic manner the technical/security challenge for establishing a gateway that can include WS-Federation based service requesters in a Danish public sector SAML 2.0-based federation. Note: The purpose of these slides is to illustrate a technical requirement. In addition, any Identity Provider must be able to fulfill requirements for mature processes, validation of users before issuing credentials. SLA’s etc, etc, to be part of the federation and thus enable the described scenario, but it is beyound the scope of these slides to discuss those requirements. It is also beyound the scope of these slides to discuss how to calculate the extra cost in adding and operating a gateway as well as how to distribute this cost to the partners in the federation Søren Peter Nielsen – 25. september 2006

Loginservice (IdP) Attribute Service Cert Auth Existing pin-codes uid/pw Service Provider - Citizen - Private employee - Public employee Login Web or Local network Danish public sector shared service requirements for maintaining integrity of users identity in a gateway scenario The above is one of the basic use cases for a Danish public sector federated identity concept. The SAML 2.0 standard is for many good reasons the preferred way to support this. However, there is a desire for a gateway function that also includes service requesters supporting only the WS-Federation specification as illustrated on the next slide. Service Provider SAML 2.0

Service Provider - Citizen - Private employee - Public employee Login Web or Local network Danish public sector shared service requirements for maintaining integrity of users identity in a gateway scenario The desired gateway should allow service requesters to enter the federation using the WS-Federation specification and then convert the WS-Federation supplied token (presumably a SAML 1.1 token as user attributes also should be transferred) to a SAML 2.0 token Service Provider - Public employee Login WS-federation w/ SAML 1.1.token SAML 2.0 Gateway WS-FED token  SAML 2.0 token

Service Provider - Citizen - Private employee - Public employee Login Web or Local network Danish public sector shared service requirements for maintaining integrity of users identity in a gateway scenario The issue for the gateway scenario is when the service provider requires High confidence in asserted identity's validity. This requires the assertion to be signed at the point of origin. However, even if WS-Federation allows for signing the SAML 1.1 token this signature cannot be maintained when being converted to a SAML 2.0 token Service Provider - Public employee Login WS-federation w/ SAML 1.1.token SAML 2.0 Gateway requires High confidence in asserted identity's validity requires Some confidence in asserted identity's validity

The problem is To allow external users access to person sensitive data Danish authorities requires High confidence in asserted identity's validity Current WS-Federation implementations like Microsoft’s Active Directory Federation Service does not support the SAML 2.0 token. Even if WS-Federation delivers a signed SAML 1.1 token the signature cannot be maintained during a conversion to the SAML 2.0 token format. Thus, even with a gateway option – service requesters using WS-Federation will still have to rely on other means for authentication when they want to access person sensitive data at other authorities – and thus goes the well-integrated login-experience down the bucket – Single Sign-On is not possible. This is because the gateway option only is able to deliver Some confidence in asserted identity's validity

Reference Brief explaining why Denmark in spring 2005 chose to recommend SAML 2.0 instead of SAML 1.1 for federation in public sector solutions – 28 June 2006 The reference brief is embedded below