Create a new SAML IDP Profile#

A SAML IDP profile must be created and configured before it can be used to respond to SAML authentication requests. It is very simple to set up a SAML IDP profile using the Admin UI, the main requirement being an existing Authentication Service profile to handle user authentication.

Begin by navigating to the Admin UI, selecting “Create Profile,” and choosing the SAML IDP profile type.

Create a SAML profile in the Admin UI
Create a SAML profile in the Admin UI. (Admin UI version: 10.6)

The Setup Wizard will guide you through the necessary steps to create the profile, as well as defining and deploying an endpoint for the Single Sign On Service.

Configure a SAML IDP Profile#

The SAML IDP profile configuration is divided in the following sections:

  • General: Includes settings to manage relationship with the Authentication Service and other generic profile settings.
  • Assertion: Configure profile-wide settings for issuing SAML assertions, like if and how to sign assertions.
  • Metadata: Configure how the SAML IDP profile exposes its metadata.
  • Request Bindings: Manage which bindings the SAML IDP profile supports for receiving messages.

General Settings#

General settings of a SAML IDP profile
General settings of a SAML IDP profile. (Admin UI version: 10.6)

Authentication Service#

  • Authentication Profile Select the Authentication Service profile that the SAML IDP profile will use to authenticate users
  • Clock Skew Configure acceptable clock skew between the SAML IDP Profile and the Authentication Service profile.

Other settings#

  • Issuer Override By default, the SAML IDP profile uses the profile’s Single Sign On Service URL as issuer. It relies on the Base URL settings for the scheme/host/port path of its value. If this is not suitable, you can override the issuer value here. The issuer value is constructed by combining the Base URL (scheme, host, and optional port) with the deployed SSO endpoint path and the /metadata suffix, unless an Issuer Override is defined, in which case the override value is used instead.

Assertion Settings#

Assertion settings of a SAML IDP profile
Assertion settings in SAML IDP profile. (Admin UI version: 10.6)
  • Time to Live The number of seconds an assertion will be valid. This can be overruled by individual service provider configuration.
  • Signing KeyStore The key to sign assertions. If not set, assertions will not be signed.

When a signing key is set, this key must also contain a certificate with the verification key (and not just a public key). When a signing key is set, both the assertion as well as the response will be signed with that key.

Metadata Settings#

Metadata settings of a SAML IDP profile
Metadata settings in SAML IDP profile. (Admin UI version: 10.6)
  • Expose Metadata When enabled, the metadata is published at the SSO endpoint with /metadata appended to the path, and it can be used by SAML Service Providers to discover the SAML IDP Service and to configure their interactions with it.

For example, if the Curity instance is hosted at https://idp.example.com, and the SSO endpoint is deployed at /idp/sso, then the metadata (when enabled) is published at https://idp.example.com/idp/sso/metadata.

Notice that the default EntityId in this case is https://idp.example.com/idp/sso/metadata.

Request Bindings Settings#

Request binding settings in SAML IDP profile
Request binding settings in SAML IDP profile. (Admin UI version: 10.6)

SAML request bindings define how a Service Provider (SP) sends an authentication request (AuthnRequest) to the Single Sign-On (SSO) endpoint. The Curity SAML IdP supports the standard SAML 2.0 front-channel bindings. You can enable one or both bindings to meet your interoperability and security requirements.

HTTP-Redirect binding the authentication request is sent to the SSO endpoint through a browser redirect.

HTTP-POST binding the authentication request is submitted to the SSO endpoint using an HTML form.

Request bindings are configured at two levels: the SAML IdP profile and the Service Provider. The profile defines which bindings are permitted for the SSO endpoint (for example, HTTP-Redirect and/or HTTP-POST). Each Service Provider specifies which binding or bindings it will use. A binding configured for a Service Provider must also be enabled in the profile; otherwise, requests using that binding are rejected.

Was this helpful?