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.

Authentication connection

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: If unchecked, the authentication provider is configured to perform pass-through in regards to the user store, i.e. to allow claims processing without identifying a user. If checked, the authentication provider will try to Safewhere*Identify a user based on a delivered identity bearing claim value.

Update unknown users from login: If “Do not map logins to user store” is not ticked and no user matches are 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. Safewhere*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 Relying Parties, then simple select them in this list. This feature enables us to tailor the login process for each of the Relying Parties 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’.

Authentication connection 2

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.

Authentication connection 3

 

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 userare 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.

SAML 2.0


SAML 2.0 is a popular data format for communicating claims between a claims provider and a relying party.

The configuration settings offered by this Authentication Connection type are:

  •  Entity ID: The entityID attribute is the unique identifier of the identity provider.

There are a whole range of fields that will help you set up a two factor authentication process. Below each of these are explained.

  • Second factor authentication connection: If you want this SAML 2.0 Authentication Connection to have a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This includes all the One Time Password Connections.
  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication), then the two may try to Identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.
  • Use as second factor only: If you just want the Authentication Connection to be used as the second factor for other connections and not have it offered to users as a primary connection option, then this checkbox must be set to true.
  • Ignored by second factor roles claim type: If there are subsets of users that you will allow logging in without also having to authenticate using the second factor, you must specify whom these users are based on a rule. The rule states that any users who have a specific value for a specific claim type, will be excluded from the second factor. This setting specifies which claim will be tested. The setting below (“Ignored by second factor roles”) states which roles will be ignored. Safewhere*Identify will search in both the received assertion and local store.
  • Ignored by second factor roles: The list of roles (claims type values) that a user must have at least one of in order to avoid having to authenticate via the second factor. You should use colon as seperator for these roles.
  • Ignore roles check: If you do not want to let anyone log in without also authenticating via the second factor (thus in effect ignoring the two parameters above), you should set this checkbox to true.

This signing certificate element specifies the signing certificate used by the Authentication Connection. This certificate is used by Safewhere*Identify to sign the communication to the Identity Provider. The potential elements are:

  • Find value: The value of the attribute that is used to Safewhere*Identify the certificate, e.g. its subject or thumbprint.
  • Get certificates button: Allow users to select a new certificate.
  • Find type: Specifies which certificate attribute that will be used to Safewhere*Identify the certificate. A common way to locate a certificate is to search for its subject s distinguished name or its thumbprint. The authentication connection will use the first certificate that matches the specified search criteria.Possible values are: FindByThumbprint, FindBySubjectName, FindBySubjectDistinguishedName, FindByIssuerName, FindByIssuerDistinguishedName, FindBySerialNumber, FindByTimeValid, FindByTimeNotYetValid, FindByTimeExpired, FindByTemplateName, FindByApplicationPolicy, FindByCertificatePolicy, FindByExtension, FindByKeyUsage, FindBySubjectKeyIdentifier.
  • Store location: The location of the certificate store to use.Value can beCurrentUser or LocalMachine.
  • Store name: Specifies which certificate store the certificate is placed in. Possible values are: AddressBook, AuthRoot, CertificateAuthority, Disallowed, My.
  • Encryption certificate is in store?: read-only checkbox, checked state means the certificate must be in above store.
  • Single log off service binding: the binding that Safewhere*Identify should use to send log off requests to the involved Identity Provider. In Safewhere*Identify, it is usually either “urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” or “urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”.
  • Single log off service location: the endpoint to which Safewhere*Identify should send log off requests.
  • Single log off service response location: the endpoint to which Safewhere*Identify should send responses for log off requests that I received from the Identity Provider.
  • Single sign on service binding: the binding that Safewhere*Identify should use to send sign on requests to the involved Identity Provider.
  • Single sign on service location: the endpoint to which Safewhere*Identify should send sign on requests.
  • Below are settings for artifact resolution:

saml 1

Note: in Identify, HTTP-POST will be the default binding whose index is 0 so that when exchanging metadata with in Identity Provider, IdP needs to update setting to use the correct HTTP-Artifact binding and Location.

saml 2

  • Default name id format: Dropdown list to specifies the default format for NameId claim. Currently “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”, “urn:oasis:names:tc:SAML:2.0:nameid-format:persistent” and “urn:oasis:names:tc:SAML:2.0:nameid-format:transient” formats are supported.

   Please be noted that when importing metadata, if the nameid is not in above formats, “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified” is used by default.

  • Always override with default NameIdFormat: When a token that Safewhere*Identify receives from an Identity Provider has NameId format set and this is checked, glossary]Safewhere*Identify[/glossary] ignores a token’s NameId format and uses the default value.
  • Use if no NameIdFormat is specified: When a token that glossary]Safewhere*Identify[/glossary] receives from an Idp does not have NameId format set and this is checked, glossary]Safewhere*Identify[/glossary] uses the default value.
  • Set assertion consumer service Url to AuthnRequest: When this is checked, glossary]Safewhere*Identify[/glossary] sets a value to AuthnRequest’s AssertionConsumerServiceUrl property. Otherwises, the property is left empty. Some specific Idps require this property must be set. Default value is FALSE for backward compatibility.
  • Validate subject confirmation data recipient: Safewhere*Identify defines an endpoint which is responsible for receiving sign on SamlResponse messages from Idps. When this is checked, Safewhere*Identify validates if recipient value of SubjectConfirmationData of a sign on Saml response matches to that endpoint.
  • Secure hash algorithm: Identify provides support for both SHA1 and SHA256 algorithm.

The below configuration settings offered by this Authentication Connection type allow for assurance level support. Below each of these are explained.

  • Set RequestedAuthnContext to AuthnRequest: When ticked and when an AuthnRequest received from a service provider contains RequestedAuthnContext classes, Identify will set the context classes – which it sends to upstream IdP – to ‘AuthnRequest’.
  • Authentication context method class mapping:Allows for mapping requested method classes received from a service provider to method classes to be sent to the Identity Provider. The values on the dropdownlist are fetched from the supported authentication context class method on Identify.

saml 3

For example: We have the pair of values: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient

This means when the AuthnRequest from the service provider has the context class = “urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport”, Identify will send an AuthnRequest to the Identity Providerwith class set to“urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient”.

