Anil John
Making Digital Services Secure and Trustworthy

Anil John

Data Minimization with Front Channel SAML Attribute Requests

 Tweet  Share  Share  Comment  Print  Email

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.

SAML 2.0 Core Specification

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:

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>

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


Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!

I will never share, rent, or sell your information to anyone. Cancel anytime.

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.

Topic(s):
By on |

Continue The Conversation ...

I would love to know your thoughts on this blog post. Please leave a comment below!

I am a digital security coach. I help technical leaders make digital services secure and trustworthy. Learn more »

Free Updates

I will never share, rent, or sell your information to anyone