1© Nokia Siemens Networks SAML Name Identifier Request-Response Protocol Contribution to OASIS Security Services TC Christian Günther, Thinh Nguyenphu Nokia Siemens Networks

2 © Nokia Siemens Networks SAML Name Identifier Request – Response Protocol What is being proposed? New SAML request-response protocol by means of which – an IdP can request an identifier for a user from a SP, in case the IdP has no unique identifier of this user of the SP, and, – after User validation, the SP sends a response back to the IdP that includes a unique identifier for the User. The IdP may use this identifier in the future to authenticate the User. The proposed SAML Name Identifier request-response protocol – frees the SP from the need to import all of their Users into IdP databases as soon as they have become part of an IdP's circle of trust, – instead, the SP registers its Users with the IdP "on-the-fly" as the need arises.

3 © Nokia Siemens Networks SAML Name Identifier Request – Response Protocol Why this proposal? Impact on existing SAML specifications? Reason for this contribution – SAML supports SPs to get attributes about users from an IdP,  e.g., regarding name identifiers, the SP usually sends an AuthnRequest to the IdP who sends an AuthnResponse containing a NameIdentifier ("Subject"). – However, if a SP is newly added to the circle of trust of an IdP, the IdP will not know of the identifiers for Users of the SP, which is required in order for the IdP to authenticate the Users of a SP. Impact on existing SAML specifications – The proposed Name Identifier request-response protocol would lead to an extension of:  protocol schema and saml-core-2.0-os  saml-profile-2.0 Name Identifier Request-Response profile  saml-conformance-2.0-os possible implementations, feature matrix – No modification of assertion schema required

4 © Nokia Siemens Networks SAML Name Identifier Request – Response Protocol Why an extension to SAML is required According to the existing SAML specifications, – if the IdP does not know of an identifier of the user for the given SP, the IdP would either send an error message or a random but unique identifier to the SP.  This means, the IdP can react in a deficient way only, without being able to solve the problem where it occurs (namely, at the IdP). According to the proposed Name Identifier Request-Response protocol, – the IdP would not send an error message or a random identifier but send a NameIdentifierRequest to the SP, who sends the requested identifier back to the IdP. – These NameIdentifierRequest/Respose messages are interlaced into the AuthenticationRequest/Response message exchange. – Hence, SP and IdP agree upon unique identifiers "on-the-fly", thereby synchronizing their databases as the need arises.

5 © Nokia Siemens Networks SAML Name Identifier Request – Response Protocol How? High level message flow black = standard SAML 2.0red = new messages

6 © Nokia Siemens Networks SAML Name Identifier Request – Response Protocol Example Instance of Name Identifier Request <samlp:NameIdentifierRequest xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="aaf a-fe114412ab72" Version="2.0" IssueInstant=" T20:31:40Z"> <saml:Issuer Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">

7 © Nokia Siemens Networks SAML Name Identifier Request – Response Protocol Example Instance of Name Identifier Response <samlp:NameIdentifierResponse xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="aaf a-fe114412ab72" Version="2.0" IssueInstant=" T20:31:40Z"> <saml:Assertion MajorVersion="1" MinorVersion="0" AssertionID=" " Issuer="Smith Corporation"> <saml:Issuer Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"> C=US, O=NCSA-TEST, OU=User, <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"> tom.smith

8 © Nokia Siemens Networks SAML Name Identifier Request – Response Protocol Example Instance of Name Identifier Response (cont'd) <saml:Attribute xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid: " FriendlyName="givenName"> Tom <saml:Attribute xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid: " FriendlyName="mail"> <saml:AttributeValue <samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Value="urn:oasis:names:tc:SAML:2.0:status:Success">

9 © Nokia Siemens Networks SAML Name Identifier Request – Response Protocol Conclusion NSN asks the SS TC for – working on the specification of a SAML Name Identifier request-request protocol as outlined in this contribution, – since this protocol enables IdPs and SPs to solve a deficiency of the existing SAML specifications in an appropriate way directly at the places where the deficiency occurs. Impact on existing SAML specifications – The Name Identifier request-response protocol would lead to an extension of:  protocol schema and saml-core-2.0-os  saml-profile-2.0 Name Identifier Request-Response profile  saml-conformance-2.0-os possible implementations, feature matrix – No modification of assertion schema required