SAML 2.0 login method

SAML 2.0 is a popular data format for communicating claims between a claims provider and a service provider.

The configuration settings offered by this Authentication Connection type are:

  •  Entity ID: The entityID attribute is the unique identifier of the identity provider.

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 SAML 2.0 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 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.

This signing certificate element specifies the signing certificate used by the Authentication Connection. This certificate is used by Safewhere*Identify to sign the communication to the Identity Provider. The potential elements are:

  • Find value: The value of the attribute that is used to Safewhere*Identify the certificate, e.g. its subject or thumbprint.
  • Get certificates button: Allow users to select a new certificate.
  • 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.Possible values are: FindByThumbprint, FindBySubjectName, FindBySubjectDistinguishedName, FindByIssuerName, FindByIssuerDistinguishedName, FindBySerialNumber, FindByTimeValid, FindByTimeNotYetValid, FindByTimeExpired, FindByTemplateName, FindByApplicationPolicy, FindByCertificatePolicy, FindByExtension, FindByKeyUsage, FindBySubjectKeyIdentifier.
  • Store location: The location of the certificate store to use.Value can beCurrentUser or LocalMachine.
  • Store name: Specifies which certificate store the certificate is placed in. Possible values are: AddressBook, AuthRoot, CertificateAuthority, Disallowed, My.
  • Encryption certificate is in store?: read-only checkbox, checked state means the certificate must be in above store.
  • Single log off service binding: the binding that Safewhere*Identify should use to send log off requests to the involved Identity Provider. In Safewhere*Identify, it is usually either “urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” or “urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”.
  • Single log off service location: the endpoint to which Safewhere*Identify should send log off requests.
  • Single log off service response location: the endpoint to which Safewhere*Identify should send responses for log off requests that I received from the Identity Provider.
  • Single sign on service binding: the binding that Safewhere*Identify should use to send sign on requests to the involved Identity Provider.
  • Single sign on service location: the endpoint to which Safewhere*Identify should send sign on requests.
  • Below are settings for artifact resolution:

saml 1

Note: in Identify, HTTP-POST will be the default binding whose index is 0 so that when exchanging metadata with in Identity Provider, IdP needs to update setting to use the correct HTTP-Artifact binding and Location.

saml 2

  • Default name id format: Dropdown list to specifies the default format for NameId claim. Currently “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”, “urn:oasis:names:tc:SAML:2.0:nameid-format:persistent” and “urn:oasis:names:tc:SAML:2.0:nameid-format:transient” formats are supported.

   Please be noted that when importing metadata, if the nameid is not in above formats, “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified” is used by default.

  • Always override with default NameIdFormat: When a token that Safewhere*Identify receives from an Identity Provider has NameId format set and this is checked, glossary]Safewhere*Identify[/glossary] ignores a token’s NameId format and uses the default value.
  • Use if no NameIdFormat is specified: When a token that glossary]Safewhere*Identify[/glossary] receives from an Idp does not have NameId format set and this is checked, glossary]Safewhere*Identify[/glossary] uses the default value.
  • Set assertion consumer service Url to AuthnRequest: When this is checked, glossary]Safewhere*Identify[/glossary] sets a value to AuthnRequest’s AssertionConsumerServiceUrl property. Otherwises, the property is left empty. Some specific Idps require this property must be set. Default value is FALSE for backward compatibility.
  • Validate subject confirmation data recipient: Safewhere*Identify defines an endpoint which is responsible for receiving sign on SamlResponse messages from Idps. When this is checked, Safewhere*Identify validates if recipient value of SubjectConfirmationData of a sign on Saml response matches to that endpoint.
  • Secure hash algorithm: Identify provides support for both SHA1 and SHA256 algorithm.

The below configuration settings offered by this Authentication Connection type allow for assurance level support. Below each of these are explained.

  • Set RequestedAuthnContext to AuthnRequest: When ticked and when an AuthnRequest received from a service provider contains RequestedAuthnContext classes, Identify will set the context classes – which it sends to upstream IdP - to ‘AuthnRequest’.
  • Authentication context method class mapping:Allows for mapping requested method classes received from a service provider to method classes to be sent to the Identity Provider. The values on the dropdownlist are fetched from the supported authentication context class method on Identify.

saml 3

For example: We have the pair of values: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient

