SAML customer requirements

Security Assertion Markup Language (SAML) is an XML-based open standard for transferring identity data between two parties: an Identity Provider (IdP) and a Service Provider (SP). To configure WFO Desktop/Web applications for SAML authentication, the applications are registered with the IdP, which holds the user's credentials.

User Identifier

A User Identifier is required; it identifies the user during authentication.

Use any attribute as the subject of the assertion. For example, use the User-Principal-Name as the Name ID attribute in the Active Directory Federation Services (ADFS) IdP.

The same value used as the User identifier must then be configured in the Username field in WFO (User Management > Security > Usernames workspace).

In a multi-tenant environment, for uniqueness, use email format as the Username.

SAML certificate

When using a customer-signed SAML certificate, the customer must provide a P12 file for signing SAML requests. The P12 file must contain both the private key and the X.509 certificate. The SAML certificate can be issued with any subject or subject alternative names. This certificate is a dedicated certificate created for the WFO system to sign SAML requests.

In a single-tenant environment using Azure AD as the SAML IdP, you are not required to supply the SAML SP certificate, as Azure AD does not validate the SP signature.

Clock skew

SAML assertions can contain timestamps that specify the period for which the assertion is valid. For authentication to work correctly, the IdP and SP must agree on the same time. However, it can be difficult to ensure the clocks are in sync on the IdP and SP as these can be independent systems managed by different parties. When the clocks get out of sync, SAML authentication fails.

To avoid authentication issues resulting from server clocks becoming out of sync, it is recommended to apply a skew policy on the IdP for some tolerance on the NotBefore SAML condition.

For example, if using ADFS, the following command should be used to allow for up to a two-minute difference between system clocks:

Set-ADFSRelyingPartyTrust –TargetIdentifier “urn:party:sso” –NotBeforeSkew 2

WFO SP relying party in the IdP

Configure the WFO SP relying party in the IdP manually or by importing the SP metadata XML you received from the SP. The metadata is exported from WFO as part of the deployment procedure.

In your IdP, select the authentication methods. For example, select Forms Authentication and Certificate Authentication methods in an environment that supports both.

If configuring the IdP manually, the IdP may require some properties.

When changing the service provider properties, for example Service Provider ID, it is required to re-send the new SP-initiated metadata to all IdPs, or to change the properties manually in the IdPs. This is required so that the IdPs can communicate with the service provider based on the new properties.

Property	Description
Assertion Consumer Service (ACS)	http(s)://<WFO_Application_Server_or_Load_ Balancer_address>/saml2/sp/acs/post
Audience or Service Provider ID	Set the IdP with a short name for the WFO application (for example, WFO_SP).
Recipient	http(s)://<WFO_Application_Server_or_Load_ Balancer_address>/saml2/sp/acs/post
User Identifier	Only user identifier attribute is required with the SAML assertion. Other user attributes are not mandatory. You can use any attribute as the subject of the assertion. For example, the Name ID attribute, which is recommended to use with the ADFS IdP, is the User-Principal-Name.
Signature Hash Algorithm	Select one of the following as the secure hash algorithm to be used by the relying party trust: For V15.2 systems installed with Security Kit 7 or later, select SHA2 For earlier systems, select SHA1 NOTE: SAML token encryption is not supported.
Preferred Binding	POST
Certificates	If required by the IdP, import the root CA of the SAML certificate to the trusted CA store.

IdP SAML metadata

IdP SAML metadata XML file is required for configuring the Weblogic Identity Provider settings. Provide the IdP SAML metadata XML file to the SP.

Exchanging the metadata is done manually as part of the configuration procedure. Automatic exchange of metadata is not supported.

When changing the IdP properties, it is required to re-send the new IdP-initiated metadata to the service provider.

Desktop applications URL

Configure desktop applications with the sign-in URL based on the sign-in type: SP-initiated (default), or IdP-initiated. For the IdP-initiated URL, see Desktop Applications Deployment Reference and Installation Guide.