• Centralized User Authentication
  • Instructions
  • Support
  • User Information
    • Identification Information
    • Attribute Availability
  • User Data Synchronization
  • Test Services
    • Shibboleth Test Service
    • Test Service Package and Test User Data

Centralized User Authentication

Instructions

Options for centralized user authentication are described on the page Centralized User Authentication Options.

The most common method for centralized user authentication is the Shibboleth service using the SAML2 protocol.

• Service overview: 1. Shibboleth (SAML2 OIDC)
• Technical installation instructions: Shibboleth Implementation Guide
  • Here you can also find instructions for server-side Apache + Shibboleth SP implementation for RHEL and Ubuntu environments.

Instructions for managing services connected to single sign-on: SP Registry (SAMLOIDC)

• Access to the SP Registry is by default available to all University of Helsinki employees.
• If a user has a University of Helsinki user account but not employee status, they must first log in to the service via single sign-on and then request account activation from atk-autentikointi@helsinki.fi (please explain in the message why this is needed).
• If a developer does not have University of Helsinki credentials, an external account can be requested from the same address if necessary.

Support

Authentication support is available via email.

User Information

Various user details that can be disclosed during authentication may be used for user identification and access management. Examples of widely used attributes include:

• Name details (first name, last name, display name)
• Email address
• Relationship to the university (faculty, staff, employee, student, affiliate, etc.)
• User groups

A more comprehensive list of attributes can be found on the Shibboleth User Attributes page.

Identification Information

The eduPersonPrincipalName attribute (EPPN) is recommended for user identification. Typically, it is in the format username@helsinki.fi.

This remains a unique identifier even if its use extends beyond the university (see trust networks).

Note: Using email as an identifier is problematic both from the application’s and the user’s data protection perspective because an email can be reassigned at the university to a new person. The same user account is not reissued to a different person, so EPPN is safe for individual user identification. Currently, the reassignment prohibition of EPPN also applies to Haka (see trust networks), but not all members of the eduGAIN trust network.

Attribute Availability

Not all attributes may always be available for all users. For example, an email might be missing.

Please consider this in application development and if a particular attribute is essential for the functionality of the application, you should:

• ask the user for missing details within the application, or if this is not possible

• provide the user with a clear error message that specifies the missing attribute (including what it is)

User Data Synchronization

User data can be updated at the time of SAML or OIDC login. If data needs to be kept up to date also outside logins, it can be updated:

• through LDAP (registration similarly via the SP registry), or
• via ESB (Data Management group can assist).

Note: Even if data is regularly updated via LDAP, identification to the service itself should be implemented using SAML or OIDC protocols. Users should never be directed to enter their password anywhere other than the centralized user authentication login page.

Test Services

Shibboleth Test Service

There is a separate test service for Shibboleth (OIDc and SAML) logins, used through the SP registry. The service is registered like for production, but instead of production, the “Publish to test servers” option is selected. Then, the service is automatically added to the Shibboleth test servers within a few minutes, and users can manage test users and their information through the SP registry.

More instructions on the Shibboleth test service on the Test Service page.

Test Service Package and Test User Data

If test user data or, for example, user data synchronization via LDAP is needed, the University of Helsinki has separate test user packages here.

Create-users are packages that can create test data according to University of Helsinki schema.

Test-user-service essentially consists of Ansible scripts for installing your test service, which includes, if necessary, an LDAP service with University of Helsinki schemas, Shibboleth (SAML/OIDC) service, a simple REST API, etc., as well as the creation of test users in such a way that the same data is fed into different services.