Previous: Shibboleth installation and configuration.
Next: Shibboleth: Integration issues.

SAML attributes

Shibboleth allows or denies access to a directory based on the attributes of the user it receives from the Identity Provider. If Identity Provider cannot authenticate the user, Shibboleth will show an ugly looking exception page. If Identity Provider can authenticate the user, Shibboleth will make the access decision based on user’s attributes returned by the IdP. Attributes come back as part of the IdP authentication response and contain a name and a value:

<saml:Attribute Name="mycompany.securityClearance"><saml:AttributeValue>TopSecret</saml:AttributeValue></saml:Attribute>

Attribute names and values are not part of the SAML standard and are IdP specific, although there are some semi-standard attribute names on the Internet.

Mapping SAML attribute names to Shibboleth attribute IDs

In order for Shibboleth to consider an attribute, its name must be mapped to an internal id using attribute-map.xml file typically located at C:\opt\shibboleth-sp\etc\shibboleth\attribute-map.xml. Attributes that are not mapped cannot participate in the authorization decision. For each attribute, add the following line to the attribute-map.xml file:

<Attribute name="nameAsSeenOnTheWire" id="internalShibbolethId" />

Internal Shibboleth ID is arbitrary and does not have to match the name on the wire. E.g., you may have

<Attribute name="myCompany:securityClearance" id="clearance" />

Static access control

Once you have attribute IDs defined, you can control access to protected resources using <RequestMapper> section of shibboleth2.xml configuration file. The following snippet gives access only to the users with Secret or TopSecret clearance:

    <RequestMapper type="Native">
        <RequestMap>
            <Host name="ikrivpc">
              <Path name="secure" authType="shibboleth" requireSession="true">
                <AccessControl>
                  <OR>
                    <Rule require="clearance">Secret</Rule>
                    <Rule require="clearance">TopSecret</Rule>
                  </OR>
                </AccessControl>
              </Path>
            </Host>
        </RequestMap>
    </RequestMapper>

In theory you can have different rules for different paths, but I have not tried that. Full documentation for RequestMap rules can be found in Shibboleth wiki.

Users who are authenticated by not authorized to access the resource will get error 401 (Unauthorized).

Dynamic access control

Being an ISAPI extension, Shibboleth injects mapped attribute values as pseudo-headers into the HTTP request. Dynamic content such as .aspx files can access those values and make finer-grained authorization decisions based on that, or use the attributes in any other way the see fit. For attribute ID fooBar corresponding header name is SHIB_FOOBAR (capitalized). Note, that these are not real headers, you will not see them on the wire. They exist only between the IIS web server and the code of the .aspx page.

In ASP.NET one retrieves the attribute value using expression Request.ServerVariables["SHIB_FOOBAR"]. It then can be used for information purposes or to show/hide parts of the web side, etc.

<% if (Request.ServerVariables["SHIB_CLEARANCE"] == "TopSecret") { %>
    <!-- show top secret stuff here -->
<% } %>

Note that this comes on top of any static protection that you might have: users whose attributes don’t match the rules from <RequestMap> in shibboleth2.xml will have their access denied and the dynamic application code won’t have a chance to run.

What’s next
I will discuss interesting issues I ran into when integrating my IdP with Shibboleth.