See also:

• The user types (CAS, Shibboleth and application)
• A complex architecture example
• Authenticating the users against an external data source

Properties below are set in /properties/config.properties, they differ depending on the deployment mode.

Setting the allowed authentication methods

Setting the allowed authentication methods is done by setting the three following properties (default values below):

auth.useCas=true
auth.useShibboleth=false
auth.useApplication=true
auth.useSpecific=false

Settign the last property to true is reserved to expert users (see Authenticating the users against an external data source ).

CAS properties

When the CAS authentication is allowed, the following property must be set:

cas.url=https://cas.domain.edu

In servlet or quick-start deployments, the id authenticated user is retrieved from the HTTP session (set by the CAS J2EE filter).

In portlet deployments, the id of the authenticated user is passed from the portal to the portlet thanks to a JSR-168 preference (uid by default):

#auth.portal.uidAttribute=uid

Shibboleth properties

When the Shibboleth authentication is allowed, the properties to set depend on the deployment used.

Servlet and quick-start deployments

The id of the authenticated user is retrieved from a specific HTTP header:

auth.shibbolethIdHeader=REMOTE_USER2

The attributes of the authenticated user are also retrieved from some HTTP headers:

auth.shibbolethAttributeHeaders=Shib-InetOrgPerson-displayName,Shib-InetOrgPerson-givenName,Shib-InetOrgPerson-mail,Shib-Person-surname

These attributes are stored in the application database.

Portlet deployments

The id of the authenticated user is passed by the portal to the portlet thanks to a JSR-168 preference:

auth.portal.uidAttribute=uid

The attributes of the authenticated user are also passed by the portal to the portlet thanks to JSR(168 preferences:

auth.portal.attributes=displayName,mail

Passing such attributes may require some changes at portal-level.