Support OIOSAML 3.0

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:

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:

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 at section Configure Service Provider.
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.

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:

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.