SAML 2.0 Application

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

The configuration settings offered by this protocol connection type are:

When Persistent Pseudonym is used, Identify offers user ability to validate that the NameIDPolicy element must be presented with the AllowCreate attribute set to true and the Format attribute set to urn:oasis:names:tc:SAML:2.0:nameid-format:persistent. If validation is enabled and the SP settings does not satisfy this, Identify will respond with a urn:oasis:names:tc:SAML:2.0:status:Responder status code to SAML service provider.
Validate if allow create is true when persistent pseudonym is used: to enable validation for AllowCreate and NameId Format, check the option
Entity ID: the entityID attribute is the unique identifier of the identity provider.

Signing certificate element specifies the signing certificate used by the protocol connection. This certificate is used by Safewhere Identify to sign the communication to the service provider. The potential elements are:

Find value: the value of the attribute that is used to specify 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 specify 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. Possible values are: CurrentUser, LocalMachine.
Store location name: specifies which certificate store the certificate is placed in.
Signing certificate is in store?: auto-set value. Checked state indicates that the certificate is found in the specified location.

Encryption certificate element specifies the encryption certificate used by the authentication connection. This certificate is used by Safewhere Identify to sign the communication to the service provider. The potential elements are:

Find value: the value of the attribute that is used to specify 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 specify 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. Possible values: CurrentUser, 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: auto-set value. Checked state indicates that the certificate is found in the specified location.

Identify currently supports up to 3 SLO bindings: HTTP-Redirect, HTTP-POST and SOAP. Those bindings are available for both protocol connection and authentication connection. If a party (SP /IdP) supports all 3 bindings, they will be imported into the respective binding sections, HTTP-Redirect must exist.

SLO bindings

Note: in order to make SOAP logout works well, the following setting in System set up must be checked as SOAP logout requires a database read for every requests coming to Runtime which obviously slows things down a little bit. Meanwhile, most of Identify deployments don’t use SOAP logout. As a result, the setting is introduced for the sake of performance optimization

Enable SOAP logout

Assertion consumer service binding: the binding that Safewhere Identify should use to send sign on responses to the involved SP. If HTTP-Artifact is used, Identify will:
- Return an artifact instead of a direct SAMLResponse message.
- Expose an artifact resolution service where a SP can use to exchange an artifact for a SAMLResponse.
Assertion consumer service location: the endpoint to which Safewhere Identify should send sign on responses.
Subject confirmation data recipient: specifies the value to set to the recipient property of assertion’s SubjectConfirmationData. Service provider can then use this value to validate if the token is meant to send to it. EntityIdentifier is used as the default value for this setting. Some SPs such as AD FS 2.0 requires that this value is set to its single sign on endpoint.
Set response’s issuer: speficies if the Issuer value of an assertion should be set which is required by some SPs.
Validate AssertionConsumerServiceUrl in AuthnRequest: when this is checked, Safewhere Identify performs validation against AssertionConsumerServiceUrl of incoming AuthenRequest messages.
Token life-time: specifies how long a token which Safewhere Identify issues remains valid. Technically speaking, it affects Conditions.NotOnOrAfter value.
Show tailored list from CDC: even when CDC is used, there may be multiple Idps are discovered from CDC. When this option is not checked, Safewhere Identify simply picks the first appropriate Idp. Otherwises, it shows all appropriate Idps in a selector page so that users can pick one.
Secure hash algorithm: identify provides support for both SHA1 and SHA256 algorithm.

The below configuration setting is offered for OIO IDWS Identify STS:

Audience restriction: list of valid entity IDs. The entity IDs are separated by ";". This audience restriction is set to the issuerthat is used to issue bootstrap token (aka ActAs token).

Safewhere Identify provides some revocation methods to determine the status of in use signing and encryption certificates. Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) are mechanisms to be used with settings are configured in the Connections detail. 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.

Safewhere Identify can function as a proxy for another identity provider. An identity provider proxy enables you to create structures of trust relationships that ultimately simplify the management of your service providers:

