The E-Authentication Architecture called Technical Approach for the Authentication Service Component has been revised to Version 2.0.0 (May 4, 2007) replacing Version 1.0.0 (June 28, 2004). In this post I'll have a quick look at what I see has changed. Be aware that I'm no E-authentication or SAML expert, so I may miss important points.
It would had been nice if there had been a short update summary section of the new TA2, but since it's not there I've tried to do a comparison myself. The changes just comes down to adding a new (parallel) architecture based on all the goodies that has come into SAML V2.0, combined with a different choice for Browser SSO and the addition of Single Log-Out (SLO). This gives three approved identity schemes into the ASC:
- PKI
- SAML 1.0 Browser Artifact Profile (SAML 1.0 BAP)
- SAML 2.0 SSO Profile using HTTP POST (SAML 2.0 SSO)
With a very important architecture (read: economic) decision in "3.1 SAML 1.0 Browser Artifact Profile Adopted Scheme":
The PMO is planning to phase out this adopted scheme some time in 2007 in favor of a SAML 2.0 based adopted scheme (see Section 3.2). A migration plan will guide Federation members and COTS vendors through the transition.
That's within the next 6 months, so hopefully everyone has updated and SAML V2.0 conforming software. The streamlining to SAML V2.0 does simplify things and SAML V2.0 support should soon become more widespread (even Google is using SAML V2.0) and adding SLO is very nice, but I can't figure out the business need to phase out the old schema already in 2007.
The TA2 does (like TA1) covers:
- Assertion-Based Authentication
- Certificate-Based Authentication
- Scheme Translation
- Secure Email
- Electronic Forms Applications
here can be noted that:
Within the ASC, SAML-based identity schemes are associated with authentication using PINs and passwords. PKI is associated with authentication using X.509 certificates. However, to support use of higher assurance level credentials by lower assurance level RPs, the ASC allows use of assertionbased mechanisms when X.509 certificates are used for authentication (see Section 2.4.2.1, Scheme Translators).
The new SAML V2.0 POST Profile
Where the SAML V1.0 based interface was based on artifact profile, the new profile is based on POST binding. This is described in E-Authentication Federation Adopted Schemes. The reason for the change of profile should be:
- Simple to implement (e.g. no firewall reconfigurations required, no mutual TLS)
- More scalable because HTTP POST is stateless (i.e., Having no information about what occurred previously) and requires fewer hardware resources
- Faster and less expensive to deploy than SAML Artifact based binding
I have no experience deploying SAML V2.0 with neither Artifact nor POST, so I can't in any way argue with what they've discovered during they're research, but I does surprise me if these are major issues.
Actually calling it a POST profile is to simplify it a lot. It's true for as far as landing the Assertion at the RP it's the POST binding, but the rest of the chosen profile is actually based on HTTP Redirect. In section "1.5.1.1 HTTP POST Binding":
This adopted scheme uses the SAML HTTP POST binding as the communication mechanism for a CS to pass a SAML assertion to an RP. The HTTP POST binding defines a mechanism by which SAML protocol messages are transmitted within the base64-encoded content of an HTML form control.
Where as in "1.5.1.2 HTTP Redirect Binding" is used both to get startet (in a typical RP first use case) and for the log out use case:
This adopted scheme uses the SAML HTTP Redirect binding as the communication mechanism for passing a SAML authentication request from an RP to a CS. This is the minimum required by [SAML2 Conform]. In addition, this adopted scheme uses the SAML HTTP Redirect binding as a communication mechanism for SAML SLO request-response message exchange.
More details can be found in the E-Authentication Federation Architecture 2.0 Interface Specifications.
0 comments :
Post a Comment