Connect NemLog-in with SAML 2.0 up-party
You can connect FoxIDs to NemLog-in (Danish IdP) with a SAML 2.0 up-party and let the users authenticate with MitID. NemLog-in is connected as a SAML 2.0 Identity Provider (IdP).
By configuring an SAML 2.0 up-party and a OpenID Connect down-party FoxIDs become a bridge between SAML 2.0 and OpenID Connect. FoxIDs will then handle the SAML 2.0 connection as a Relying Party (RP) / Service Provider (SP) and you only need to care about OpenID Connect in your application. If needed, you can possibly select multiple login option (up-parties) from the same OpenID Connect down-party.
FoxIDs support NemLog-in and the SAML 2.0 based OIOSAML3 including single logout (SLO), logging, issuer naming, required OCES3 (RSASSA-PSS) certificates and it is possible to support NSIS.
You can test NemLog-in login with the online web app sample (sample docs) by clicking
Log inand then
Danish NemLog-in TESTfor the test environment or
Danish NemLog-infor production.
Take a look at the NemLog-in sample configuration in FoxIDs Control: https://control.foxids.com/test-corp
Get read access with the user
[email protected]and password
TestAccess!then select the
The sample is configured with a separate track for the NemLog-in SAML 2.0 integration.
- The NemLog-in development portal with documentation
- Create OCES3 production certificate in the certificate administration
- The NemLog-in administration portal where you configure IT-systems
- Test environment
Transform the DK privilege XML claim to a JSON claim.
Consider separate track
NemLog-in requires the Relying Party (RP) to use a OSES3 certificate and extensive logging. Therefore, consider connecting NemLog-in in a separate track where the OCES3 certificate and log level can be configured without affecting anything else.
You can connect two tracks in the same tenant with a track link.
NemLog-in requires all requests (authn and logout) from the Relying Party (RP) to be signed. Furthermore, NemLog-in requires the RP to sign with a OCES3 certificate. It is not possible to use a certificate issued by another certificate authority, a self-signed certificate or a certificate issued by FoxIDs.
OCES3 test certificates are use in the test environment and OCES3 production certificates are used in production. An OCES3 certificate is valid for three years. After that, it must be updated manually.
You will need separate FoxIDs tracks to handle the test and production environments respectively. The tracks can optionally be combined in an app track with track links.
.P12file fails to load in FoxIDs, you can convert it to a
.PFXfile with the FoxIDs.ConvertCertificateTool.
.P12 OCES3 certificate in FoxIDs Control Client:
- Select (or create) the track to be used for NemLog-in
- Select the Certificates tab
- Click the arrow down on the Swap certificate button and then in the Contained certificates section click Change container type
- Then click on the primary certificate, then write the password and upload the
It is subsequently possible to add a secondary certificate and to swap between the primary and secondary certificates.
Configuring NemLog-in 3 as Identity Provider (IdP)
You need to configure the OCES3 certificate before following this guide.
1) - Start by creating an SAML 2.0 up-party in FoxIDs Control Client
- Select the Parties tab and then the Up-parties
- Click Create up-party and then SAML 2.0
- Add the name
- Select show advanced settings
- Select the dot URL binding pattern
- Set the session lifetime to 1800 (30 minutes) in the Logout session tab
- Go back to the SAML tab
- Disable automatic update
- Click Read metadata from file and select the NemLog-in IdP-metadata
- Configure a custom SP issuer, the issuer can optionally start with
- The issuer in this example is
- The issuer in this example is
- Optionally remove the
*and configure claims, the following claims is most often used:
- optionally include the privilege claim, see step 3)
- In production only! Set certificate validation mode to
Chain trust(if the OCES3 certificate is global trusted) and revocation mode to
- Select to include the encryption certificate in metadata
- Set the NameID format in metadata to
- Add an attribute consuming service in metadata and add the service name.
- Add all the claims configured in step 11 as requested attributes with the format
urn:oasis:names:tc:SAML:2.0:attrname-format:uri. Optionally set each attribute as required.
- Add at least one technical contact person
- Click create
- Go to the top of the SAML 2.0 up-party
- Download the SAML 2.0 up-party SP-metadata, in this case https://foxids.com/test-corp/nemlogin-test/.nemlogin./saml/spmetadata.
- The SP-metadata file is used to configure the NemLog-in IT system.
2) - Then go to the NemLog-in adminstration protal
First you need to create an NemLog-in IT-system or have someone else creating an NemLog-in IT-system and assign you access.
- Select the IT-system
- Click upload metadata file and upload the SAML 2.0 up-party SP-metadata file
- Go back to the IT-system
- Click the button Save the technical details
- Click Provision to integrationtest and then click Apply for integration test
To configure production you need to upload a test report, have it approved and then repeat the FoxIDs and NemLog-in configuration.
3) - Optionally - add privilege claim transformation in FoxIDs Control Client
Optionally, if you are using the privilege claim.
FoxIDs can transform the DK privilege XML claim to a JSON claim. It is recommended to add the transformation in order to obtain smaller claims and tokens. Furthermore, it makes the tokens readable.
- Add the DK privilege claim transformer.
- Remove the original privilege claim from the claims pipeline.
4 - Add SAML 2.0 claim to JWT claim mappings in FoxIDs Control Client
FoxIDs internally converts SAML 2.0 clams to JWT claims. NemLog-in / OIOSAML3 defines a set of SAML 2.0 claims where JWT mappings need to be added.
- Go to the Settings tab and Claim mappings
- Add mappings for all the claims configured in step 1.11, optionally also include mapping for the privilege claim, you can create you own short JWT claim names
- Click update
The SAML 2.0 up-party can now be used as an up-party for down-parties in the track.
NemLog-in requires requests and responses to be logged including the signature proof and stored for half a year (180 days). It is also required to log which identity has login and logout of which session, at what time and the IP address.
FoxIDs default log errors and events including the time and the IP address.
With an Enterprise plan on FoxIDs.com log data is stored for 180 days. If you are using a Free or Pro plan, you can send logs to your own Application Insights with a log stream and thereby save the logs for 180 days.
It can be configured which logs should be logged to the Application Insights which is part of the FoxIDs installation or to an external repository with a log stream.
The log level NemLog-in require is configured in the FoxIDs log settings:
log info trace
log claims trace
log message trace
- Click update
Request authentication context
You can request a desired NSIS assurance level as an authn context class reference.
Possible NSIS assurance levels:
You can likewise specify ID type as an authn context class reference.
Possible ID types:
And possible credential types:
In the case you need to provide different sets of authn context class references. You need to create multiple SAML 2.0 up-parties connected to NemLog-in as different IT systems.
E.g., if you need to support step-up authentication. Then you would create one SAML 2.0 up-party with authn context class reference
https://data.gov.dk/concept/core/nsis/loa/Substantial and another SAML 2.0 up-party with authn context class reference