This is the third blog of a series on SAML, these are the first and second blogs.
Great, it’s installed and securing the Apache URL, but it doesn’t seem complete. One thing becomes clear at this point. SAML only performs authentication if you are building a custom app, authorisation is your problem. You can get passed useful information from the IdP if you configure Shibboleth to accept and map this to fields that you can access from your application.
This blog covers the last steps in proving all the moving pieces are working correctly.
Prerequisites for this are:
- SAML Proof of concept – Part 2 has been completed
Gluu Setup:
To see information about an authenticated user. Firstly, any attributes need to be exposed by your IdP in the SAML Trust Relationship. Check that memberOf, Username and Display Name are released attributes. If they aren’t, click on the missing attributes to bring them in and update the settings.
Create a user, you will have to edit the user after creation to set the password.
Create a group and assign the user to the group
Attribute Mapping:
For you to access the additional attributes exposed by the IdP you will need to install a programming language that runs under Apache and then maps the exposed IdP attributes to local attributes names so they can be referenced. I’ve selected php as it’s easy to setup for our test scenario.
Each attribute exposed by the IdP has a unique identifier to identify the SAML2 URIs for the attributes you have exposed. These can be found under Configuration -> Attributes in the Gluu console
Update the Attribute Mappings configuration on your web server found in /etc/shibboleth/attribute-map.xml.
For each attribute you want to access the following line needs to be added to this file <Attribute name=”[SAML2 URI]” id=”[DESIRED ATTRIBUTE NAME]“/>
In our test case, we want to add the following between the root attribute tags
<Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">...<Attribute name="urn:oid:memberOf-oid" id="memberOf"/>
<Attribute name="urn:oid:0.9.2342.19200300.100.1.1" id="userName"/>
<Attribute name="urn:oid:2.16.840.1.113730.3.1.241" id="displayName"/>...
</Attributes>
Restart Shibboleth
service shibd restart
Test web page creation:
To install php on your web server the commands to run on you server are:
sudo su
apt-get install libapache2-mod-php5
Next create a file under /var/www/html/auth called phptest.php. With the following contents
<?php
$arr = array(
"userName" => $_SERVER["userName"],
"displayName" => $_SERVER["displayName"],
"memberOf" => $_SERVER["memberOf"]);
echo json_encode($arr,JSON_FORCE_OBJECT);?>
If you now visit https://<your webserver ip>/auth/phptest.php you will be presented with a web page with the following text
{"userName":"test","displayName":"A Test User for SAML","memberOf":"inum=@!F9C7.0026.1F8D.7F67!0001!074F.FAD6!0003!D8F1.3153,ou=groups,o=@!F9C7.0026.1F8D.7F67!0001!074F.FAD6,o=gluu"}
It’s not pretty, but a JSON feed of attributes is what your client side JavaScript should need to do it’s thing correctly, obviously any server side case can also take advantage of these exposed attributes.
All the code, all the fun – Ben
