Single Sign-On (SSO)
vScope offers full support for both SAML 2.0 and OpenID Connect (OIDC), giving organizations flexibility to integrate with their preferred identity provider. Whether you rely on SAML for established compatibility or OIDC for modern token-based authentication, vScope ensures secure, centralized access control.
vScope supports Single Sign-On (SSO) using any SAML 2.0–capable IdP. This allows enhanced security features such as Multi-factor Authentication (MFA). By letting your IdP handle authentication and permissions, you centralize access control and user management. This guide outlines the configuration steps.
SAML2.0 requires configuration in both the Identity Provider (IdP) and the Service Provider (vScope).
vScope SSO settings
Settings in vScope for Single Sign-On.
- Configuration name
- The name of the SAML configuration in vScope.
- E.g.
Entra
.
- Callback URL
- The URL (on vScope) to which the IdP will redirect successful authentications.
- Automatically generated by vScope.
- The Callback URL will be generated by combining:
- Settings > Network > Web Application Address > Base URL
- Settings > Single Sign-On (SSO) > Configuration name
- E.g.
https://vscope.mycompany.com/rest/usermanager/sso/authenticate/Entra
.
- The Callback URL will be generated by combining:
- Identifier (Entity ID)
- The unique identifier that vScope uses when interacting with the IdP (must match the Identifier/Entity ID registered for the app in the IdP).
- E.g.
vScope
.
- App Federation Metadata Url
- The URL to the Identity Provider metadata XML which contains configuration details of the IdP along with certificates for signing SAML assertions.
- Often called App Federation Metadata URL, IdP Metadata URL or SAML Metadata URL in the IdP
- E.g. (ADFS)
https://<adfs-server>/FederationMetadata/2007-06/FederationMetadata.xml
- E.g. (Entra ID)
https://login.microsoftonline.com/mytenant/federationmetadata/2007-06/federationmetadata.xml?appid=myapp
- E.g. (Okta)
https://mycompany.okta.com/app/myapp/sso/saml/metadata
Signing & Certificates
Signing is used to verify the validity of SAML messages and assertions. Most IdPs sign assertions by default but do not require the SP to do the same for authentication requests or metadata.
In vScope SSO settings there are four settings that control different aspects of signing:
- Sign Metadata (default false)
- Signs the vScope SP metadata XML file. If you configure the IdP with the SP metadata from vScope and the IdP expects it to be signed, enable this setting.
- Sign Authentication Requests (default false)
- Signs the AuthnRequest from vScope to the IdP.
- Request Signed Assertions (default false)
- Requests the IdP to sign assertions sent to vScope. Unsigned assertions will be ignored by vScope if enabled. Make sure to configure the IdP to sign assertions.
- Request Signed Responses (default false)
- Requests the IdP to sign entire SAML responses sent to vScope. Unsigned responses will be ignored by vScope if enabled. Make sure to configure the IdP to sign responses.
IdP SSO settings
These are settings in the IdP. The exact names of the settings may vary.
- Identifier (Entity ID) (Entra), Relying Party Identifier (ADFS), Application label (Okta)
- Must match Identifier (Entity ID) in vScope SSO settings.
- ACS (Assertion Consumer Service URL) (Entra), Callback URL, Reply URL or Single sign-on URL (Okta)
- Must match Callback URL in vScope SSO settings.
Attributes & Claims
To enable authentication and authorization, both vScope (the Service Provider) and the IdP (Identity Provider) must agree on which attributes (user data stored in the IdP) are sent, and how these are represented as claims inside a SAML assertion.
A SAML assertion is a digitally signed, trusted XML message issued by the IdP and consumed by vScope. It communicates proof of authentication, user attributes (such as email or group membership), and authorization details each time a user logs in to vScope.
There are four claims that vScope expects to be present in the SAML assertion. Ensure that your IdP is configured to include the corresponding attributes as claims.
- Email (user email)
- Given name (first name)
- Surname (last name or family name)
- Groups (the user’s group memberships)
These claims are configured as Attribute assignments in vScope SSO settings:
For each of the claims the following values must be set.
- Name
- The name of the claim. E.g.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
.
- The name of the claim. E.g.
- Friendly name (optional)
- The friendly name of the claim. E.g.
emailaddress
.
- The friendly name of the claim. E.g.
- Name format
- The format of Name. E.g.
URI
.
- The format of Name. E.g.
Verify the exact names in the IdP.
As vScope receives a SAML assertion it will attempt to map claims by their Name or Friendly name.
So for email in the example above, vScope will look for the user email in http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
and emailaddress
in the SAML assertion.
The groups claim
The groups claim is not required but recommended. It can be used by vScope Group Mapping to map the user by the groups in the SAML assertion to groups in vScope. [Read more about configuring group mapping here]