Authentication Provider
Last updated
Last updated
The Access Manager web service allows you to choose one of several different types of authentication providers. It is recommended to use modern authentication using a mechanism such as OpenID Connect, where an identity provider can provider high assurance authentication utilizing passwordless or multi-factor authentication.
Access Manager supports modern identity providers such as Azure AD and Okta out of the box.
OpenID Connect is the preferred authentication provider. Coupled with a modern IDP like Azure AD or Okta, you can provide strong authentication to your application, backed up by multi-factor authentication. See the guides for setting up Access Manager to work with Azure AD or Okta.
Using OpenID Connect requires that your identity provider pass a upn claim containing the on-premises Active Directory UPN of your users.
WS-Federation can be used to delegate the authentication process to an on-prem ADFS or similar product. Read the setup guide for configuring Access Manager to work with ADFS.
Using WS-Federation requires that your identity provider pass a upn claim containing the on-premises Active Directory UPN of your users.
Certificate-based authentication is provided by Access Manager, with the optional support for requiring smart-card authentication.
Certificates must contain a principal name attribute in their Subject Alternative Names which specifies the user's UPN as found in Active Directory.
Limited support is available for use of altSecurityIdentities in cases where certificates are used without a UPN, however these are not supported outside the forest where AMS is located.
Specify any custom EKUs that must be present in the certificate for the authentication to be successful.
You must select how you want to validate the certificate issuer. Note that no matter which validation option is selected, at a minimum all certificates must be validated up to a trusted CA on the machine that runs AMS.
Use this option to only require that the certificate was issued by an issuer trusted by this machine. This option isn't recommended, as any CA could potentially issue a certificate that you may trust.
NTAuth storeActive Directory Enterprise CAs are automatically registered in the directory itself as trusted issuers. CAs in the Enterprise NTAuth store are trusted to issue logon certificates within the domain. If you select this option, then only certificates issued by one of these CAs are trusted. (Recommended options for smart card certificates)
This option allows you to import a specific certificate authority's certificate that must be present in the certificate chain for it to be accepted. This can be a subordinate CA, rather than a root certificate. You can add multiple trusted issuers to this list, but only one of them needs to be present in the client's certificate chain.
The Integrated Windows Authentication (IWA) provider allows users to login with NTLM or Kerberos authentication. In order to use kerberos, the web site host name must be registered on the SPN of the computer object (not the service account). Eg if using a hostname of accessmanager.lithnet.io, you'll need to register the SPN http/accessmanager.lithnet.io or host/accessmanager.lithnet.io. If the host name matches the AD computer name, then no additional SPNs are required.
Select one of the following authentication options
Basic: Uses basic authentication (username/password) - Not recommended
NTLM: Use NTLM authentication only
Negotiate: Use kerberos if possible, otherwise fall back to NTLM
Specify the users and groups that should be allowed to log into this service, or leave the field blank to allow anyone who successfully authenticates to login
