Versions Compared

Old Version 21

changes.mady.by.user Peter Clijsters

Saved on

compared with

New Version 22

changes.mady.by.user Peter Clijsters

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Depending on the integration option you choose for your service, you need to follow a different connection procedure and technical implementation.

1) SFO authentication

  • Procedural
    An institution must give permission for a SFO integration in the SURFsecureID pilot or production environment. Although an SFO integration is almost always implemented by the institution itself, it is possible that someone else may want to implement it. By requiring permission from the institution we make sure that the proper persons are notified. The SURFconext contactperson (SURFconext-verantwoordelijke) needs to provide this permission by sending an email to support@surfconext.nl. 
  • Technical
    Implement the SFO connection. There is a technical description of how a SFO connection works and what is needed to connect with it. This integration is based on the widely used open standard SAML2, so an integrating can be easily made. However, for some popular systems, we've created a description or even software to make it even easier:


2) Standard authentication. This integration is similar to connecting to SURFconext with a few differences.

  • Procedural / contractual
    Because this integration option uses SURFconext for the first factor and privacy sensitive information from the user is transferred to the service, it is necessary to have the correct agreements in place. Make sure you follow the SURFconext contractual obligations. This step is not necessary when you use the SURFsecureID test environment.
  • Technical
    Technically, your service will connect to SURFsecureID directly. However, because indirectly your service also uses SURFconext, you will need to register your service in the SURFconext SP dashboard. When this is done, you need to implement the technical connection with SURFsecureID. Making this connection is similar to making a SURFconext connection. These steps are necessary for each SURFsecureID environment.


More info: 

Introduction

Connecting to the SURFsecureID gateway is very similar to connecting to SURFconext. The are only small differences:

  • you will need other SAML metadata.
  • there are other optional features in the SAML protocol messages
  • there are other SAML features
  • there are differences in SURFconext features available when authenticating

When you need different LoA's, more work may be involved. The SP must communicate the required LoA to the SURFsecureID gateway and verify the strength at which a user was authenticated. Both are expressed in the SAML request and response messages that are exchanged between the SP and SURFsecureID.

Levels of Assurance

Regarding to the levels of assurance, there are three scenarios, explained below. They can be combined: the gateway will use then the scenario having the highest LoA.

1. Minimum LoA specified by the institution (static)

The institution requires, for a specific SP, its users always to be authenticated at a certain minimum LoA.

The institution must ask SURFnet to set this minimum. SURFnet will configure this on the SURFsecureID gateway.

2. Minimum LoA specified by SP (static)

The SP requires always a certain minimum LoA.

The SP must ask SURFnet to set this minimum. SURFnet will configure this on the SURFsecureID gateway.

3. LoA defined during authentication (dynamic)

A SP can request authentication at a certain LoA by specifying it in the AuthnRequest. The SP can send this request to the gateway at any time, also when a user is already logged in. This makes it possible to raise the LoA for a user depending on the context, e.g. if the user wants to enter the admin part of the site.

Three levels of assurance

The SURFsecureID gateway supports three levels of assurance:

  • LoA 1: Password authentication through SURFconext at the users home IdP
  • LoA 2: LoA 1 + SMS or Tiqr authentication
  • LoA 3: LoA 1 + YubiKey (hardware token) authentication

Each LoA is assigned to an identifier and is different for each type of environment used:

...

 

...

Pilot

...

Production

...

http://test.surfconext.nl/assurance/loa1

...

http://pilot.surfconext.nl/assurance/loa1

...

http://surfconext.nl/assurance/loa1

...

http://test.surfconext.nl/assurance/loa2

...

http://surfconext.nl/assurance/loa2

...

http://test.surfconext.nl/assurance/loa3

...

http://surfconext.nl/assurance/loa3

The requested LoA is interpreted as a minimum. The SURFsecureID gateway:

  • Will not perform authentication below the requested loA.
  • May perform authentication at a higher level, in which case the higher level LoA will be expressed in the returned SAML Assertion.

The LoA required is passed to the SURFsecureID gateway in an AuthnContextClassRef element in a RequestedAuthnContext element in the SAML AuthnRequest.

The identifiers are used in SAML messages communicating the LoA between the SURFsecureID gateway and SP. The actual method of authentication itself (e.g. SMS + password) is not communicated!

  • The SURFsecureID gateway will report the SP the actual LoA at which authentication was performed. This is done with the AuthnContextClassRef element of AuthenticationContext in the SAML Assertion.
  • A SP may request authentication at a specific LoA by specifying the LoA identifier in a AuthnContextClassRef element in a RequestedAuthnContext in a SAML AuthnRequest.

More info: