In order to assure that public sector relying parties are able to comply with policies that limit the identity information that they need from a CSP to specific authorized purposes, such as authentication and identity resolution, CSPs should transmit only those attributes that are explicitly requested by an RP. This blog post provides a pointer to a standards based mechanism to do this in the front channel using SAML 2.0.
Many of the front-channel SAML 2.0 federation implementations I’ve seen tend to be rather promiscuous in that they have defined a (sometimes) minimal and default attribute bundle for their community, and deliver it with every authenticated response. While that would work within that community, it becomes problematic if that community needs to inter-operate with a public sector RP that has very specific privacy policies that limits the information it can get from a CSP to only that which it has specifically requested.
To enable this capability, it is necessary to utilize an optional element of the SAML 2.0 protocol called the AttributeConsumingServiceIndex in an authentication request that is generated by an RP (Line 8 below):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <samlp:AuthnRequest ID="abcd1234" Version="2.0" IssueInstant="2014-01-01T01:01:01Z" ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AttributeConsumingServiceIndex="1"> <saml:Issuer>https://rp.example.com/SAML2</saml:Issuer> <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/> <samlp:RequestedAuthnContext Comparison="exact"> <saml:AuthnContextClassRef> http://idmanagement.gov/ns/assurance/loa/3 </saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> </samlp:AuthnRequest>
AttributeConsumingServiceIndex (Optional) - Indirectly identifies information associated with the requester describing the SAML attributes the requester desires or requires to be supplied by the identity provider in the
message. The identity provider MUST have a trusted means to map the index value in the attribute to information associated with the requester. [SAMLMeta] provides one possible mechanism. The identity provider MAY use this information to populate one or more elements in the assertion(s) it returns.</p> SAML 2.0 Core Specification </blockquote> The key here is to define, out-of-band, the index values which are pointers to specific attribute bundles. For example: * AttributeConsumingServiceIndex="0" - Don't send any attributes * AttributeConsumingServiceIndex="1" - Send attribute bundle 1 (First Name, Last Name) In an ideal scenario, you would point to and advertise each of the attribute bundles using SAML Metadata, but there is nothing stopping you from hard coding those bundles into your implementation based on out-of-band agreements (short term results with potential long term management headaches). The end result is that the RP receives only those attributes it has specifically requested per its policy. In the above example, the RP requested index (bundle) 1 as part of the Authentication Request, which has been defined out of band to be First Name and Last Name. That in turn would result in the CSP, after authenticating the individual, issuing the following response with an Assertion consisting of both an Authentication Statement as well as an Attribute Statement:I would be very interested in knowing which of the commercial and open source federation implementations currently support the *AttributeConsumingServiceIndex* capability out of the box. **RELATED INFO** * [SAML 2.0 Assertion Syntax] : https://blog.aniljohn.com/2007/11/saml-20-assertion-syntax.html "SAML 2.0 Assertion Syntax"
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 <samlp:Response Destination="https://rp.example.com/SAML2/ACS" ID="xyz098" InResponseTo="abcd1234" IssueInstant="2014-01-01T01:01:11Z" Version="2.0"> <saml:Issuer>https://csp.example.com/</saml:Issuer> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:Status> <saml:Assertion ID="cc19ebdda" IssueInstant="2014-01-01T01:01:11Z" Version="2.0"> <saml:Issuer>https://csp.example.com/</saml:Issuer> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"> XY123400000511900000000517022Z </saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/> </saml:Subject> <saml:Conditions NotBefore="22014-01-01T01:01:11Z" NotOnOrAfter="2014-01-01T01:06:11Z"> <saml:AudienceRestriction> <saml:Audience> http://rp.example.com/ </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2014-01-01T01:01:11Z" SessionIndex="67775277772"> <saml:AuthnContext> <saml:AuthnContextClassRef> http://idmanagement.gov/ns/assurance/loa/3 </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute Name="http://example.com/ns/attributes/person/GivenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml:AttributeValue>Jane</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="http://example.com/ns/attributes/person/sn" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml:AttributeValue>Smith</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> </samlp:Response>
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.