Add SAML Service Provider

Use this setup to add a SAML service provider (SP) application to SecureAuth CIAM. When you add a SAML application CIAM creates a client record that defines how authentication and access policies apply to that application.

This setup allows SecureAuth to enforce user authentication and control who can access the SP application. After a user signs in, CIAM checks their identity and any assigned user policy before sending a SAML assertion to the application.

Use cases

SecureAuth CIAM supports adding and protecting applications that use the SAML protocol. These applications typically rely on browser-based single sign-on (SSO) and are common across enterprise environments.

Here are some examples of how you can use CIAM to protect SAML service provider applications:

Internal business systems: Require authentication through CIAM before users access HR platforms, finance tools, or organizational applications. Apply user policies to limit access by role, group, or department.
Technical and partner-facing portals: Secure applications used by engineers, field service teams, or external partners. Use SAML attribute mappings to pass relevant identity information to the service provider.
Clinical and adminstrative systems: Protect access to Electronic Health Record (EHR) platforms, shift managment tools, and internal portals used by staff. Use CIAM to authenticate doctors, nurses, and administrators and enforce role-based access.

Before you begin

You'll need:

The SAML metadata from the application. This defines the trust connection (via URL, XML file, or manual settings).
A list of SAML attributes the application expects (such as email or username).
(Optional) A user policy if you want to restrict acccess to certain users or groups.

Note: This task involves creating a client application in CIAM that represents and protects a third-party SAML service provider (SP) application. We'll use Bluehawk as an example of a fictional SP application.

Step 1: Create the application

In the selected workspace, go to Applications > Clients.
Click Create Client.
Result: The Create Application page displays in CIAM.
Enter a name and optional application URL.
- The optional URL links to the application's login page or landing page.
- You can also use the optional URL to let SecureAuth CIAM initiate authentication for the application.
  For example, enter https://outlook.microsoft.com to enable direct access to Outlook through CIAM.
Note
Leaving the Application URL field blank does not affect SAML authentication. The application can still redirect to SecureAuth CIAM for login if configured with the CIAM IdP metadata.
For example, users can go directly to the Bluehawk application, which redirects to CIAM for authentication, even if no URL is entered.
Select SAML Service Provider as the application type.
Click Create.

Step 2: Fill in client application details in CIAM

On the Overview tab, enter the application details and optional settings.

Field	Description
Application Name	Name shown in CIAM for this client application.
Description	Optional. Short summary to help identify the application.
Application URL	Optional. URL of the SP application login page. Used for launching the SP application from CIAM. For example, enter `https://outlook.microsoft.com` to launch Outlook from CIAM.
Add Entity Info	Optional. Turn on to define custom metadata for the application. Enables the Entity Info tab.
Override SAML Attributes	Optional. Turn on to define custom SAML attributes for the application. Enables the Attributes tab

Step 3: Add service provider metadata

Go to the SAML tab. This is where you define how SecureAuth connects to the SP application.

You can provide the SP metadata in one of the three ways:

Method	Description
URL	Enter the metadata URL provided by the SP application. SecureAuth automatically imports the required connection settings, such as Entity ID and ACS URL.
XML	Upload the metadata XML file provided by the SP application. This is often used when the SP does not provide a URL.
Manual	Enter key details manually if no metadata is available. You must specify the Entity ID, ACS URL, optional signing certificate, and binding method. See below for field descriptions. Entity ID – Unique identifier for the SP application. Provided by the SP. ACS URL – Assertion Consumer Service (ACS) endpoint where SecureAuth sends the SAML assertion after login. Signing Certificate (optional) – Certificate used by the SP to validate logout requests or responses. Upload only if required by the SP. SSO Binding Method – Choose the method the SP application uses for SAML communication: Form Post – Secure and widely supported. Redirect – Uses URL parameters; required by some service providers (SP).

Reminder

After adding metadata, provide the SAML IdP metadata from CIAM to the SP application (like Bluehawk). This allows the SP to recognize SecureAuth CIAM as a trusted identity provider.

Step 4: Set Subject NameID

The Subject NameID tells the application which identifier to use for the user login; such as email or username.

SecureAuth sends this value in the SAML assertion to help the SP application recognize the user.

You can either use the default setting from your SAML IdP configuration, or override it for this specific application.

Option	Description
Use default (leave check box cleared)	SecureAuth uses the NameID value defined in your global SAML IdP Settings.
Override Subject NameID	Select this check box to define a different identifier for this application. Select a NameID format and the attribute that supplies the value (such as email or userID).

Tip

Some SP applications require a specific NameID format or attribute. Check the SP documentation or contact the vendor if unsure.

Step 5: Choose signing algorithm

On the SAML tab, scroll to the Binding Preferences section.

Select the signing algorithm SecureAuth uses to sign the SAML assertion sent to the SP application. This digital signature ensures the message is trusted and has not been altered in transit.

Option	Description
SHA-1	Not recommended. Considered insecure and deprecated.
SHA-256	Recommended. Provides strong security and is widely supported by SAML-enabled applications.
SHA-512	Stronger than SHA-256. Use only if the SP application explicitly supports it.

Step 6: Set Access Control

Go to the Access Control tab. This is where you determine which users can access the SP application through SecureAuth CIAM.

By default, access is unrestricted. You can assign a user policy to apply rules based on user groups, attributes, or other conditions.

Option	Description
Unrestricted	All users who authenticate through SecureAuth can access the SP application.
Select a User Policy	Choose a predefined user policy to restrict access. Only users who meet the policy criteria can launch and use the SP application.

Tip

User policies are managed separately in CIAM. To create or edit policies, go to Authorization > Policies in the selected workspace.

In this section: