Quality of Authentication (QoA)
- Silvan Grüter
- Andreas Marinello
- Marc Burkhard
- Former user (Deleted)
Introduction
The Quality of Authentication, QoA for short (or Level of Authentication, LoA), defines the quality of authentication that must be achieved in order to meet the defined security requirements of an application. The QoAs are freely definable within the CoreOne Suite, as they are used and interpreted differently in different use cases. This article describes the basic concept and shows a few examples.
Level of Trust
With an installation, there is an option to configure and use a different LoT level. Each LoT level can contain 1-N QoA definitions. This enables you to run different configurations for multiple applications even though they do not share the same understanding of a LoT and or QoA definition.
Quality of Authentication Definition
Within a LoT, a single quality of authentication definition describes a collection of permissible login steps and / or federations that a user must successfully complete in order to reach the corresponding level. The individual levels also have a rank associated to them, which allows you to achieve an ordering within the different QoAs.
Quality of Authentication entries
A single entry consists of a combination of authentication steps and / or federations that must be completed. For example, a quality of authentication entry can consist of a password authentication and a one-time pin which is sent via SMS. If there are several entries for the same quality of authentication, these are to be understood as alternatives (logical OR link).
OIDC ACR and AMR
According to the OpenID Connect specifications, a client can always request a certain ACR value. The ACR value contains the Authentication Context Reference, which is a string representation of the requested authentication level. Within the CoreOne Suite, this references the Level of Trust and therefore the Quality of Authentication and Quality of Registration. The issued token will then contain the appropriate value in the acr claim.
ACR Values
On the application side, a higher QoA can be requested at any time using the authentication request parameter ACR_VALUES.
https://server.example.com/connect/authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fc
&acr_values=urn%3Acoreone%3Aauthentication%3Aqoa%3Avalue%3A1Prefix
Whenever you define your own ACR values, please note that you need to prefix them with urn:coreone:authentication:loa:value:
So requesting urn:coreone:authentication:qoa:value:0 results in the following http parameter
acr_values=urn%3Acoreone%3Aauthentication%3Aloa%3Avalue%3Aurn%3Acoreone%3Aauthentication%3Aqoa%3Avalue%3A0Prefix | Version | Description |
|---|---|---|
| >= 7 | Request a specific LoA, renamed to QoA in version 8, still supported as legacy |
| >= 8 | Request a specific QoA |
| >= 8 | Request a specific LoT |
As the entries are ranked, it’s important to understand that requesting or configuring a certain QoA always also allows any QoA that is within the same set and has a higher rank, as those entries are regarded as more secure.
Examples
Setup
We assume that we have defined the following quality of authentication:
Quality of Authentication | Rank | ACR Value |
|---|---|---|
Default | 1 | urn:coreone:authentication:qoa:value:0 |
Multi Factor Authentication | 2 | urn:coreone:authentication:qoa:value:1 |
Government Issued | 3 | urn:coreone:authentication:qoa:value:2 |
with the following entries
Quality of Authentication Entry | Configuration | AMR Value |
|---|---|---|
Default | Password | pwd |
– OR | Login with a government issued external IdP | external |
Multi Factor Authentication | Password + SMS | pwd, sms |
– OR | Password + Mail | pwd, mail |
– OR | Password + OTP | pwd, otp |
– OR | Login with a government issued external IdP | external |
Government Issued | Login with a government issued external IdP | external |
and that we have the following applications available to the users
Applikation | QoA |
|---|---|
User Portal | Default |
Web Shop | Multi Factor Authentication |
Tax Appliaction | Government Issued |
Use Cases
The following examples result from the setup described above
Simple Authentication
Step | Result | ACR Value | AMR Value |
|---|---|---|---|
User opens the User Portal | He is asked to enter username and password | urn:coreone:authentication:qoa:value:0 | pwd |
Multi Factor Authentication
Step | Result | ACR Value | AMR Value |
|---|---|---|---|
User opens the Web Shop | He is asked to enter username and password. Additionally he is asked to enter either an SMS OTP, Mail OTP or TOTP | urn:coreone:authentication:qoa:value:1 | pwd, mail OR pwd, sms OR pwd, otp |
Authentication using external IdP
Step | Result | ACR Value | AMR Value |
|---|---|---|---|
User opens the Tax Application | He is asked to login using a government issued IdP | urn:coreone:authentication:qoa:value:2 | external |
Step Up Authentication
Step | Result | ACR Value | AMR Value |
|---|---|---|---|
User opens the User Portal | He is asked to enter username and password | urn:coreone:authentication:qoa:value:0 | pwd |
User navigates to the Web Shop | The user is already logged in with a username and password. On the LoA, however, further steps are necessary for all entries and the user is requested to use one of the possible registration procedures. As soon as he has done this, he is logged on to the web shop. | urn:coreone:authentication:qoa:value:1 | pwd, mail OR pwd, sms OR pwd, otp |
User navigates to the Tax Application | The registration steps already carried out do not correspond to the LoA and a registration is therefore started using an external IdP. | urn:coreone:authentication:qoa:value:2 | pwd, mail, external OR pwd, sms, external OR pwd, otp, external |
Single Sign On
Step | Result | ACR Value | AMR Value |
|---|---|---|---|
User opens the Web Shop | He is asked to enter username and password. Additionally he is asked to enter either an SMS OTP, Mail OTP or TOTP | urn:coreone:authentication:qoa:value:1 | pwd, mail OR pwd, sms OR pwd, otp |
User switches to the User Portal | Since he has already completed all the required registration steps, he is already registered. | urn:coreone:authentication:qoa:value:0 | pwd, mail OR pwd, sms OR pwd, otp |
SAML Authentication Context Declaration.
A similar specification also exists in SAML with the Authentication Context Declaration.
© ITSENSE AG. Alle Rechte vorbehalten. ITSENSE und CoreOne sind eingetragene Marken der ITSENSE AG.