Support OIOSAML 3.0

Safewhere Identify has full support for the new OIOSAML 3.0 profile and the NSIS 2.0. This document will show you how to set your Identify instance up to fully comply with those profiles.

Level of assurance (LoA)

The OIOSAML 3.0 profile uses a set of 3 new levels of assurances:

4.1.1.3 Authentication Contexts

[OIO-SP-06]

The following <saml:AuthnContextClassRef> values MAY be used to request the desired [NSIS] assurance level,
and if present, MUST be used with the Comparison attribute set to minimum:
https://data.gov.dk/concept/core/nsis/loa/Low
https://data.gov.dk/concept/core/nsis/loa/Substantial
https://data.gov.dk/concept/core/nsis/loa/High

You can define them on the Authentication context method classes page.

We suggest that you assign comparable values as follows:

In addition, the profile defines 2 identity types:

[OIO-SP-07]
The following <saml:AuthnContextClassRef> values MAY be used to request the desired attribute profile (see chapter 6 for attribute profiles):
https://data.gov.dk/eid/Person
https://data.gov.dk/eid/Professional

You do not need to define authentication context method classes for these two strings.

Use level of assurance

By default, Identify does not evaluate levels of assurance sent in AuthnRequest. To let Identify do so, you need to configure a number of other settings. You can ignore the section about step-up if you do not need to use the step-up feature though.

Subject identifiers and NameId

The OIOSAML 3.0 profile defines two new NameID identifier strings which represents a natural person or a professional identity.

The NameID element (whether persistent or transient) SHOULD contain an
SP-specific identifier based on a UUID following RFC 4122 as shown in the following example:
https://data.gov.dk/model/core/eid/person/uuid/123e4567-
e89b-12d3-a456-426655440000
(if the Subject represents a natural person identity), and
https://data.gov.dk/model/core/eid/professional/uuid/123e4567-e89b-12d3-a456-426655440000
(if the Subject represents a professional identity; see chapter 6 for details)

You can issue such NameID by using our claim rules.

Basic privilege profile 1.2

A Basic privilege profile claim (BPP) is usually composed from many claims as well as other parameters. Because each customer can have different input claims for building a BPP claim, the best approach is to use our excellent scripting transformation to build the claim.

Attribute profiles

Another new requirement of the OIOSAML 3.0 profile is the two attribute profiles: natural person profile and professional person profile. One more time, you can easily issues mandatory claims by using our powerful claim transformations.

New behaviors

In addition to new requirements that need some special setups, the profile has some small requirements that we have implemented as default behaviors of Safewhere Identify.

IsPassive and LoA

Per the OIOSAML 3.0 profile:

IdPs MUST understand and respect the IsPassive attribute on requests. If the IsPassive attribute is set and control of the user interface is needed to complete an authentication, the following status code MUST be returned urn:oasis:names:tc:SAML:2.0:status:NoPassive.

*Note: The NoPassive error can occur if the IdP does not have a session with the user, if the IdP has a session but at a lower LoA than requested by the SP, or if the IdP policy requires active user consent prior to attribute release.*

This means that if you set up your Identify instance to evaluate LoA and the situation mentioned in the note happens, Identify will return a NoPassive response to the service provider.

Storing private keys in HSM devices

Another key new requirement from the NSIS 2.0 standard is that private keys of signing certificates must be stored in HSM devices. To start with, we have implemented support for Azure Key Vault's HSM keys. We will add support for hardware-based HSM devices in a future version.