n--1 type federation and more SAML 2.0 questions

["Engler, Michael" <michael.engler@sap.com>]

Title: n--1 type federation and more SAML 2.0 questions

Hi there,

I have a couple of questions regarding the federation scenarios, conformance modes, and authentication context classes supported by SAML 2.0:

Federation Scenarios:

My understanding is, that in general, transient federation should be used to handle group like access, where multiple IdP users can be mapped then to a single SP user ... In that case, I read from the standard, that attribute statements should be used for transferring the information required by the SP for finding the correct SP user ... e.g. this membership status ... or a certain company attribute, that might be used for instance to map all users of the SAP AG to a certain default SAP user at other SPs. The agreement, what attributes to use and how to interpret them is done out of band, right (please correct me if I am wrong)?

My main question, however, is for the persistent identifiers. Let us assume I have either 2 IdP accounts or 1 account each at 2 IdPs ... which I want to map to a single SP account. Does the SAML standard define, whether it shall be possible to have n--1 mappings of IdP users (respectively persistent Ids) to SP users? Or would we assume, that the latest mapping wins, and only a single persistent identifier is mapped to the SP user?

In case we have multiple to one mappings at the SPs, what would be the desired behavior for deferation? I again assume, that calling a defederate endpoint should only defederate the single mapping for the currently used opaque identifier, is this correct?

Conformance modes:

Another stupid question regarding conformance modes and interoperability. Does each and every IdP and SP require to support the ECP modes and PAOS? If yes, why is that the case? If no, how comes that in the Liberty Interop matrix, (http://www.projectliberty.org/liberty_interoperable/interoperable_products/saml_2_0_test_procedure_v3_0_full_matrix_product_table), the IBM and RSA products achieved IdP and SP conformance modes, but do NOT support the ECP conformance mode?

Authentication Context Classes:

Finally a question regarding the authentication context classes.

I understand that I can specify in the AuthNRequest a list of authentication context classes deemed acceptable by a certain SP. Is now this "PreviousSession" always implicitly included in that list? I could not find any information on that in the standard.

If this is not the case, and I need to explicitly mention "PreviousSession" ... how would an SP be able to specify a particular authentication context with single sign-on? E.g. a user authenticated already at the IdP coming from SP1 (which required password authentication). Now he wants to access SP2 that requires client certificate authentication. If SP2 includes "PreviousSession" explicitly, the IdP will accept the existing session, the SP2 will receive in the assertion "PreviousSession" as authentication context class ... and assumes that authentication took place with client certificates ... but is wrong!

Or does the IdP have to ensure, that although "PreviousSession" was included in the list of accepted authentication context classes, one of the other authentication context classes need to match the authentication method that the user performed already?

If the SP specifies a list of 3 authentication context classes, it will still only receive "PreviousSession" if SSO took place ... how does the SP in that case know, what method was previously used for setting up the user context at the IdP?

Long list of questions ... any help is very welcome, many thanks in advance!!

Greetings,

Michael

Dr. Michael Engler
NetWeaver Foundation
Security & Identity Management
SAP AG

Dietmar-Hopp-Allee 16
69190 Walldorf
T   +49/6227/7-47599
F   +49/6227/78-46187
E   michael.engler@sap.com

Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/CEO), Léo Apotheker (stellv. Sprecher/Deputy CEO), Werner Brandt, Claus Heinrich, Gerhard Oswald, John Schwarz, Peter Zencke Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board: Hasso Plattner, Registergericht/Commercial Register Mannheim No HRB 350269

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.