Note: when there is no authentication context class method added on Identify, this option will not display.Safewhere*Identify provides some revocation methods to determine the status of inuse signing and encryption certificates. Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) are mechanisms to be used with settings configured in eachconnection. Revocation Checks can be set for:

  • Signing certificate revocation check
  • Encryption certificate revocation check

The values that can be set for the above are:

  • None: Revocation checking is done.
  • CheckEndCert: Revocation checking is done on the end certificate and only the end certificate.
  • CheckEndCertCacheOnly: Revocation checking is done on the end certificate and only the end certificate. Revocation checking only accesses cached URLs.
  • CheckChain: Revocation checking is done on all of the certificates in every chain.
  • CheckChainCacheOnly: Revocation checking is done on all of the certificates in every chain. Revocation checking only accesses cached URLs.
  • CheckChainExcludeRoot: Revocation checking is done on all certificates in all of the chains except the root certificate.
  • CheckChainExcludeRootCacheOnly: Revocation checking is done on all certificates in all of the chains except the root certificate. Revocation checking only accesses cached URLs.

Another requirement of eGov 2.0 profile in regarding to RequestedAuthnContext is that SP implementations also MUST support the acceptance/rejection of particular <saml2:AuthnContext>content based on the identity of the Identity Provider. In Safewhere*Identify, this requirement is translated to “the ability to reject particular <saml2:AuthnContext> based on Saml2 authentication connection” and is implemented as such. Saml2 authentication is added a new setting which can be used to specified a list of authentication context method classes which Safewhere*Identify rejects when evaluating assertions the corresponding Identity Provider. Multiple classes can be set to the setting. In that case, “;” is used as the separator. For example,  let’s assume we have a connection to ADFS 2.0 and on the ADFS side we log in by using the default login page against AD. Its returning assertion will have one AuthenticationStatement whose class is PasswordProtectedTransport. Now that if we configure the connection to reject PasswordProtectedTransport method, the response will become invalid to Safewhere*Identify.

  • Rejected authentication context method classes: As above described, an array of classes seperated by semi-colon.
  • Federated session lifetime (minutes): Specifies how long a federated session which is established when a user uses this authentication connection to log in.
  • Always override SessionNotOnOrAfter with federated session lifetime: Tokens which Safewhere*Identify receives from an Idp may have SessionNotOnOrAfter set. This value specifies the time point which login session expires. If the setting is not checked, Safewhere*Identify will obey token’s SessionNotOnOrAfter when it establishes a federated session. Otherwises, it will use the value which is specified by the Federated session lifetime setting.
  • IP-based filter for Home Realm Discovery: specifies IP addresses of RPs for the filter.An IP address consists of 4 sections of numbers between 1 and 255. The 4 sections of numbers are seperated by a dot. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by seperating them with semicolons. E.g.: 192.168.1.1;192.168.1.2;192.168.0.0-192.168.1.255.
  • Supports automatic selection of authentication connection: check it to enables the Auto HRD mechanism for this authentication connection.
  • Authentication status checker path: path to checker script which is called to process Auto HRD mechanism.

Username & Password


Since this connection type handles all the authentication solely in Safewhere*Identify, limited configuration is needed.

  • Federated session lifetime (minutes): Specifies how long a federated session which is established when a user uses this authentication connection to log in.

There are a whole range of fields that will help you set up a two factor authentication process. Below each of these are explained.

  • Second factor authentication connection: If you want this Authentication Connection to have a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This includes all the One Time Password Connections.
  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication, then the two may try to Safewhere*Identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.
  • Use as second factor only: If you just want the Authentication Connection to be used as the second factor for other connections and not have it offered to users as a primary connection option, then this checkbox must be set to true.
  • Ignored by second factor roles claim type: If there are subsets of users that you will allow logging in without also having to authenticate using the second factor, you must specify whom these users are based on a rule. The rule states that any users who have a specific value for a specific claim type, will be excluded from the second factor. This setting specifies which claim will be tested. The setting below (“Ignored by second factor roles”) states which roles will be ignored. Safewhere*Identify will search in both the received assertion and local store.
  • Ignored by second factor roles: The list of roles (claims type values) that a user must have at least one of in order to avoid having to authenticate via the second factor. You should use colon as seperator for these roles.
  • Ignore roles check: If you do not want to let anyone log in without also authenticating via the second factor (thus in effect ignoring the two parameters above), you should set this checkbox to true.

Other settings for this authentication connection type:

  • Maximum number of allowed authentication attempts before password must be reset: Makes it possible for you to define how many retries are allowed before you will no longer take the chance that this is not an attempt at gaining wrongful access to an account. After user has tried this number of times he must use the “Reset password” page to reset his password.
  • Enabled for mobile use: Should be ticked if you also want to allow mobile users to authenticate using this connection.
  • IP-based filter for Home Realm Discovery: specifies IP addresses of RPs for the filter.An IP address consists of 4 sections of numbers between 1 and 255. The 4 sections of numbers are seperated by a dot. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by seperating them with semicolons. E.g.: 192.168.1.1;192.168.1.2;192.168.0.0-192.168.1.255.
  • Username is case-sensitive : should be ticked if you want usernames not to be validated on case-sensitive.
  • Show the link to return to the selector page: should be ticked if you want to allow user to return to Selector page to select the another authentication connection when being at login page. When this option is enabled, there is a link “Return to login selector page” displayed.
  • Custom authentication view:Allow user to select a custom view instead of using the default view.

Mobile


This type of login page is very similar to the Username and Password page, but is specifically focused on secure authentication in connection with login on mobile devices. Since it utilizes a user’s mobile device for delivering an additional security factor – without the user needing to take any additional action – it is a very attractive solution both in regards to usability as well as financially.

The idea behind this authentication method is that the user initially logs in to a personal profile page via regular 2-factor authentication, where a code for use on the mobile device is created. The first time the user initiates authentication via the mobile device, he will be asked to supply this code, which will then be used to create a unique cookie on the device. The next time the user then authenticates via this mobile device, he will just be exposed to the primary authentication requirement (being “username and password”), since the additional authentication factor (the mobile code) is handled by Safewhere*Identify simply checking that the code in the cookie is valid.

