Configure SAML authentication for Nomad server on Domino

Create an IdP configuration document for Nomad server for Domino to participate in SAML authentication.

Before you begin

  • There must be a replica of idpcat.nsf on the domino server running the nomad server task.
  • Have the metadata .xml file that you exported from your IdP, for example FederationMetadata.xml, in a location from which you can access it so that you can import it into the IdP configuration document.
    Note: If you will create another IdP configuration document, for example, for federated login with the ID vault, make a backup copy of the file; when you import the .xml file into the IdP configuration document, the .xml file is deleted from your local system.
  • It is recommended to deploy Nomad server for Domino on a hostname that is not also used by any site hosted by Domino's http task, even if on a different port. Otherwise, there is a potential for configuration collisions if SAML is configured for both.

About this task

If your Web servers are behind a load balancer or IP sprayer, create one IdP configuration document. Your IdP will connect to the load balancer or IP sprayer. If your Web servers are not behind a load balancer or IP sprayer, create a separate IdP configuration document for each Nomad server for Domino.

Procedure

  1. Open the idpcat.nsf replica on the server where Nomad server for Domino is installed.
  2. Click Add IdP Config to create a new configuration document.
  3. Click Import XML file and select the metadata .xml file you exported from your IdP. In ADFS, this file name is typically FederationMetadata.xml.
    The following information is imported from the .xml file.
    Table 1. Fields in the IdP Configuration document whose values are generated from the metadata.xml file
    Field Description
    Protocol version One of the following:
    • SAML 2.0
    • SAML 1.1
    Federation product One of the following:
    • AuthnRequest SAML 2.0 compatible
    • ADFS
    Note: Authn is a standard authentication protocol available for SAML 2.0. If your IdP is configured to support Authn, best practice is to keep AuthnRequest SAML 2.0 compatible selected.
    Artifact resolution service URL

    Domino® generates the artifact URL for the federation service you specified in the Federation product field.

    The web address (URL) in this field is created when you click the "Import XML file" button. It is the URL to which incoming requests are redirected for authentication with the IdP.

    Do not modify this text unless you are working with a metadata XML file that is not available for import into the form; in that case, be sure to copy and paste text accurately into this field.

    Single sign-on service URL If the data is available in the imported XML file, Domino® generates the login URL for the federation service specified in the Federation product field. For example, on ADFS: https://adfs.renovations.com/adfs/ls/IdpInitiatedSignOn.aspx
    Note: The value in this field is a subset of the expected URL to the IdP. The Domino® server generates the full URL when necessary.
    Signing X.509 certificate Domino® imports the certificate code from file.
    Encryption X.509 certificate

    Domino® imports the certificate code from file. If import is replacing an existing signing certificate, the previous signing certificate is saved off as an IdP legacy certificate.

    Note: This field appears only when the Type field is set to SAML 2.0.
    Protocol support enumeration Domino® generates a string designating the protocol(s) for the SAML release specified in the Type field that are also supported by the specified IdP. This string will become part of authentication URLs provided by Domino® as the service provider to the IdP specified in this configuration document.

    For example, url.oasis.names.tc:SAML:2.0:protocol.

  4. In the Basics tab > Host names or addresses mapped to this site field, configure the Nomad server for Domino DNS host name or host names.
  5. In the Service provider ID field, enter a value to identify the Nomad server for Domino as service provider partner with the IdP.
    • This value has to be a properly constructed URL but it isn't used for HTTP connections.
    • If you are using TLS (required for ADFS), specify https: in the URL.
    • This value must match the value in the IdP trust or partnership that you will create to identify the web server. For example, in ADFS, this value must match the value specified in the Relying party trust identifiers box in the Relying Party Trust.
    For example: https://nomad.renovations.com.
  6. If prompted for a Nomad Postback URL, please use the nomad host location and append /names.nsf?SAMLLogin. For example: https://nomad.renovations.com/names.nsf?SAMLLogin.
  7. In the Basics tab, IdP name field, enter a name to identify the Web site of the identity provider; the name does not have to be exact, and is only for your administrative convenience.
  8. Save and close the IdP configuration document.
  9. Optional: If you want to ensure that SAML assertions are encrypted to help protect sensitive data, complete the task Generating a certificate to encrypt SAML assertions. Complete it before you complete the task Exporting the Domino web configuration to an .xml file, so that the certificate is included in the ServiceProvider.xml file.
  10. Follow instructions in Exporting the Domino web configuration to an .xml file.
  11. Use the .xml file generated in the previous step to create the service provider config in your IDP. For examples of Active Directory Federated Services (ADFS), see Setting up a Relying Party Trust for Web servers.
  12. If you have multiple Nomad servers for Domino behind a load balancer, ensure there is a replica of idpcat.nsf on both. You will need to distribute the key that was created in the first server's ID file to the other servers behind your load balancer. Please follow the steps in Adding the Service Provider server certificate and key to other vault server ID files to export the key and then import it on the other servers. The doc was primarily written for multiple vault servers, but the basics still apply.