Skip to Content

After Shibboleth is Installed

This post is for people who are setting up shibboleth service providers on their web servers.


Look at for common configuration procedure.

  • shibboleth2.xml: This file is where your shibboleth settings will reside. The default shibboleth site settings goes under ApplicationDefaults. Additional vhosts are managed with ApplicationOverride.
  • attribute-map.xml: This file defines the attributes used by the service provider. Add the attributes that you need to that file. Common attributes requested are user information like username (duckid), email address and directory information that all come from LDAP.

Testing Shibboleth

  • Once installed and configured go to your default shibboleth site URL: (The /Login depends on your shibboleth configuration). You can optionally set a target variable to redirect to after authentication. E.g.
  • If you see a 404 error you probably have a redirect setup to send Shibboleth.sso (or any handlerURL you have setup) to some page on your website. Common problem with WordPress. Add RewriteCond %{REQUEST_URI} !^/?Shibboleth.sso/ to stop the redirect. In Shibboleth 2.5.2 you have to setup the redirect for any website that uses redirects otherwise you will see 404 errors.
  • Once you hit enter on that URL you should be redirected to your IDP to authenticate. Once authenticated if you see no errors you will be redirected to your site. Otherwise you will see errors.
  • Commons errors. Here are some possible ones that you should check for:
    • IDP is not configured for your Shibboleth address.
    • IDP is configured for https but you tried to connect with http. This includes using http in the target variable. Since we require https for Shibboleth it is recommended to make all traffic redirect to https.
    • Your server’s date is skewed. Make sure to use NTP and have it running and synced with or any other reliable NTP server.
    • Check Shibboleth logs for errors as well.
  • Once authenticated go to to review your session and see if all the attributes you requested are being provided. If your attribute-map.xml is configured correctly you should see attributes you have access to.

Configuring your application

  • Once you have setup Shibboleth and the attributes you want to configure your site to use Shibboleth in a lazy or non-lazy way.
  • The attributes you requested will be provided to your application in environment variables or HTTP request headers. Reference link.
  • Examples of accessing attributes:
    • PHP: $_SERVER – PHP array.
    • Ruby on Rails: Request.env – Rails object.
  • After you authenticate with Shibboleth you will be using your language’s method of accessing the attributes so you can then authenticate the user on your application and also collect information about the user from those attributes.
  • If you use lazy sessions add a link to login with Shibboleth with an appropriate target that will handle the authentication. E.g.
  • If you use non-lazy sessions make sure you have code in your application that is available on all pages that will give access to the user right after they authenticate with Shibboleth.

Lazy vs Non-lazy Sessions

  • Lazy sessions means that the user does not need to authenticate right away with Shibboleth when visiting your site. This common practice for sites that have public/open pages. Apache example:
AuthType shibboleth
ShibRequireSession Off
ShibUseHeaders On
require shibboleth
  • Non-lazy sessions means as soon as the user visits your site they have to authenticate with Shibboleth. This is used when you have private pages that you require authentication. This can be also used to protect uploaded files like PDFs, images, and so on.
AuthType shibboleth
ShibRequireSession On
ShibUseHeaders On
require valid-user
# Optionally you can set: require
# require duckid robc dmundra

Plugins/modules/extensions for common content management systems