The is currently no way of automatically creating codes for users and ensuring that user gets an interface to retrieve these, unless you set up a Safewhere*UserProv site or support this via Safewhere*Identify’s web service. But it would be possible to simply just add a free claim type and let users specify their own code that they will then be requested to insert via the Mobile Login Page.

Although the connection type in itself is a form of two factor authentication, it can in fact even be used with other connection types to increase security further. There are a whole range of fields that will help you set up a two factor authentication process. Below each of these are explained.

  • Second factor authentication connection: If you want this Authentication Connection to have a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This includes all the One Time Password Connections.
  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication, then the two may try to Safewhere*Identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.
  • Use as second factor only: If you just want the Authentication Connection to be used as the second factor for other connections and not have it offered to users as a primary connection option, then this checkbox must be set to true.
  • Ignored by second factor roles claim type: If there are subsets of users that you will allow logging in without also having to authenticate using the second factor, you must specify whom these users are based on a rule. The rule states that any users who have a specific value for a specific claim type, will be excluded from the second factor. This setting specifies which claim will be tested. The setting below (“Ignored by second factor roles”) states which roles will be ignored. Safewhere*Identify will search in both the received assertion and local store.
  • Ignored by second factor roles: The list of roles (claims type values) that a user must have at least one of in order to avoid having to authenticate via the second factor. You should use colon as seperator for these roles.
  • Ignore roles check: If you do not want to let anyone log in without also authenticating via the second factor (thus in effect ignoring the two parameters above), you should set this checkbox to true.

Specific settings for this authentication connection type:

  • Maximum number of allowed authentication attempts before a device-based cookie is expired: Makes it possible to define how many retries are allowed before you will no longer take the chance that this is not an attempt at gaining wrongful access to an account. After user has tried this number of times he will be asked to also insert his Device Code again to get another go at the password.
  • Do not verify if cookie matches device specific information: When this option is checked, user is not required to enter Device Activation Code if he has already once logged in successfully and the code on the device matches his activation code.

Other settings for this authentication connection type:

  • Enabled for mobile use: Should be ticked if you also want to allow mobile users to authenticate using this connection.
  • IP-based filter for Home Realm Discovery: specifies IP addresses of RPs for the filter.An IP address consists of 4 sections of numbers between 1 and 255. The 4 sections of numbers are seperated by a dot. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by seperating them with semicolons. E.g.: 192.168.1.1;192.168.1.2;192.168.0.0-192.168.1.255.
  • Show the link to return to the selector page: should be ticked if you want to allow user to return to Selector page to select the another authentication connection when being at login page. When this option is enabled, there is a link “Return to login selector page” displayed.
  • Custom authentication view:Allow user to select a custom view instead of using the default view.

To see how the authentication page looks to the users, please click here.

WS-Federation


WS-Federation is a popular data format for communicating claims between a claims provider and a relying party. The configuration settings offered by this Authentication Connection type are:

  • Entity ID: The entityID attribute is the unique identifier of the identity provider.

There are a whole range of fields that will help you set up a two factor authentication process. Below each of these are explained.

  • Second factor authentication connection: If you want this Authentication Connection to have a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This includes all the One Time Password Connections.
  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication, then the two may try to Safewhere*Identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.
  • Use as second factor only: If you just want the Authentication Connection to be used as the second factor for other connections and not have it offered to users as a primary connection option, then this checkbox must be set to true.
  • Ignored by second factor roles claim type: If there are subsets of users that you will allow logging in without also having to authenticate using the second factor, you must specify whom these users are based on a rule. The rule states that any users who have a specific value for a specific claim type, will be excluded from the second factor. This setting specifies which claim will be tested. The setting below (“Ignored by second factor roles”) states which roles will be ignored. Safewhere*Identify will search in both the received assertion and local store.
  • Ignored by second factor roles: The list of roles (claims type values) that a user must have at least one of in order to avoid having to authenticate via the second factor. You should use colon as seperator for these roles.
  • Ignore roles check: If you do not want to let anyone log in without also authenticating via the second factor (thus in effect ignoring the two parameters above), you should set this checkbox to true.

Other settings include:

  • Passive requestor endpoint: Specifies the endpoint of an IdP to which Safewhere*Identify sends log in and log out requests and responses.
  • Find value: The value of the attribute that is used to Safewhere*Identify the certificate, e.g. its subject or thumbprint.
  • Get certificates button: Allow users to select a new cert.
  • Find type: Specifies which certificate attribute that will be used to Safewhere*Identify the certificate. A common way to locate a certificate is to search for its subject s distinguished name or its thumbprint. The authentication connection will use the first certificate that matches the specified search criteria.Possible values are: FindByThumbprint, FindBySubjectName, FindBySubjectDistinguishedName, FindByIssuerName, FindByIssuerDistinguishedName, FindBySerialNumber, FindByTimeValid, FindByTimeNotYetValid, FindByTimeExpired, FindByTemplateName, FindByApplicationPolicy, FindByCertificatePolicy, FindByExtension, FindByKeyUsage, FindBySubjectKeyIdentifier.
  • Store location: The location of the certificate store to use.Possible values are: CurrentUser, LocalMachine
  • Store name: Specifies which certificate store the certificate is placed in.Possible values are: AddressBook, AuthRoot, CertificateAuthority, Disallowed, My.
  • Federated session lifetime (minutes): Specifies how long a federated session, which is established when a user uses this authentication connection to log in, will last.
  • Enabled for mobile use: Should be ticked if you also want to allow mobile users to authenticate using this connection.
  • IP-based filter for Home Realm Discovery: specifies IP addresses of RPs for the filter.An IP address consists of 4 sections of numbers between 1 and 255. The 4 sections of numbers are seperated by a dot. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by seperating them with semicolons. E.g.: 192.168.1.1;192.168.1.2;192.168.0.0-192.168.1.255.
  • Supports automatic selection of authentication connection: check it to enables the Auto HRD mechanism for this authentication connection.
  • Authentication status checker path: path to checker script which is called to process Auto HRD mechanism.

NemID


NemID is a popular new authentication method in Denmark. NemID for Safewhere*Identify supports both regular NemID login as well as NemID Erhverv.

From version 4.2, two major changes were introduced:

  • The old Java applet is replaced by new NemID JavaScript which makes it possible to login from mobile devices.

