SAML SSO

Centralized authentication made easy with SAML-based SSO

• What is SSO SAML?
• How SAML SSO Is Set Up
• Self-Service SSO Setup in AlphaSense
• SAML SSO FAQs

What is SAML SSO?

Single Sign-On (SSO) is an authentication method that lets users access multiple applications using a single set of login credentials. After users sign in once, they can move between connected systems without logging in again.

SAML (Security Assertion Markup Language) is an open standard used to implement SSO, especially in enterprise environments.

How SAML-Based SSO Works

• The Identity Provider (IdP) handles user authentication.
• The Service Provider (SP) trusts the IdP to verify identities.
• After a user signs in through the IdP, the IdP sends a SAML assertion to the SP to confirm the user's identity.

Benefits of SAML SSO

• Centralized authentication and security
• Fewer passwords for users to manage
• Consistent policy enforcement (e.g., password complexity, MFA)
• Improved user experience across applications

How SAML SSO Is Set Up

A SAML (Security Assertion Markup Language) Single Sign-On (SSO) integration connects two systems:

• Service Provider (SP): The application users want to access (e.g., AlphaSense).
• Identity Provider (IdP): The system that verifies user identities (e.g., Okta, Azure AD, OneLogin).

Establishing Trust Between SP and IdP

To enable secure communication and user authentication, the SP and IdP exchange metadata:

SP → IdP:

The Service Provider (AlphaSense) sends:

• Assertion Consumer Service (ACS) URL – where it receives authentication responses.
• Entity ID – a unique identifier for AlphaSense as a service.
• Supported bindings – supported protocols for communication (e.g., HTTP-POST).

IdP → SP:

The Identity Provider responds with metadata that includes:

• IdP Entity ID – the IdP’s unique identifier.
• SSO URL – the endpoint where authentication requests are sent.
• Signing certificate – used to verify the authenticity of SAML assertions.

Result: A Secure Connection

This metadata exchange forms a trusted relationship. Once configured:

• The IdP authenticates users.
• The SP accepts authenticated sessions, allowing users to access the application without logging in again.

Self-Service SSO Setup in AlphaSense

AlphaSense offers a Self-Service SSO setup feature that allows your organization to configure Single Sign-On independently, with minimal involvement from AlphaSense.

These guides offer step-by-step instructions for completing the metadata exchange process, making it simple for your administrators to establish and manage the SSO connection.

Getting Started with SAML SSO

To begin setting up Single Sign-On (SSO) with AlphaSense, select the guide that matches your Identity Provider or configuration preference:

• First Time SAML SSO Set Up
• Update Existing SAML Connection 

SAML SSO FAQs

What is an SSO Admin?

• The SSO Admin is a user in your organization with access to the AlphaSense SSO Admin tool. This person can:
  • Enable, update, or disable your company's SSO configuration.
  • Manage the SSO setup directly within the AlphaSense portal

What is an IdP Admin?

• The IdP Admin manages your organization's Identity Provider (IdP), such as Okta or Azure Active Directory (Azure AD). This person is responsible for:
  • Setting up the AlphaSense SSO application in your IdP.
  • Providing metadata required for SSO configuration.
• In many organizations, the same person can serve as both the SSO Admin and the IdP Admin.

Who should be assigned as the SSO Admin?

• Any user with an AlphaSense account who is responsible for managing SSO settings can be the SSO Admin. They should be able to coordinate with the IdP Admin to:
  • Ensure accurate setup and updates.
  • Provide the required metadata.
• If your IdP Admin will also serve as the SSO Admin, but does not yet have an AlphaSense account, AlphaSense can create a non-paying user profile so they can serve as the SSO Admin.

How do we enable the SSO Admin role for a user?

• Contact your AlphaSense representative. Our team will assign the SSO Admin role to the designated user.

Can users bypass SSO and use a username and password?

• No. Once SSO is enabled, all users must log in through your Identity Provider. Standard username-password login is disabled to protect your organization’s security.

Which Identity Providers (IdPs) are supported?

• AlphaSense supports any IdP that implements the SAML 2.0 protocol, including:
  • Okta
  • Azure Active Directory (Azure AD)
  • Other SAML 2.0-compliant providers

How do we set up AlphaSense SSO in Okta or Azure AD?

• Your IdP Admin should complete this setup. AlphaSense provides step-by-step guides for:
  • Okta
  • Azure AD

Can we temporarily disable SSO?

• Yes. The SSO Admin can:
  • Temporarily disable SSO by toggling off the SSO Status switch in the SSO Setup page.
  • Permanently remove SSO by clicking Remove SSO—this action is irreversible and will affect all users.

Does AlphaSense support SSO testing in a development or sandbox environment?

• No. AlphaSense does not provide access to a development or sandbox environment. However, you can test the real connection before enabling it for users, and you can enable or disable SSO in your production account at any time using the Self-Service tool.

Does AlphaSense support IdP-initiated login?

• No. AlphaSense does not support IdP-initiated login due to security concerns.
• IdP-initiated login can bypass important Service Provider (SP) security checks and open the door to certain types of attacks. For security reasons, only SP-initiated SAML login is supported.

What are the AlphaSense entity ID and reply URL (ACS URL)? Are they different from the values used in the old SSO connection?

• Yes. You will receive a different entity ID and ACS URL. These values are customized and unique to your organization, so there are no predefined values. You will be able to view the values for your connection in our self-service portal when you initiate the setup process.

As we migrate from the old SSO system to the new SSO system, should we update the new IdP application with the new values?

• We recommend keeping the old IdP application intact for several weeks after you migrate. If there are any issues with the new SSO connection, you can revert to the old SSO connection with one click by turning off the SSO status switch on the SSO Setup page.
• The old IdP application can serve as a baseline so you can keep user assignments and customized usernames or NameIDs the same across both applications, if needed.