All Protocol Connection share a number of identical settings, which are 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). To see these additional settings, you first have to save a connection with the basic settings explained in this chapter and then open the connection for editing again.
Name: This is the name that identifies the Protocol Connection.
Description: This is a description of the connection for internal administrative purposes only.This field supports localization.
Use Persistent Pseudonym: Federation with persistent name IDs establishes a permanent relationship between a user on an Identity Provider and a user on a replying party or users on an affiliation of replying party. The persistent name ID is used by an Identity Provider and a replying party as a common name for a single user. If this name ID for a user is the same for multiple replying parties, the replying parties are said to be affiliated or belong to an affiliation group. Use this kind of federation to link accounts out-of-band, but without using identifiers that can be traced back to a specific user. This increases the security of your systems by preventing eavesdroppers from determining identities on the basis of name ID formats that pass logon IDs or e-mail addresses.
Ignore Authentication Method of Choice: When a user initially is asked to authenticate and there are multiple possible authentication methods to choose from, the user is asked which one he wants to use for logging in. Once selected, all future logins automatically assume that this is the authentication method of choice for him. If you want to force the user to select the preferred authentication method each time, enable this checkbox.
Owner Organization: By default, the owner organization is set to the organization of the user who created the connections. If you want 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.
The next settings described in this chapter all have an influence on how claim values are set in the claims pipeline. All of them can be said to be claim filters. Any request using the selected Protocol Connection will thus be subjected to the claims filters of it as specified in the following:
Connection Dependency: This setting allows the user to specify which Authentication Connections are to be used with this Protocol Connection. The user is also able to set the priority of Authentication Connection (which is used for picking up a session when multiple sessions exist) by changing its index in the list using the Up/Down buttons.
Home Realm Discovery: This settings allows the user to specify which HRD mechanisms are to be used with this Protocol Connection. The user is also able to set the priority of mechanism by changing its index in the list using the Up/Down buttons – The index is used to decide which mechanism is called during HRD processing. There are two groups of HRD rules: standard and default mechanisms.
Current HRD mechanisms:
- Whr parameter: See description below.
- Persistent cookie: Persistent cookie discovery.
- Show tailored IDPs list from CDC: Even when CDC is used, there may be multiple Idps are discovered from CDC. When this option is not checked, Safewhere*Identify simply picks the first appropriate IdP. Otherwise, it shows all appropriate IdPs in a selector page so that users can pick one.
- Common domain cookie:CDC discovery.
- IP-based HRD: When an SSO request comes from an IP-address matching that is set on an Authentication Connection - and this mechanism is enabled - then Identify will use the “IP-based filter for Home Realm Discovery” option to find the one that is prioritized. If the value matches with more than one of the Authentication Connections, then the one chosen will be the one that is indexed lowest in the Connection Dependency list. If none match, then IP-address will not be used for HRD.
- Auto HRD:When a user is redirected to Safewhere*Identify, the system can detect if he or she has already logged in to an upstream Identity Providers such as Facebook, Google, or ADFS 2.0 in the same browser session and thus automatically use the corresponding connection to grant the user access to the Service Provider he or she wants to visit.
There are a few other settings related to Auth HRD explained below:
- Disable automatic Auth selection if not supported by all login modules: If this option is checked and there is an Authentication Connection, that does not support auto HRD, the auto HRD mechanism will not be used.
- Auto Home Realm Discovery processing timeout: (seconds) It might take a while to process through iframes of the login. This value is used to stop the auto HRD process when the set time is exceeded.
- Allow user to override Auto HRD: When this option is checked, then a button is offered that says: "If you want to ignore and continue, click here!". It will allow a user to skip auto HRD processing manually.
- Option for processing Home Realm Discovery when error happens: Determine which option to process when a fatal error happens. Two options are offered:
- ProceedToNextMechanism: When a fatal error happens, proceed to using the next lower priority mechanism.
- ProceedToDefaultMechanism: When a fatal error happens, proceed to using default mechanisms.
- Default HRD mechanisms: Offer three possible choices for the HRD mechanism:
- Determine single authentication connection:Determine each authentication login status.
- Identify-initiated common domain cookie:Identify-initiated cookie discovery.
- Show log on picker: Show Selector page to pick up an Authentication Connection.
Claim Pipeline: The claim pipeline of the Protocol Connection consists of a number of Transformation steps that you can select. Only claim transformations that belong to the organization in the allowed-to-see organizations of the currently logged-in 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, click here. To add Claim Transformation object to the connection’s Pipeline, choose it from the drop-down 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.
Remember Consent: If you want to make it possible for the users to choose to skip the consent step when logging in given that they gave consent during the initial login, set this option to True. The consent choices they made will be saved and used for their future authentications for this Protocol Connection.
Consent claims sets: The consent claims set of the Protocol Connection consists of a number of claim sets that you can select. You can choose to add any claims set that is added to the system. To read more on adding claims set objects, click here. To relate a claims set object to the connection’s consent, choose it from the drop-down and click Add or select the added claims set from the selected added claims set list and click Remove to remove it.
Scopes for consent:Consent scopes are Service Provider specific data for the user that can be requested by the RP from the Resource Server/Protected Resource.
To relate a scope object to the connection’s consent, click the Add button:
- Name: Specify a name for the scope that will make it easy to recognize when adding to the “Scopes for consent” on the Protocol Connection s.
- Code: Specify the code for the scope.
- Description: Specify the description that will make it easy to recognize when viewing on my consent or consent page.
- Is the scope required for user to authenticate?: When a scope is required, the user must agree to it before he can continue logging in.
Note: The name and code must be unique for the connection.
Authentication list view name:Specify the view that should be used in place of the default view to display associated Authentication Connections.To activate this feature, put your specified view at the locations~/Views/PlugIn/ or ~/Views/Shared/in the Runtime folder and input the view name (not including the “cshtml” file type) on the "Authentication list view name" field of the Protocol Connection.
Present the login selection page if no prior service provider specific selection has been made:Instead of having a cookie with one value common for all service providers, the cookie will store a login selection choice per service provider. This setting allows the administrator to choose whether the user should be offered to select another authentication method than the one they are currently logged in with albeit in a session with another service provider. Presenting such a choice is important in the case, where the choice of authentication method will have an impact on the authorization rights of the user. It is also possible to just choose – as was the case in earlier versions - that SSO will be carried out whenever possible.
Now let us take a look at the different configuration settings that exist for the different Protocol Connection types.