University of Oregon

Identity Management - Shibboleth Application Integration

Audience
Faculty/Staff
Researcher
Student
GTF

Shibboleth relies on two components to be integrated with your web application. The first is a stand-alone server process that runs in the background (shibd) that will communicate with the Identity Provider. The second is a module for your web server that handles the communication between shibd and your application.

The first step in Shibboleth integration is to configure the Shibboleth Service Provider (SP) software on your system. There are pre-built binaries available for several operating systems at the link below. These are highly recommended, as we have had mixed results building the SP from scratch.

Once you have the basic installation finished, you will need to setup a basic configuration for your SP. Sample instructions for this are below.

You will also need to make sure that you have credentials in the test Shibboleth system that you can authenticate with. The test Shibboleth server authenticates against our test LDAP directory. If you do not have a test LDAP account, please contact us and we will set one up for you. To test that you have credentials in test, go to the following URL in a web browser and see if you can authenticate:

https://iscas-test.uoregon.edu/cas

Common Configuration Procedure

Shibboleth is a very flexible system, which unfortunately also means that configuring it can be complex. However, these are the most common steps that need to be taken. The file locations given in the examples are specific to the Redhat Linux RPMs used with the Apache web server and will need to be adjusted if you are using a different OS or web server:

If you are using Windows with IIS, there are separate instructions here: Windows specific instructions

  • Add the following to the /etc/shibboleth/shibboleth2.xml file within the <Sessions> element:
<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet" relayState="cookie"
entityID="https://shibboleth-test.uoregon.edu/idp/shibboleth">
                <SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" defaultACSIndex="5"/>
            </SessionInitiator>
  • Modify the SessionDefaults element to use your server name where sp.example.org is listed.
<ApplicationDefaults id="default" policyId="default"
        entityID="https://sp.example.org/shibtest"
        homeURL="https://sp.example.org/shibtest/index.html"
        REMOTE_USER="uid persistent-id targeted-id"  signing="false"
encryption="false" >
<MetadataProvider type="XML" file="/etc/shibboleth/idp-metadata.xml"/>
  • Restart the Shibboleth SP daemon to make your changes effective:
/etc/init.d/shibd restart
  • Once this is complete, update your ticket in the wso-request RT queue and the IS Shibboleth team will work with you to open up access to their test server.

Apache Configuration

To use Shibboleth authentication for certain areas of your website, you will need to edit your Apache configuration. A simple example of how to do this is below:

<Location /shibtest>
    AuthType shibboleth
    ShibRequestSetting requireSession 1
    Require valid-user
</Location>

For more details, please reference the documentation here: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig

Attribute Delivery

By default, all Shibboleth enabled applications have access to the DuckID, email and uoPersonAffiliation attributes for all people. The following attributes are available by request for UO employees only: name, UO address, UO phone, primary and secondary job title and department and do not require data steward approval. To request access to any other attributes, use the Shibboleth Attribute Request Form.  Post the completed form to your existing wso-request ticket or send it via campus mail to Noreen Hogan in Information Services.