Skip to main content
Version: v1.7.0

Login With SSO

AlphaSense is designed to seamlessly integrate with the majority of SSO providers. Among those, below are SSO providers that have been verified as a plug-and-play solution, ensuring effortless compatibility and streamlined deployment.

Future updates will provide guide to incorporate additional SSO providers, primarily focusing on verification and will be available upon customer request.

warning

Upon succesful SSO setup, your SuperAdmin account will lose its access to the platform. To prevent this, it is recommended to assign Admin User License to other users in advance by following the Manage Admin User Licenses guide.

This will ensure these users retain full administrative privileges to manage your AlphaSense product, providing seamless access to the platform even after SSO is configured.

Configure SSO service​

To configure SSO, a Kubernetes secret in platform namespace with values for below needs to be created.

1. SAML Entity ID​

saml-entityid is the ID of AlphaSense's metadata. It should be unique especially when you already have SSO configured in the multi-tenant SaaS platform. The recommended value for the entityId is the domain of the environment, e.g., alphasense.ad.companyname.com. You can find it here under sector 8.3.6 Entity Identifier of the SAML 2.0 specification.

2. SAML URL Alternative Context Paths​

info

This SAML URL alternative context paths configuration is optional and only required in specific below use cases. It can be excluded in executing commands if not applicable.

saml-url-alternative-context-paths is the configuration used to support cases where the base URL in the SAML message differs from the URL of the sso-ws service itself. This can occur if the cluster has multiple domain names or if the URL configured within the IdP is a customized URL that differs from the original one. You can find it as a part of attribute AssertionConsumerServiceURL under sector 3.4.1 Element of the SAML 2.0 specification. This was named as Single sign-on URL in Okta or Reply URL in Microsoft Entra ID.

Use Case 1:​

  • Customer is having sso-ws deployed in their own private domain - the cluster domain name in the Configuration step.
  • Whereas the IdP configuration requires public access (i.e., it needs to be configured with a public domain).

This creates a mismatch between the allowed domain in sso-ws and the included domain in the IdP's SAML message. So these URLs need to be added in SAML alternative context paths.

Example:

  • Public endpoint: a1.b.c/saml
  • Private endpoint: a2.b.c/saml
  • Alternative URL context paths: a1,a2

Use Case 2:​

After internal changes from service side, base URL of sso-ws service will be updated, but the customer's IdP is still configured with the old URL. So these URLs need to be added in SAML alternative context paths.

Example:

  • Old SAML endpoint: a.b.c/sso-ws-v1/saml
  • New SAML endpoint: a.b.c/sso-ws-v2/saml
  • Alternateive URL context paths: sso-ws-v1,sso-ws-v2

3. Execute Commands​

sso configuration
kubectl -n platform create secret generic sso-config \
    --from-literal=saml-entityid=<e.g., alphasense.ad.companyname.com> \
    --from-literal=saml-url-alternative-context-paths=<e.g., alphasense.ad.companyname.app,alphasense.ad.companyname.com>

After you changed the entity id or saml url alternative context paths in the secret sso-config, you will need to restart the sso-ws pods with:

restart sso-ws pods
kubectl -n platform rollout restart deployment sso-ws