releasing the ldap mail attribute from the shibboleth idp
Thu, Feb 7, 2013
In this tutorial I show how to get the Shibboleth Identity Provider (IdP) to release a user’s mail attribute from an LDAP store. If you don’t have an IdP installed, perhaps you’d like to spend a happy half hour reading my other tutorial - Coffee break Shibboleth IdP install with custom certificate, login page and LDAP.
If you’ve read the previous tutorial you’ll know that our hero, Harry McDesperate, the world’s most violent house visitor(!) is rather fond of Blandings Manor and his attributes gain him entry to that fine baronial pile via his letter of introduction. However to gain access now, Blandings have decided that all visitors must have an email address, so they can inform the visitors of new furrniture arrivals, tea acquisitions etc. But Harry’s letter doesn’t contain an email address so Jives McDoorman sends him on his way and his next port of call is your office. Demanding that his letter of introduction be updated to contain his email address. What are you going to do?
There are three steps to releasing an attribute. First you define a data connector. This tells the IdP where to get attributes from. In our case it’s going to be LDAP. So open the file IDP_HOME/conf/attribute-resolver.xml and uncomment the Example LDAP Connector section. This is what mine looks like:
Note the resolver id which in this case is ldapConnector. You’ll need that in a moment. My FilterTemplate also has cn but your’s might be uid depending how your LDAP is set up. Also note that I’ve restricted what the IdP will pull from LDAP using ReturnAttributes. This is a space separated list of attributes that you want. Restricting what it pulls out can speed up the extraction process. That’s the source of attributes now plumbed into the IdP.
The next step is to define a new attribute. Open the file IDP_HOME/conf/attribute-resolver.xml again and look for the section called Attribute Definitions. You’ll find a bunch of commented out attributes that are useful for an IdP to know about. We won’t uncomment them all as we only want to release the mail attribute. So what I did was just create a new one:
Note the id of ‘email’ and the reference to ldapConnector in the Dependency. This tells the IdP that the attribute who’s id is ‘email’ comes from LDAP as the ‘mail’ attribute, which is one of the attributes, well the only one, we pull from LDAP based on ReturnAttributes in the DataConnector.
The last step is to release this newly plumbed in and defined attribute to anyone. Open the file IDP_HOME/conf/attribute-filter.xml and in the AttributeFilterPolicyGroup section add a new AttributeFilterPolicy. This is mine:
This states that the attribute known as ‘email’ (remember from the attribute definition?) can be released to anyone.
To test this you can use the Attribute Authority Command Line Interface:
replace harrymcd with a valid user from your LDAP store. You should see the mail attribute released in SAML2 format:
And that’s that. LDAP attribute store plumbed in, one attribute defined and released.
Harry returns to Blandings with his new letter of introduction and waves it at Jives McDoorman, who groans and shows our hero to the tea and cake trolley.
- Coffee break Shibboleth IdP install with custom certificate, login page and LDAP
- LDAP Data Connector
- Define and Release a New Attribute in an IdP
- Attribute Authority, Command Line Interface (AACLI)