Service Providers

A SAML Service Provider in the Curity Identity Server represents the application or service that requests authentication from the SAML Identity Provider (IdP).

Example Service Provider
An example Service Provider in the Admin UI. (Admin UI version: 10.6)

A Service Provider is typically an application or system that relies on the IdP to authenticate users and to obtain SAML assertions containing verified identity information and, optionally, user attributes.

The SAML IdP Service in the Curity Identity Server can be configured to interact with multiple Service Providers simultaneously. Each Service Provider is defined by a distinct configuration and identified by a unique Entity ID, which serves as a globally unique identifier within SAML protocol exchanges. This ensures proper routing, validation, and trust management across federated systems.

When a user attempts to access a Service Provider application, the Service Provider initiates an authentication request and redirects the user to the Curity Identity Server, acting as the SAML Identity Provider. Upon successful authentication, the Curity Identity Server issues a digitally signed SAML assertion containing authentication statements and any configured user attributes. The assertion is then returned to the Service Provider, which validates the signature, extracts the necessary identity data, and establishes a local session.

Through this trust relationship, the Curity Identity Server provides centralized authentication and identity management, enabling Service Providers to delegate authentication securely while maintaining compliance with SAML 2.0 standards and best practices.

Service Provider Configuration#

Service Providers in the Curity Identity Server have numerous configuration options that control their behavior. These settings ensure proper communication and security between the Identity Provider and Service Provider. Key configuration aspects include:

Entity ID and Assertion Consumer Services#

Each Service Provider has an Entity ID that uniquely identifies it in SAML messages. The Assertion Consumer Services (ACS) are the endpoints where the SAML IDP Service sends SAML assertions (i.e. SAML Response messages). Each ACS is defined by:

  • URL: The endpoint where the SAML response will be sent
  • Binding type: How the SAML response will be transmitted (HTTP POST, HTTP Redirect, etc.)
  • Index: An identifier that can be used by a Service Provider in an authentication request to indicate the preferred response destination

Assertion Issuance#

When issuing assertions to Service Providers, several options control the assertion’s properties:

  • Time To Live (TTL): The number of seconds that an assertion is valid after it is issued
  • NameID Format: The format of the NameID element in the assertion
  • Audience: The value used as the Audience in the assertion (defaults to the Service Provider’s Entity ID if not configured)

These settings ensure that assertions are secure, properly scoped, and valid for the appropriate time period.

Attributes#

The attribute configuration for a Service Provider defines which attributes are included in the SAML assertions sent to that Service Provider. The attributes can be established during user authentication or resolved by the SAML IDP Service when the assertion is issued.

The configuration allows you to select both attribute groups, as well as individual attributes:

  • Attribute Groups: When selected, all attributes in the group are included in the assertion
  • Individual Attributes: Can be selected for fine-grained control over attribute release

When an attribute is selected (either as part of a group or individually), it will only be included once in the assertion. Attribute groups serve as a convenient way to manage related attributes together.

Service Provider Types#

The Curity Identity Server supports multiple approaches for storing and managing SAML Service Providers, depending on your deployment needs:

  • Configuration Service Providers — Service Providers defined directly in the system configuration. This option is ideal for controlled or static environments tut is limited to 100 Service Providers.
  • Database Service Providers — Service Providers stored in an external database. This option is suitable when you need dynamic or large-scale Service Provider management.

Database Service Providers#

When the number of Service Providers grows beyond a few dozen, or when you need to manage them through an external system, SAML Service Providers can be stored in a compatible Data Source. In this model, Service Providers are not stored in the Curity Identity Server‘s configuration.

Modifying Service Providers directly in the database instead of using the GraphQL API or the Admin UI can cause the Service Providers to become invalid, and hence inaccessible from the Curity Identity Server.

Removing Curity configuration that is used by Database Service Providers (e.g. attributes) without updating the affected Service Providers may also cause problems. Care must be taken to update Curity configuration and Database Service Providers in tandem to make sure there is always consistency between them.

Configuring a Data Source#

The first thing to do to enable Database Service Providers is to configure a Data Source for storing Service Providers in the SAML IdP Profile.

In the Admin UI, you can find the Database Service Providers section under the SAML IdP Profile’s General page.

Example Database Service Provider
An example configuration of Database Service Provider in the Admin UI. (Admin UI version: 11.0)

Managing Database Service Providers#

Once enabled, Database Service Providers can be managed through:

  • The Admin UI
  • The GraphQL API (requires configuring a GraphQL endpoint and authorization access)

Managing Database Service Providers in the Admin UI#

After enabling Database Service Providers, you can create and manage them directly through the Admin UI in the Database Service Providers section of your SAML IdP Profile.

Managing Database Service Providers via GraphQL API#

The GraphQL API provides a flexible way to create, read, update, and delete database Service Providers programmatically. To use the GraphQL API:

  1. Create an endpoint of type saml-service-provider-graphql-api in the SAML IdP Profile
  2. Configure linked OAuth Profile in the SAML IdP Profile, the linked OAuth profile is used to validate the access tokens that are sent with GraphQL requests
  3. Configure an appropriate Authorization Manager in the SAML IdP Profile to authorize users to access the API

The GraphQL API is self-documented. Check the GraphQL APIs documentation for more information about using Curity‘s GraphQL APIs and obtaining the full GraphQL schema.

Was this helpful?