Noted: Microsoft Internet Explorer 8 (IE8) is no longer supported as it does not manage JavaScript adequately which producing a range of errors when users are trying to log on with NemID. NemId users are recommend to use newer version of IE or another browser from now on.

  • Multiple Issuing CAs is now supported as mentioned in the NemID TU13 package (please refer to DanID official documentation).

There are a whole range of fields that will help you set up a two factor authentication process. Below each of these are explained.

  • Second factor authentication connection: If you want this Authentication Connection to have a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This includes all the One Time Password Connections.
  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication, then the two may try to Safewhere*Identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.
  • Use as second factor only: If you just want the Authentication Connection to be used as the second factor for other connections and not have it offered to users as a primary connection option, then this checkbox must be set to true.
  • Ignored by second factor roles claim type: If there are subsets of users that you will allow logging in without also having to authenticate using the second factor, you must specify whom these users are based on a rule. The rule states that any users who have a specific value for a specific claim type, will be excluded from the second factor. This setting specifies which claim will be tested. The setting below (“Ignored by second factor roles”) states which roles will be ignored. Safewhere*Identify will search in both the received assertion and local store.
  • Ignored by second factor roles: The list of roles (claims type values) that a user must have at least one of in order to avoid having to authenticate via the second factor. You should use colon as seperator for these roles.
  • Ignore roles check: If you do not want to let anyone log in without also authenticating via the second factor (thus in effect ignoring the two parameters above), you should set this checkbox to true.

The other configuration settings offered by this Authentication Connection type are:

  • IFrameBase URL:Specifies base url of the iframe. Recommended value: https://appletk.danid.dk/
  • Applet Operation: Specifies the log on operation which the applet should use. Recommended value: OpenLogon2
  • Include Raw Cert: If this is checked, Safewhere*Identify will append a claim whose name is “urn:oid:1.3.6.1.4.1.1466.115.121.1.8” and value is raw data of user’s certificate.
  • Find Value: The value of the attribute that is used to Safewhere*Identify the certificate, e.g. its subject or thumbprint.
  • Find Type: Specifies which certificate attribute that will be used to Safewhere*Identify the certificate. A common way to locate a certificate is to search for its subject s distinguished name or its thumbprint. The authentication connection will use the first certificate that matches the specified search criteria.
  • Store Location: The location of the certificate store to use.Possible values are: CurrentUser, LocalMachine
  • Store Name: Specifies which certificate store the certificate is placed in.Possible values are: AddressBook, AuthRoot, CertificateAuthority, Disallowed, My.
  • Federated session lifetime (minutes): Specifies how long a federated session which is established when a user uses this authentication connection to log in.
  • Enabled for mobile use: Should be checked if you also want to allow mobile users to authenticate using this connection.
  • IP-based filter for Home Realm Discovery: specifies IP addresses of RPs for the filter.An IP address consists of 4 sections of numbers between 1 and 255. The 4 sections of numbers are seperated by a dot. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by seperating them with semicolons. E.g.: 192.168.1.1;192.168.1.2;192.168.0.0-192.168.1.255.
  • Show the link to return to the selector page: should be ticked if you want to allow user to return to Selector page to select the another authentication connection when being at login page. When this option is enabled, there is a link “Return to login selector page” displayed.
  • OpenOces applet endpoint: Points to the endpoint from which the applet is fetched.
  • Challenge: Specifies the exact type of authentication challenge used in the applet (choice between “DanID PID-CPR Response” and “DanID CPR to PID match”).

There are furthermore some settings that set up the option of logging in using the key file (the “Login with NemID key file” tab):

nemId 1

  • Log On To: External party URI
  • Issuer Distinguished Name Filter Value: Company name. Used to check if the certificate supplied by the user has an Issuer that matches this filter value.
  • Subject Distinguished Name Filter Value: Company Number (CVR). Used to check if the certificate supplied by the userhas a Subject that matches this filter value.
  • Serial Number Filter Value: A unique concatenated identifying number. Used to check if the certificate supplied by the userhas Serial number that matches this filter value.

The WhoIsLRA checks whether the authenticating user is administrator for his company. It does this by sending the CVR number (unique company number used in Denmark) to the WhoIsLRA service. The service will then return an array of LRAReply objects with two properties: distinguishedName and emailAddress. These will be interpreted by the IlraClaimsTransformation extensible point. Based on how this one is set up, it will then interpret the LRAReply objects and issue a claim for the user. Please contact Safewhere if you wish this feature to be set up.

  • Enable WhoIsLRA check: Checks if the user is set as Administrator for the company at which he works, by contacting the WhoIsLRA service
  • Claim type to test against WhoIsLRA: This is the claim that should hold the user’s CVR number.
  • Custom authentication view:Allow user to select a custom view instead of using the default view.

How to prepare for NemID on hardware

To enable your users to log on using NemID employee certificate on hardware you need to implement the OpenSign applet on your site. If you already receive employee signatures (MOCES I and/or MOCES II), you have already implemented the OpenSign applet. In that case, you only need to check the following:

On all pages, that load the OpenSign-applet the following list of plugins should also include “cryptoki”, i.e.:<param value=”capi,pkcs12,cdcard,oces,cryptoki”/>

Be aware not to use space between the zip_file_names.

Facebook


It is possible to authenticate users into a federation using their Facebook account. Before it even becomes relevant to set up the Facebook authentication connection in Safewhere*Identify, we must register Safewhere*Identify as an Application with Facebook. The link to do this is:

https://developers.facebook.com/apps/

After signing up as a Facebook developer, register your Safewhere*Identify installation using the “Create New App” button.

facebook 1

This will start a wizard, where you can insert information about Safewhere*Identify as the related application. We will below show the edit form for better overview:

facebook 2

Enter the following information:

  • Display name: A name identifying the application (could e.g. be the Safewhere*Identify site name).
  • Namespace: Not relevant.
  • Contact email: Primary email used for important communication related to the app.
  • App Domains:Not relevant.
  • Hosting URL: Not relevant.
  • Sandbox Mode: Set to Disabled to activate the use of Facebook authentication.
  • Website with Facebook Login: Insert using the following format: [identify site URL]/runtime/facebook/consume.idp

Once registered you will be given a number of important information that you will be using to set up the Facebook connection in Safewhere*Identify. These are:

  • App ID: The unique number that your app is given with Facebook.
  • App Secret: A secret code that will be used to ensure that your installation of Safewhere*Identify is the only one that can use the Facebook authentication app setup.

Now that you have Safewhere*Identify registered in Facebook, you can continue to set up the Facebook authentication connection in Safewhere*Identify. The settings to use are:

  • Facebook OAuth dialog endpoint: Should always be set to https://www.facebook.com/dialog/oauth unless Facebook changes their API.
  • Facebook OAuth dialog for mobile endpoint:Should always be set to https://m.facebook.com/dialog/oauth unless Facebook changes their API.
  • Facebook OAuth access token endpoint: Should always be set to https://graph.facebook.com/oauth/access_token unless Facebook changes their API.
  • Facebook user information endpoint:Should always be set to https://graph.facebook.com/me unless Facebook changes their API.
  • Client id (App id): The App Id automatically generated by Facebook.
  • Client secret code: The secret code automatically generated by Facebook.
  • The additional permissions that a user should grant to identify: Currently, the only possible value here is “email;first_name;last_name”. When you have inserted “email;first_name;last_name” into this field, then this will have two consequences:
  • Enabled for mobile use: Should be checked if you also want to allow mobile users to authenticate using this connection.
  • Perform log out at SLO:Should be checked if you also want to log out your account from Facebook.
  • IP-based filter for Home Realm Discovery: specifies IP addresses of RPs for the filter. An IP address consists of 4 sections of numbers between 1 and 255. The 4 sections of numbers are seperated by a dot. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by seperating them with semicolons. E.g.: 192.168.1.1;192.168.1.2;192.168.0.0-192.168.1.255.
  • Supports automatic selection of authentication connection: check it to enables the Auto HRD mechanism for this authentication connection.
  • Authentication status checker path: path to checker script which is called to process Auto HRD mechanism.

Besides the actual Facebook specific configuration settings, there are a whole range of fields that will help you set up a two factor authentication process, if so desired. Below each of these are explained.

  • Second factor authentication connection: If you want this Facebook Authentication Connection to have a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This includes all the One Time Password Connections.
  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication, then the two may try to Safewhere*Identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.

The following are the list of claims that Safewhere*Identify can expect to get returned from Facebook. The claim types in italic are only returned if so configured in the setting “The additional permissions that a user should grant to Safewhere*Identify: “.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/namehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/givennamehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/surnamehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

To see how the authentication page looks to the users, please click here.

Google


It is possible to authenticate users into a federation using their Google account. Before it even becomes relevant to set up the Google authentication connection in Safewhere*Identify, we must register Safewhere*Identify as an Application with Google. The link to do this is:

https://console.cloud.google.com/iam-admin/projects

After signing up as a Google developer, register your Safewhere*Identify installation using the “Create project” button, input the project name then click “Create”

googleapp1

Then wait until the project is created successfully. On the dashboard of the new created project,input the text: “Credentials” on the search dialog then clicks on the it.

googleapp2a

Once the “Credentials” form opens, choose “Create credentials” and select “Oauth client ID”

googleapp3

You may be asked to set the product name, so choose “Configure  consent screen” like below:

googleapp4

Input the project name and the needed info then click Save

googleapp5

On this form we will input the following values :

googleapp6

  • Application type : Select “Web application”
  • Name : input the name of the credential.
  • Authorized Javascript origins : input the Identify site URL
  • Authorized redirect URI: Insert using the following format: https://[Identify site URL]/runtime/google/consume.idp that will point to your Safewhere*Identify installation. (please trim any white spaces when you input this URI)

Once registered you will be given a number of important information that you will be using to set up the Google connection in Safewhere*Identify. These are:

  • Client ID: The unique number that your app is given with Google.
  • Client Secret: A secret code that will be used to ensure that your installation of Safewhere*Identify is the only one that can use the Google authentication app setup.

googleapp7

Now that you have Safewhere*Identify registered with Google you can continue to set up the Google authentication connection in Safewhere*Identify. The settings to use are:

  • Google OAuth dialog endpoint: Should always be set to https://accounts.google.com/o/oauth2/authunless Google changes their API.
  • Google OAuth dialog for mobile endpoint: Should always be set to https://accounts.google.com/o/oauth2/authunless Google changes their API.
  • Google OAuth access token endpoint: Should always be set to https://accounts.google.com/o/oauth2/tokenunless Google changes their API.
  • Facebook user information endpoint: Should always be set to https://www.googleapis.com/oauth2/v1/userinfounless Google changes their API.
  • Client id (App id): The App Id automatically generated by Google.
  • Client secret code: The secret code automatically generated by Google.
  • The additional permissions that a user should grant to Safewhere*Identify: Currently, the possible value here are “email” and “profile”. When you have inserted these into this field (seperated by semicolon), then this will have two consequences:
    • The user will, when logging in using the Google account, be asked to accept that his email address and personal profile information will be sent to the application (i.e. Safewhere*Identify)
    • In the token, that is returned to Safewhere*Identify from Google, the following claims will also be included:
    • Enabled for mobile use: Should be checked if you also want to allow mobile users to authenticate using this connection.
    • Perform log out at SLO:Should be checked if you also want to log out your account from Google.
    • IP-based filter for Home Realm Discovery: specifies IP addresses of RPs for the filter.An IP address consists of 4 sections of numbers between 1 and 255. The 4 sections of numbers are seperated by a dot. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by seperating them with semicolons. E.g.: 192.168.1.1;192.168.1.2;192.168.0.0-192.168.1.255.
    • Supports automatic selection of authentication connection: check it to enables the Auto HRD mechanism for this authentication connection.
    • Authentication status checker path: path to checker script which is called to process Auto HRD mechanism.

Besides the actual Google specific configuration settings, there are a whole range of fields that will help you set up a two factor authentication process, if so desired. Below each of these are explained.

  • Second factor authentication connection: If you want this Facebook Authentication Connection to have a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This includes all the One Time Password Connections.
  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication, then the two may try to Safewhere*Identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.

The following are the list of claims that Safewhere*Identify can expect to get returned from Google. The claim types in italic are only returned if so configured in the setting “The additional permissions that a user should grant to Safewhere*Identify: “.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/namehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

To see how the authentication page looks to the users, please click here.

Twitter


It is possible to authenticate users into a federation using their Twitter account. Before it even becomes relevant to set up the Twitter authentication connection in Safewhere*Identify, we must register Safewhere*Identify as an Application with Twitter. The link to do this is:

https://dev.twitter.com/apps

After signing up as a Twitter developer, register your Safewhere*Identify installation using the “Create new app” button.

twitters0

A create application form will be shown. After the application is saved successfully, we will have the form like below :

twitters1

Enter the following required information:

  • Callback URIs: Insert using the following format: https://[Identify site URL]/runtime/twitter/consume.idp that will point to your Safewhere*Identify installation.

Once registered you will be given a number of important information that you will be using to set up the Twitter connection in Safewhere*Identify. These are:

twitters2

  • Consumer key: The unique key that your app is given with Google.
  • Consumer secret: A secret code that will be used to ensure that your installation of Safewhere*Identify is the only one that can use the Google authentication app setup.

Now that you have Safewhere*Identify registered with Twitter you can continue to set up the Twitter authentication connection in Safewhere*Identify. The settings to use are:

  • Twitter OAuth request token endpoint: Should always be set to https://api.twitter.com/oauth/request_tokenunless Twitter changes their API.
  • Twitter OAuth dialog endpoint: Should always be set to https://api.twitter.com/oauth/authenticateunless Twitter changes their API.
  • Twitter OAuth dialog for mobile endpoint: Should always be set to https://api.twitter.com/oauth/authenticateunless Twitter changes their API.
  • Twitter OAuth access token endpoint: Should always be set to https://api.twitter.com/oauth/access_tokenunless Twitter changes their API.
  • Twitter OAuth user information endpoint: Should always be set to https://api.twitter.com/oauth/access_tokenunless Twitter changes their API.
  • Client id (App id): The App ID automatically generated by Twitter.
  • Consumer secret code: The secret code automatically generated by Twitter.

Besides the actual Twitter specific configuration settings, there are a whole range of fields that will help you set up a two factor authentication process, if so desired. Below each of these are explained.

  • Second factor authentication connection: If you want this Twitter Authentication Connection to have a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This includes all the One Time Password Connections.
  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication, then the two may try to Safewhere*Identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.
  • Enabled for mobile use: Should be checked if you also want to allow mobile users to authenticate using this connection.
  • Perform log out at SLO: Should be checked if you also want to log out your account from Twitter.
  • IP-based filter for Home Realm Discovery: specifies IP addresses of RPs for the filter.An IP address consists of 4 sections of numbers between 1 and 255. The 4 sections of numbers are seperated by a dot. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by seperating them with semicolons. E.g.: 192.168.1.1;192.168.1.2;192.168.0.0-192.168.1.255.
  • Supports automatic selection of authentication connection: check it to enables the Auto HRD mechanism for this authentication connection.
  • Authentication status checker path: path to checker script which is called to process Auto HRD mechanism.

The following are the list of claims that Safewhere*Identify can expect to get returned from Twitter.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

To see how the authentication page looks to the users, please click here.

Linkedln


It is possible to authenticate users into a federation using their LinkedIn account. Before it even becomes relevant to set up the LinkedIn authentication connection in Safewhere*Identify, we must register Safewhere*Identify as an Application with LinkedIn. The link to do this is:

https://www.linkedin.com/secure/developer

After signing up as a LinkedIn developer, register your Safewhere*Identify installation using the “Add New application” button.

linkedin1

 

This will open a form where you can add info about the app as here shown

linkedin2

Once registered you will be given a number of important information that you will be using to set up the Linked connection in Safewhere*Identify. These are:

linkedin3

  • Client ID: The unique number that your app is given with LinkedIn.
  • Client Secret: A secret code that will be used to ensure that your installation of Safewhere*Identify is the only one that can use the Facebook authentication app setup.
  • Default application permission: please use “r_basicprofile” as default
  • Authorized Redirect URLs: Simply just replace the site tag with your Safewhere*Identify site url; https://[identify site]/runtime/linkedin/consume.idp
  • Default “Cancel” Redirect URL: Simply input your SP site url, e.g https://claimapp.safewhere.com . when user clicks on “Cancel” button, he will be redirected to this URL.

Then choose the “Javascript” tab, update the Identify domain to valid SDK domains:

linkedin4

  • Valid SDK Domains:Simply input your Safewhere*Identify domain. When JavaScript request to logout comes to LinkedIn, they know it come from a valid domain that you allowed.

Now that you have Safewhere*Identify registered with LinkedIn you can continue to set up the LinkedIn authentication connection in Safewhere*Identify. The settings to use are:

  • LinkedIn OAuth request token endpoint: Should always be set to https://api.linkedin.com/uas/oauth/requestToken unless LinkedIn changes their API.
  • LinkedIn OAuth dialog endpoint: Should always be set to https://www.linkedin.com/uas/oauth/authenticate unless LinkedIn changes their API.
  • LinkedIn OAuth dialog for mobile endpoint: Should always be set to https://www.linkedin.com/uas/oauth/authenticate unless LinkedIn changes their API.
  • LinkedIn OAuth access token endpoint: Should always be set to https://api.linkedin.com/uas/oauth/accessToken unless LinkedIn changes their API.
  • LinkedIn user information endpoint: Should always be set to http://api.linkedin.com/v1/people/~unless LinkedIn changes their API.
  • Client id (App id): The API Key automatically generated by LinkedIn.
  • Consumer secret code: The secret code automatically generated by LinkedIn.

Besides the actual LinkedIn specific configuration settings, there are a whole range of fields that will help you set up a two factor authentication process, if so desired. Below each of these are explained.

  • Second factor authentication connection: If you want this Linkedln Authentication Connection to have a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This includes all the One Time Password Connections.
  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication, then the two may try to Safewhere*Identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.
  • Enabled for mobile use: Should be checked if you also want to allow mobile users to authenticate using this connection.
  • IP-based filter for Home Realm Discovery: specifies IP addresses of RPs for the filter.An IP address consists of 4 sections of numbers between 1 and 255. The 4 sections of numbers are seperated by a dot. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by seperating them with semicolons. E.g.: 192.168.1.1;192.168.1.2;192.168.0.0-192.168.1.255.
  • Perform log out at SLO:Should be checked if you also want to log out your account from Linkedln.

