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 enables login from mobile devices.

Noted: Microsoft Internet Explorer 8 (IE8) is no longer supported as it does not handle JavaScript adequately, resulting in errors when users try to log in with NemID. NemID users are recommended to use a newer version of IE or another browser from now on.

  • Multiple Issuing CAs are now supported, as mentioned in the NemID TU13 package (please refer to DanID's 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 a second factor from the different Authentication Connections 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 essentially setting up two-factor authentication), the two connections may try to identify the incoming user based on two different identity-bearing claims. This dropdown is activated when the user selects that the connection will have a second factor. The options in the dropdown are:

    • Use the first identity: The system will disregard the "Identity bearing claim" value of the second factor and 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 want the Authentication Connection to be used only as the second factor for other connections and not offer it to users as a primary connection option, check this checkbox.

  • Ignored by second factor roles claim type: If there are subsets of users that you want to allow logging in without authenticating using the second factor, you must specify these users based on a rule. The rule states that 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 "Ignored by second factor roles" setting specifies which roles will be ignored. Safewhere Identify will search in both the received assertion and local store.

  • Ignored by second factor roles: This is a list of roles (claim type values) that a user must have at least one of to avoid authenticating via the second factor. Use a colon as a separator 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 that the applet should use. Recommended value: OpenLogon2

  • Include Raw Cert: If checked, Safewhere Identify will append a claim with the name "urn:oid:1.3.6.1.4.1.1466.115.121.1.8" and the value as the raw data of the user's certificate.

  • Find Value: The value of the attribute used to identify the certificate, such as its subject or thumbprint.

  • Find Type: Specifies which certificate attribute will be used to 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 is established when a user logs in using this authentication connection.

  • Enabled for mobile use: Check this if you want to allow mobile users to authenticate using this connection.

  • IP-based filter for Home Realm Discovery: Specifies the IP addresses of RPs (Relying Parties) for the filter. An IP address consists of 4 sections of numbers between 1 and 255, separated by dots. An IP range consists of two IP addresses separated by a dash. You can enter multiple IP addresses or IP ranges by separating them with semicolons. Example: 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: Check this if you want to allow users to return to the Selector page to select another authentication connection when on the login page. When this option is enabled, a link "Return to login selector page" will be displayed.

  • OpenOces applet endpoint: Points to the key file client URL. Recommended value: https://codefileclient.danid.dk/.

  • Challenge: Specifies the exact type of authentication challenge used in the applet (choice between "DanID PID-CPR Response" and "DanID CPR to PID match").

  • OpenOces environment: specify the NemID user environment. Recommended values:

    • OcesIDanidEnvPreProd: test environment.
    • OcesIDanidEnvProd: production environment.

For logging in using the key file ("Login with NemID key file" tab), there are additional settings:

  • 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 user has 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 user has a Serial number that matches this filter value.

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

  • Enable WhoIsLRA check: Checks if the user is set as an Administrator for the company they work for 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: Allows the 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 certificates 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 careful not to use spaces between the zip_file_names.