This means when the AuthnRequest from the service provider has the context class = “urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport”, Identify will send an AuthnRequest to the Identity Providerwith class set to“urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient”.

Note: when there is no authentication context class method added on Identify, this option will not display.Safewhere*Identify provides some revocation methods to determine the status of inuse signing and encryption certificates. Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) are mechanisms to be used with settings configured in eachconnection. Revocation Checks can be set for:

  • Signing certificate revocation check
  • Encryption certificate revocation check

The values that can be set for the above are:

  • None: Revocation checking is done.
  • CheckEndCert: Revocation checking is done on the end certificate and only the end certificate.
  • CheckEndCertCacheOnly: Revocation checking is done on the end certificate and only the end certificate. Revocation checking only accesses cached URLs.
  • CheckChain: Revocation checking is done on all of the certificates in every chain.
  • CheckChainCacheOnly: Revocation checking is done on all of the certificates in every chain. Revocation checking only accesses cached URLs.
  • CheckChainExcludeRoot: Revocation checking is done on all certificates in all of the chains except the root certificate.
  • CheckChainExcludeRootCacheOnly: Revocation checking is done on all certificates in all of the chains except the root certificate. Revocation checking only accesses cached URLs.

Another requirement of eGov 2.0 profile in regarding to RequestedAuthnContext is that SP implementations also MUST support the acceptance/rejection of particular <saml2:AuthnContext>content based on the identity of the Identity Provider. In Safewhere*Identify, this requirement is translated to “the ability to reject particular <saml2:AuthnContext> based on Saml2 authentication connection” and is implemented as such. Saml2 authentication is added a new setting which can be used to specified a list of authentication context method classes which Safewhere*Identify rejects when evaluating assertions the corresponding Identity Provider. Multiple classes can be set to the setting. In that case, “;” is used as the separator. For example,  let’s assume we have a connection to ADFS 2.0 and on the ADFS side we log in by using the default login page against AD. Its returning assertion will have one AuthenticationStatement whose class is PasswordProtectedTransport. Now that if we configure the connection to reject PasswordProtectedTransport method, the response will become invalid to Safewhere*Identify.

  • Rejected authentication context method classes: As above described, an array of classes seperated by semi-colon.
  • Federated session lifetime (minutes): Specifies how long a federated session which is established when a user uses this authentication connection to log in.
  • Always override SessionNotOnOrAfter with federated session lifetime: Tokens which Safewhere*Identify receives from an Idp may have SessionNotOnOrAfter set. This value specifies the time point which login session expires. If the setting is not checked, Safewhere*Identify will obey token’s SessionNotOnOrAfter when it establishes a federated session. Otherwises, it will use the value which is specified by the Federated session lifetime setting.
  • 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.
  • Supports automatic selection of authentication connection: check it to enables the Auto HRD mechanism for this authentication connection.
  • Authentication status checker path: path to checker script which is called to process Auto HRD mechanism.

Metadata status settings (from version 5.5):

Monitor metadata: enable to check the metadata's certificate(s) every x minute(s) where x is set by Metadata monitoring interval (minutes). The check will only be performed when metadata is uploaded from URL. Some events will also be logged if system detects issue in metadata.
  • 5551System - Error when a certificate was expired
  • 5552System - Warning when a certificate is going to expire
  • 5548System - Information when Identify finished checking metadata and found no changes
  • 5549System - Information when Identify finished checking metadata and found new certificate changes
  • 5550System - Information when Identify automatically updated metadata for a connection
Automatically update metadata: check to allow system to automatically update metadata when detecting certificate changed from external system. It requires Monitor metadata is enabled as well.
Metadata monitoring status: status of last check updated by system when is Monitor metadata enabled. Default value is Unspecified.
  • Unspecified: This default status indicates that the job has not been run since the last time the connection is saved manually (aka not by the monitoring job). A connection in this status is displayed in WHITE color.
  • Updated – This status indicates that the connection has been updated with latest metadata by the job successfully, and that all certificates of the connection are updated. The connection is displayed in GREEN color.
  • Inaccessible: This status is applied when an error occurs when monitoring and updating metadata automatically. It could be that a metadata url is inaccessible or metadata content cannot be parsed and updated to connection. The connection is displayed in RED color.
  • OutOfDate: This status only applied when the Monitor metadata setting is turned on but the Automatically update metadata is turned off, the job monitors metadata and finds out that it has been changed. The connection also is displayed in RED color in this case.