Frequently Asked Questions
Are the new tokens backwards compatible?
The new token schemas provided for OIDC and SAML applications are not fully backwards compatible.
Significant changes:
- Only necessary data is included, other personal information can be queried from the Authorization Service API if required by your application
- The full list of e-groups has been removed. This is replaced by the concept of Roles, which you define for your application and map to e-groups plus requirements on identity assurance and multifactor.
| Attribute | Legacy SAML Field | Example Value | Migration Note |
|---|---|---|---|
| User identifier (duplicate of email) | upn | marie.curie@cern.ch | The value in this attribute is not backwards compatible. UPN previously contained the email which was misleading and insecure as it could be modified. The new UPN claim is a permanent, unique, non-reassigned ID. For CERN users it represents the CERN Login name, for federated users it is a unique identifier scoped to the identity provider, e.g. 12387234@google or albert.einstein@unibe.ch |
| User identifier (duplicate of email) | UPN | marie.curie@cern.ch | As above |
| EmailAddress | marie.curie@cern.ch | Maintained | |
| Display Name | DisplayName | Marie Curie | Maintained |
| First Name | Firstname | Marie | Maintained |
| Last Name | Lastname | Curie | Maintained |
| CERN Person ID | PersonID | 755555 | Maintained |
| CERN Unix ID | uidNumber | 55555 | Maintained |
| CERN Unix GID | gidNumber | 5555 | Maintained |
| Preferred Language | PreferredLanguage | FR | Maintained |
| Groups | Group | [list of e-groups] | Replaced by Roles, mapped to e-groups, level of assurance and single/multi factor criteria |
| CERN Identity Class | IdentityClass | CERN Registered | As above |
| Authentication level (Normal or Multifactor ) | AuthLevel | Normal | As above |
| Phone Number | PhoneNumber | +41227655555 | Discontinued, available from the Authorization Service |
| Mobile Number | MobileNumber | +41754115555 | Discontinued, available from the Authorization Service |
| Building | Building | 11 1-111 | Discontinued, available from the Authorization Service |
| CERN Department | Department | IT/MIA | Discontinued, available from the Authorization Service |
| Home Institute | HomeInstitute | CERN | Discontinued, available from the Authorization Service |
| Common Name | CommonName | mcurie | Discontinued (For CERN people, this matches the UPN) |
| Account source | Federation | CERN | Discontinued |
| CERN Role | role | CERN Users | Discontinued |
Why is my SAML application not working with the new SSO?
First, make sure you follow the SAML Application checklist. If it is still not working and you are getting the message "Invalid Client" from SSO, you may need to ensure that your Metadata includes <md:KeyDescriptor use=”signing”> - your signed authentication requests will only be validated if SSO knows which key to use to check the signature.
How can I look up groups for a user?
You will no longer receive all e-groups in your SSO tokens. Instead, you must define roles for your application that are linked to groups. This change has been implemented to protect the privacy of users' personal data. If you have a genuine reason to query all the groups for a user, you can request permission to use the Authorization Service API with an OIDC Application.
How do I require 2FA for my application?
Create a role that is both "Required" and "Requires multifactor", more details are available in the Roles Documentation.
How can an insecure frontend and secure backend work together with OAuth?
A common use case is having an insecure (e.g. single page web app) frontend sending authenticated requests to a secure backend protected by OAuth. There are two main ways to do this:
Token exchange (Purple, dashed lines)
- User authenticated on the frontend via an OAuth public client
- Token is exchanged for a token made for the backend (i.e. audience set to the backend client)
- Token is sent to the backend
Multiple Audiences accepted by backend (Orange, solid lines)
- User authenticated on the frontend via an OAuth public client
- Same token sent to the secure backend, which accepts token audience equal to the frontend client as well as its own
We provide the following libraries and examples which might be of use: