 |  |
| | |
OLAT comes with two Shibboleth 2.0 compliant authentication providers. This means, OLAT integrates with your existing Shibboleth infrastructure for authentication and you may use the attributes released by your Shibboleth Identity Provider to restrict access to courses.
OLAT needs a Shibboleth Service Provider (SP) to protect the resource , and to provide the attributes for the authenticated identities. For an introduction about how install and configure a Shibboleth Service Provider 2.0 with Apache, mod-shib, shibd (Shibboleth daemon), mod_jk see OLAT Installation & Administration Documentation.
OLAT uses the SWITCH provided Embedded Discovery Service, which gets configured via the shibbolethlogin.html.
OLAT retrieves the shibboleth attributes directly from the request in org.olat.shibboleth.ShibbolethDispatcher.
Just set the loglevel to DEBUG for the org.olat.shibboleth.ShibbolethDispatcher to get the Shib attribute Map for an authenticated user in olat.log.
OLAT requests a minimum set of attributes from the Identity Provider. The required attributes are: Shib-SwissEP-UniqueID, Shib-InetOrgPerson-mail,
Shib-Person-surname, Shib-InetOrgPerson-givenName, and Shib-SwissEP-HomeOrganization.
When a user first successfully authenticates herself via Shibboleth, she must register with OLAT. The user is asked for a username which identifies the user within OLAT. A user profile is generated and the email address provided by the Identity Provider's Attribute Authority is automatically added to the profile. This implies that an Identity Provider's Attribute Authority must at least provide an email address attribute. Furthermore, a unique identifier is needed which is configurable per site in the olat_config.xml. After accepting the disclaimer, the user is forwarded to the home screen and registration is completed.
Shibboleth SP provides attributes of a user to OLAT. These attributes are propagated within OLAT upon each successful authentication. The attributes can be used within course building blocks to define access and visibility rules. Note that these attributes are not persisted, except for the unique identifier (used to associate an authenticated user to its OLAT user profile) and the email address.
For easier handling of attributes, you may define a set of attribute translations in
olat_config.xml. Attributes will be available by their translated name (outName) within OLAT.
For example, a standard attribute defined by Shibboleth is
Shib-InetOrgPerson-givenName which is both hard to
remember and enter into form fields. With the attribute translation map, you can translate
this attribute's name to givenName and reference it in
your accessibility and visibility rules with its translated name.
DefaultShibbolethAuthenticationController just provides a link for
redirecting the requests to the /shib/. The user is farther redirected to the central WAYF, and upon
selection of the IdP, to the IdP authentication page. Upon successful authentication the user is redirected again to OLAT.
Login sequence with DefaultShibbolethAuthenticationController:
OLAT Login page: Shibboleth Login - DefaultShibbolethAuthenticationController > Redirect to /shib/ > mod_shib > Redirect to WAYF, choose IdP > Redirect to IDP >
IdP Authentication > redirect to the Service Provider that protects this Resource (see SP configuration in shibboleth2.xml) > OLAT (ShibbolethDispatcher - retrieves the attributes)
 |
SWITCH Central WAYF
 |
Authenticate to your IdP
ShibbolethAuthenticationController uses the SWITCH Embedded DS. It basically works like the one above, except
that the user already gets directly the WAYF on the login page.
Login sequence with ShibbolethAuthenticationController:
OLAT Login page: Shibboleth Login Embedded WAYF, Choose your IdP (ShibbolethAuthenticationController) > Redirect to IDP > IdP Authentication >
redirect to the Service Provider that protects this Resource > OLAT (ShibbolethDispatcher - retrieves the attributes)
 |
SWITCH Embedded WAYF
|
Authenticate to your IdP
| |  | |
 |