Enable proxy: when enabled, all the validation rules will be applied. In addition, the AuthnRequest - which Identify sends to upstream IdPs - will contain proxying attributes.
Requester Id: requester Id of the service provider. This value may be included in AuthnRequest sent to upstream IdPs when "Use the RequesterId above for proxied AuthnRequest" is ticked. It should be in the form of a URI, e.g. urn:safewhere:company:dk
Use the RequesterId above for proxied AuthnRequest: when this setting is True, the AuthnRequest, which Identify sends to upstream IdPs, will use Requester Id valueinstead of the value it gets from service provider.
Do not include authentication authorities from upstream IdPs: by default, when proxying is used, the response sendt to the original service provider needs to have AuthenticatingAuthority attribute. This option allows for omitting that piece of information.

There are 2 configuration settings for the SAML 2.0 attributes service:

Attribute name which specifies subject claim type: specifies the attribute that defines the subject claim type.
Default subject claim type: it is not possible to extract subject claim type from the request, this value will be used as subject claim type.

Requested authentication context method class is used to specify what type of authentication should be used to authenticate a user. As an SP, Safewhere Identify must check if an assertion from an Identity Provider contains any AuthenticationStatement that meets the method class it formerly specified in an AuthnRequest.

Default requested authentication context class: default value is the X509 class.
Always use default requested authentication context class: when this is set to true, assertions which Safewhere Identify return to service providers always have the default class. Default value is TRUE.
Evaluate requested authentication context: specifies if Safewhere Identify should check whether it has any authentication connection that can fulfill the requested authentication context of an AuthnRequest.
SAML response signing: specifies what parts of a log in SAMLResponse message should be signed. There are 3 options: MessageOnly, AssertionOnly, and MessageAndAssertion.
Do not encrypt assertions: specifies if issued assertions should be encrypted.
Set SessionNotOnOrAfter: a date sent to the requesting party, that specifies the date and time after which the session will no longer be valid. The value in this field is set in minutes so the value sent will be current time + SessionNotOnOrAfter.
Common Domain Cookie (CDC) section: is a secure browser cookie scoped to the common domain. For each browser user, this cookie stores a history list of recently visited IdPs. The name and value of the cookie are specified in the IdP Discovery Profile. Identify supports both read and write methods:

Settings in Identify Admin for SAML 2.0 Protocol Connection:
- To enable writer, fill in the CDC write path to "Common domain cookie writer" field When the writer is configured, the Identify IdP will append its entityID to the IdPs list of CDC after SAML SP logins successfully.
- To enable reader, fill in the CDC read path to "Common domain cookie read" field When the reader is configured, for every SAML request from this service provider, Identify will read from the CDC’s cookies and pick up the last IdP in the IdPs list for authenticating.
Note: the IdentifyCDC package can be found in the installation folder, named "CDC"

Safewhere Identify supports the multi-valued attribute rendering at the responded assertion via the setting:

Use multi-valued attribute: as default, the value for this setting is disabled and the multi-value attribute will render like below:

<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="id52cbaab4d1c2432ca753439df702639e" IssueInstant="2015-04-28T11:20:31.258Z" Version="2.0">
        …
        <AttributeStatement>
            …
            <Attribute Name="http://www.safewhereidentify.com/roles" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <AttributeValue>idp_dma_administrator</AttributeValue>
            </Attribute>
            <Attribute Name="http://www.safewhereidentify.com/roles" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <AttributeValue>idp_dma_eu-indberetter</AttributeValue>
            </Attribute>
        </AttributeStatement>
</Assertion>

But once this setting is true, you will have:

<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="id52cbaab4d1c2432ca753439df702639e" IssueInstant="2015-04-28T11:20:31.258Z" Version="2.0">
        …
        <AttributeStatement>
            …
            <Attribute Name="http://www.safewhereidentify.com/roles" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <AttributeValue>idp_dma_administrator</AttributeValue>
                <AttributeValue>idp_dma_eu-indberetter</AttributeValue>
            </Attribute>
        </AttributeStatement>
</Assertion>

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.

5551: System - Error when a certificate was expired
5552: System - Warning when a certificate is going to expire
5548: System - Information when Identify finished checking metadata and found no changes
5549: System - Information when Identify finished checking metadata and found new certificate changes
5550: System - 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.