From version 4.2, two major changes were introduced:
- 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:188.8.131.52.4.1.14184.108.40.206.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 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.
There are furthermore some settings that set up the option of logging in using the key file (the “Login with NemID key file” tab):
- 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.