The following are the list of claims that Safewhere*Identify can expect to get returned from LinkedIn. The claim types in italic are only returned if so configured in the setting “The additional permissions that a user should grant to Safewhere*Identify: “.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

To see how the authentication page looks to the users, please click here.

OpenID


It is possible to authenticate users into a federation using their OpenID account. When setting up OpenID there is no need to set up any account with the provider (as opposed to what is necessary with all the other social authentication connection types).

Although there are no specific configuration fields, you do have some control over the authentication connection via the script file: <tenant_directory>\<runtime_directory>\Scripts\OpenID-en.js. Open it and see examples for “vidoop” or “launchpad” on how to comment out providers you don’t need.

Notice! OpenID basically is a help to allow integration of a wide selection of Safewhere*Identify Providers with Safewhere*Identify. Many of these identity providers may not work properly. This is not necessarily a problem that Safewhere*Identify can do much to alleviate, since the problems are mostly with the providers. We will although here list the status of some of the providers and our success with them in our testing environment, so you may avoid some annoyances with setting up providers that we do not find work properly:·

  • ClickPass: Safewhere*Identify cannot redirect to this provider and always get the error from OpenID: “No OpenID endpoint found”. We have not yet been able to solve this problem.·
  • ClaimID: We have not been able to test this provider since they have closed the registration pages and we therefore have not had any account for testing.·
  • Blogger: An error occurs in the communication between Google and Blogger that we unfortunately can not do anything to fix.·
  • Google, Yahoo and others: Will return empty claim response to requests. They just authenticate and do not respond to claim requests. Read more on this here: http://stackoverflow.com/questions/3129013/openauth-net-claims-request-is-always-null


Second factor authentication connection:
If you want this OpenID Authentication Connection to have a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This includes all the One Time Password Connections.There are a whole range of fields that will help you set up a two factor authentication process, if so desired. Below each of these are explained.

  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication, then the two may try to Safewhere*Identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.
  • Enabled for mobile use: Should be checked if you also want to allow mobile users to authenticate using this connection.
  • IP-based filter for Home Realm Discovery: Specifies IP addresses of RPs for the filter. An IP address consists of 4 sections of numbers between 1 and 255. The 4 sections of numbers are seperated by a dot. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by seperating them with semicolons. E.g.: 192.168.1.1;192.168.1.2;192.168.0.0-192.168.1.255.
  • Perform log out at SLO:Should be checked if you also want to log out your account from OpenID IdP.

To see how the authentication page looks to the users, please click here.

Live ID


It is possible to authenticate users into a federation using their Live ID account. Before it even becomes relevant to set up the Live ID authentication connection in Safewhere*Identify, we must register Safewhere*Identify as an Application with Live ID. The link to do this is:

https://account.live.com/developers/applications/

After signing up as a Live ID developer, register your Safewhere*Identify installation using the “Add an app” button at “My applications”.

liveid1

After the new application is creating, click “Generate New password” button under “Application secrets” (Please copy this code because it displays only once)

liveid2

 

 

Then Under  “Platforms”, select “Add Platform” and choose “Web”

liveid3

Enter the following information:

  • Redirect domain:Insert the following URIs using the following format: https://[Identify site URL]/runtime/liveid/consume.idp & https://[Identify site URL]/runtime/liveid/signoff.idp that will point to your Safewhere*Identify installation.

liveid4

Please ensure the checkbox “Live SDK support” is True at the “Advanced Options”

liveid5

Once registered you will be given a number of important information that you will be using to set up the Live ID connection in Safewhere*Identify. These are:

  • Client ID: The unique number that your app is given with Live ID.
  • Client Secret: A secret code that will be used to ensure that your installation of Safewhere*Identify is the only one that can use the Live ID authentication app setup.

Now that you have Safewhere*Identify registered with Live ID you can continue to set up the Live ID authentication connection in Safewhere*Identify. The settings to use are:

  • Live ID OAuth dialog endpoint: Should always be set to https://oauth.live.com/authorize unless Live ID changes their API.
  • Live ID OAuth dialog for mobile endpoint: Should always be set to https://oauth.live.com/authorize unless Live ID changes their API.
  • Live ID OAuth access token endpoint: Should always be set to https://oauth.live.com/token unless Live ID changes their API.
  • Live ID user information endpoint: Should always be set to https://apis.live.net/v5.0/me unless Live ID changes their API.
  • Client id (App id): The Client Id automatically generated by Live ID .
  • Client secret code: The secret code automatically generated by Live ID .

Besides the actual Live ID specific configuration settings, there are a whole range of fields that will help you set up a two factor authentication process, if so desired. Below each of these are explained.

  • Second factor authentication connection: If you want this Facebook Authentication Connection to have a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This includes all the One Time Password Connections.
  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication, then the two may try to Safewhere*Identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.
  • Enabled for mobile use: Should be checked if you also want to allow mobile users to authenticate using this connection.
  • IP-based filter for Home Realm Discovery: specifies IP addresses of RPs for the filter.An IP address consists of 4 sections of numbers between 1 and 255. The 4 sections of numbers are seperated by a dot. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by seperating them with semicolons. E.g.: 192.168.1.1;192.168.1.2;192.168.0.0-192.168.1.255.
  • Perform log out at SLO:Should be checked if you also want to log out your account from Live ID

The following are the list of claims that Safewhere*Identify can expect to get returned from Live ID. The claim types in italic are only returned if so configured in the setting “The additional permissions that a user should grant to Safewhere*Identify: “.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

To see how the authentication page looks to the users, please click here.

LDAP


LdapProvider authentication connection extends Identify with the capability to authenticate a user against a LDAP-WS service, which in turns validate a user against an LDAP-compliant server. Note: Identify*Admin requires that the standard Name claim type must be used so we must set Name claim as its identify bearing claim.

The specific configuration for LDAP Authentication connection are:

  • Authentication type: Contains FormBase method and Integrated methodDomain: (Only applies to Microsoft Active Directory) The Active Directory domain name.
  • Prefix user identity with domain name: (Only applies to Microsoft Active Directory) Check to allow Identify to prefix the user identity with the domain name.
  • Identity’s LDAP attribute:Specifies the LDAP attribute, which is used as the user name. It can be pre-defined attribute such as: email address, telephone number, employee ID or new added in LDAP Attribute Definitions UI. Only single-valued attribute should be used for this setting.
  • LdapWS service name: Specifies the LdapWS tenant (please refer to LDAP Web Service Settings) used for this connection.
  • Ldap attribute to specify the primary account: Specifies the LDAP attribute which is used to specify the primary account if a user cannot be uniquely identified by the identity filter above.
  • Primary account attribute value: The value to be used to filter in “LDAP attribute to specify the primary account”.
  • Use on screen keyboard : allow user to input his pasword via this onscreen keyboard. Its default status is False. When you check it, your login page will look like below :

ldap 1

 

  • Enable reset password: allow user to be able to changing his/her password in Login page. The password will be auto-generated following the password policy of the LDAP-WS.
  • Roles that skip reset password: if user has role(s) in this setting, Identify will ignore the change password request.
  • Check for deactivated users when password reset.

The LdapProvider authentication connection even includes a whole range of fields that will help you set up a two factor authentication process. Each of these fields are explained below.

  • Second factor authentication connection: If you want this LdapProvider Authentication Connection to use a second factor, you must choose this second factor among the different Authentication Connections that have been set up in the system. This also encompass all the One Time Password Connections.
  • Two factor identities condition:When using two different Authentication Connections together (which is basically what you are doing when setting up two-factor authentication), then the two may try to identify the incoming user based on two different identity bearing claims. This dropdown is activated when a user has chosen, that the connection will have a second factor. Options in the dropdown are:
    • Use the first identity: System will disregard the “Identity bearing claim” value of the second factor and just focus on identifying the user based on the first one.
    • Two identities must be the same: The user will not be allowed to log in unless the identity of the user for the first factor is identical to that of the second factor.
  • Use as second factor only: If you just want the Authentication Connection to be used as the second factor for other connections and not have it offered to users as a primary connection option, then this checkbox must be set to true.
  • Ignored by second factor roles claim type: If there are subsets of users that you will allow to perform logins without having to authenticate using the second factor, you must specify whom these users are based on a rule. The rule states that any users who have a specific value for a specific claim type, will be excluded from the second factor. This setting specifies which claim will be tested. The setting below (“Ignored by second factor roles”) states which roles will be ignored.Identify will search in both the received assertion and local store.
  • Ignored by second factor roles: The list of roles (claims type values) that a user must have at least one of in order to avoid having to authenticate via the second factor. You should use colon as seperator for these roles.
  • Ignore roles check: If you do not want to let anyone login without also authenticating via the second factor (thus in effect ignoring the two parameters above), you should set this checkbox to true.
  • Custom authentication view:Allow user to select a custom view instead of using the default view.

There is also option to enable/disable support for specialized web pages for mobile use.

  • Enabled for mobile use

Windows integrated settings:

  • Registry: disable the loopback check by setting the DisableLoopbackCheck registry key
  1. Click Start, click Run, type regedit, and then click OK.
  2. In Registry Editor, locate and then click the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

  1. Right-click Lsa, point to New, and then click DWORD Value.
  2. Type DisableLoopbackCheck, and then press ENTER.
  3. Right-click DisableLoopbackCheck, and then click Modify.
  4. In the Value data box, type 1, and then click OK.
  5. Quit Registry Editor, and then restart your computer.
  • Browsers settings:

 Internet Explorer, Chrome, Safari:

Tools > Option > Security > Local Intranet

> Site : Add the Identify website

> Custom Level…> User Authentication > Logon > Automatic logon only in Intranet Zone

Firefox:

Logging

  • Event 999 following by another event: there is a problem with LDAP Web Service Settings, the following event describes detail information of the LDAP Web Service Settings failure.
  • Event 97 : the following event describes detail information about license issue
  • Event 143 : it describes how the LDAP claims transformation failed :
    • No LDAP-WS is attached
    • The speficied filter is sufficient to uniquely identify a user so that his or her attributes and be fetched.
    • The ClaimsPrincipal didn’t contain a claim whose type is {0}. That claim is required to extract user identity to look up for more claims

One-time Password


The OTP authentication connection can only be used as second factor with another authentication connection type. The configuration settings offered for OTP are:

  • Order of factors: basically a choice between “email, sms” or “sms, email”. Specifies which one the system will preferably use to send a user his password. If the user does not have, e.g. email address, then the system would instead use
  • OTP length: Length in digits of the one-time password that is sent to the user on email or sms.
  • OTP lifetime: The time in seconds that a sent password can be used before it expires.
  • Max input attempts: The maximum number of times that a user can try to insert password on the authentication page before his authentication will be set as failed.
  • SMS claim type: The claim type that a user’s mobile number will be extracted from. The system will initially look to see if the user has a value for this claim in the local storage. If not, it will get the value from the incoming token’sexternal claim, if value exists here.
  • Email claim type: The claim type that a user’s email will be extracted from. The system will initially look to see if the user has a value for this claim in the local storage. If not, it will get the value from the incoming token’sexternal claim, if value exists here.

Yubico


Like OTP, the authentication connection for Yubikey can only be used as second factor with another Authentication Connection type. The configuration settings offered for Yubi are:

  • Client ID: The register application ID from Yubico.com.
  • API key: This is the secret code for the client ID that was register on Yubico.com.
  • Desired sync level in percent: The desired synchronization level in percentage that the validation server should reach before sending reply.
  • Nonce to be used for the next request: The value string to be used for the every request to Yubico and it will be return in the response for validation if the response is for a specific request. This value is optional. If no value is set a random nonce value will be created.
  • User agent: The value that is set in user-agent from HTTP header on the request to Yubico. This value is optional, if this is unset a value will be created to set to HTTP Header User-agent in following formation: “YubicoDotNetClient {version}” where {version} is the current version of Yubico Client that used for validation.
  • Test mode: Normally, a Yubi connection needs the specification on the whole above settings so that the Yubi can be loaded successfully. In test mode, we just need to fill some test values on the required fields. To learn more about Yubi test mode please go the chapter on Yubico Test Login Page.
Was this helpful ?Good Somewhat Bad