Authentication Connection

Add Authentication Connection

All Authentication Connection share a number of identical settings which will be explained below, but some of them will also have a number of additional configuration settings used for establishing the connection to the external party (IdP or RP). In order to see these additional settings you will first have to save a connection with the basic settings explained in this article; then open the connection for editing again.

Name: A name that identifies the Authentication Connection. Please give an appropriate name for the Authentication Connection. It will be used in the selector page when showing connections types that users can choose for logging in.

Description: A description of the connection for internal administrative purposes only. This field supports localization.

Enabled: If a connection is disabled it will not be offered as an authentication method.

The next settings described in this article all have an influence on how claim values are set in the claims pipeline. All of them can thus be said to be claim filters. Any request using the selected Authentication Connection will thus be subjected to the claims filters of it as specified in the following:

Do not map logins to user store: When this setting is set to true the system will not map incoming user tokens from this connection to users in Identify's user storage. Rather we will just let the token enter the claims pipeline immediately seen as unregistered users.

Update unknown users from login: If "Do not map logins to user store" is not ticked and no user match is found (a match with the users in the user store is performed based on the identity bearing claim), then the system needs to decide whether it will create a user. The decision depends on the "Update unknown users from login" setting. If the "Update unknown users from login" setting is true, a user has to be created. Identify will save identity bearing claim (if any) sent from requestor to the Identity claim field for the Authentication connection. It will also add the selected claims from "User Template Claims" to the newly created user. Value from requestor's identity bearing claim will take precedence if value for this claim also exist for template. If the "Update unknown users from login" setting is false, the request will simply move on to next step.

Specify organization of auto-created users: If a user is to be automatically created (based on the “Update unknown users from login” field being set to true), then that user needs to be made member of an organization in the system. With this field you choose the organization that the user will be made member of when being automatically created. Proposed organization will be the one that the logged in user himself is member of.

Owner Organization: By default, the owner organization will be set to the organization of the user who created the connections. If you wish a different organization to own the connection, you can set it here. A user will only be offered to change it to his organization or any sub-organization of it.

Identity Bearing Claim: Specifies the free value claim in Safewhere*Identify that will be used to map a received identity bearing claim to a user in the user store. Identity Bearing Claims must be unique for a user, so you will not be allowed to make a connection for a claim, which already has more users with the same value for the claim. Likewise, if a claim has been set to “Identity Bearing”, then no user account can have the value of the claim updated to the same as another user in the system.

Connection Dependency: If you wish this authentication method to only be used by certain service providers, then simple select them in this list. This feature enables us to tailor the login process for each of the service providers using Safewhere*Identify as the IdP.

Authentication context method class: This option is used in relation to assurence level support. We can grant the authentication context method classes that are supported in Identify for the Authentication Connection. Its default value is ‘None’.

User template claims: If the claims pipeline creates a new user, based on the “Update unknown users from login” checkbox being ticked, then we can specify what values the different claims must be given in this section.

After potentially having been exposed to the “User Template Claims” step of the Pipeline, an incoming token using this authentication connection will go through the remaining Claim Pipeline of the connection.

Claim Pipeline: The Claim Pipeline consists of a number of Transformation steps that you can select. Only claim transformations which belong to the organization in the allowed-to-see organizations of current logged user are displayed. Each Transformation step will alter the claim set of the token before handing it on to the next step. You can choose to add any of the Claim Transformation objects that are added to the system. To read more on adding Claim Transformation objects please click here. To relate a Claim Transformation object to the connection’s Pipeline, choose it from the dropdown and click “Add”. Make sure to order the objects so transformations are done in the right order. The higher in the list the earlier the Transformation step will be executed.

These are all the claim pipeline steps that a request will go through in relation to the Authentication Connection it is using. But the claims filtering is not yet fully completed.

Now let us take a look at the different configuration settings that exist for the different Authentication Connection types.