This documentation relates to uPortal 4.0
If you are using a different version, please click on "Click for all versions" on the left side of the page and select the relevant version.


Skip to end of metadata
Go to start of metadata
All Versions
Page not found
Table of Contents
Page not found

Shibboleth Overview



Gliffy is unlicensed. Please install a license to draw diagrams in your wiki.

Skipping a lot of detail here is an overview of the steps involved with using Shibboleth with uPortal. The uPortal configuration step is very small and generally trivial. In the list below steps 1 through 4 are covered by the Shibboleth Documentation. Step 5 is the only uPortal specific part and described below.

  1. Install and configure Shibboleth SP - configure SP to pass uid via REMOTE_USER to get it working faster.
  2. Install and configure uPortal - get it running on its own without Shib.
  3. Install and configure Apache httpd server.  Configure httpd with Shib and validate that Shib can protect resource AND pass attributes.  Also configure httpd to work with tomcat (mod_jk).  Configure the Shib SP to pass attributes in HTTP Headers.
  4. Configure to get the IDP's Login page
  5. Configure uPortal authentication - use the RemoteUserSecurityContext for (Shib) authentication

For Shibboleth IdP or httpd server related questions please contact the shibboleth-users list.

Shibbolizing uPortal

Step 1 - Security Context

Configure uPortal to get the username from the REMOTE_USER header. Update the uportal-war/src/main/resources/properties/ file:

## This is the factory that supplies the concrete authentication class

Shibboleth only configuration

Optionally, to ensure the Shibbolized uPortal instance has no chance of using anything but Shibboleth for authN, comment out the root.simple context as well.


WARNING – do not remove the line The RemoteUserPersonManager expects the RemoteUserSecurityContext to be a child of the root, not the root itself.

Multiple Authentication Systems

To enable multiple authentication systems use UnionSecurityContextFactory as root. With multiple authentication systems, uPortal will attempt to authenticate the user to all systems until one is successful.

## This is the factory that supplies the concrete authentication class

Step 2 - Person Manager

Configure uPortal to create user's on demand based on the REMOTE_USER header.

In uportal-war/src/main/resources/properties/contexts/userContext.xml replace SimplePersonManager bean

<bean id="personManager" class="" />

with the RemoteUserPersonManager bean. Note that the bean id stays the same.

<bean id="personManager" class="" />

Step 3 - Person Attributes

Configure uPortal to populate user's attributes based on headers from Shibboleth.

In pom.xml update the line:




In uportal-war/src/main/resources/properties/contexts/personDirectoryContext.xml add the following beans

 | Servlet filter that creates an attribute for the serverName
<bean id="requestAttributeSourceFilter" class="">
    <property name="additionalDescriptors" ref="requestAdditionalDescriptors" />
    <property name="usernameAttribute" value="remoteUser" />
    <property name="remoteUserAttribute" value="remoteUser" />
    <property name="serverNameAttribute" value="serverName" />
    <property name="processingPosition" value="BOTH" />
    <property name="headerAttributeMapping">
            <entry key="cn">
            <entry key="givenName" value="givenName" />

 | Session-scoped descriptors object. One of these will exist for each user in their session. It will store the
 | attributes from the reques set by the requestAttributeSourceFilter
<bean id="requestAdditionalDescriptors" class="">
    <property name="delegateDescriptors">
            <bean class="" scope="globalSession">
                <aop:scoped-proxy />
            <bean class="" scope="request">
                <aop:scoped-proxy />

In uportal-war/src/main/webapp/WEB-INF/web.xml add the following servlet filter



No Guest Access

Configure the httpd server to protect uri '/uPortal/Login'

Guest and Authenticated Access

This step is only needed if you're using the uPortal rendered login link.

Modify files in uportal-war/src/main/webapp/WEB-INF/jsp/Invoker/ to change the Login and Logout UIs to something appropriate to your institution.

Guest users go through /uPortal/Login also.  If you have a guest access, you need to configure the 'Sign in' link in uPortal to go to the Shib login page and return to /uPortal.  You can do this by changing the org.jasig.portal.channels.CLogin.CasLoginUrl property (which the Sign-in link uses by default) to something like the following and configure Apache to protect the URL /Shibboleth.sso/Login:


To use a different property name; e.g. to not suggest that CAS is being used, change the property name from org.jasig.portal.channels.CLogin.CasLoginUrl to something else and modify files accordingly; e.g.:

<bean id="idpLoginUrl" class="java.lang.String">
    <constructor-arg value="${org.jasig.portal.idp-login.IdpLoginUrl}"/>
<a id="portalLoginLink" class="btn" title="<spring:message code=""/>" href="${idpLoginUrl}"><spring:message code=""/></a>

Optional: to delete the 'New User' link, remove the link from the login.jsp page.

Multiple Authentication Systems configuration

With multiple authentication systems, you will need to design a login template that will allow users to select a specific authentication system to login. To initiate a Shibboleth session, you will need to construct a Shibboleth WAYF login url, for example the format for our school's WAYF is -

Another example repurposing the default CAS login and replacing it with a Shibboleth login.

<div id="portalCASLogin" class="fl-widget-content">

<a id="portalCASLoginLink" class="button" href="" title="Shibboleth Login">
<span>USC Login</span>


Having problems with these instructions?

Please send us feedback at

  • No labels