Virtual server IDs for SAML applications

Use VSIDs when the SP doesn’t provide unique identifiers for different purposes and when each identity provider (IdP) needs to identify itself differently when connecting to the SP.

If the IdP and SP are able to connect to each other with unique entity IDs for different purposes, such as in the following example, you don’t need to use VSIDs.

When you add a SAML application to PingOne, PingOne is the IdP, and the application is the SP. The IdP and SP identify each other with the entity ID. When an IdP creates a SAML assertion, the IdP populates the Issuer element with its own entity ID and the Audience element with the SP’s entity ID.

When multiple VSIDs are defined for an application, the application team will need sets of metadata for each VSID to complete integrations for different purposes, such as development, testing, and production. Each VSID has a unique set of metadata:

Learn more about obtaining these metadata XML files and URLs in IdP metadata for SAML applications.

When you define one or more VSIDs in a SAML application, the application sends requests to URLs embedded with VSID information. You can obtain VSID connection information using IdP metadata. Learn more in IdP metadata for SAML applications.

For example, the following IDP Metadata URL is intended to retrieve metadata when PingOne uses a VSID to identify itself:

where eyJ2c2lkIjoidXJuOndpZGdldDpjYTp3aG9zYXR3b3JrOnNzbzpkZXYifQ translates to {"vsid":"urn:widget:us:whosatwork:sso:dev"} using the Who’s at Work entity ID from the previous example in When you need virtual server IDs.

PingOne also supports using URLs to indicate the desired VSID with the vsid HTTP request query parameter instead of embedding the VSID information in the URL. For example, you can append the vsid HTTP request query parameter with a VSID to the IDP Metadata URL to indicate the desired VSID, such as the following example. The HTTP query parameter value must be URL encoded.

This URL triggers PingOne to generate an IdP metadata request where PingOne identifies itself as urn:widget:us:whosatwork:sso:dev.

If the vsid HTTP request query parameter value is mismatched with the VSID embedded in the URL, the embedded VSID takes precedent.

If VSIDs aren’t defined, PingOne uses the default server ID based on the domain in the request URL as its identifier. The domain in the request URL is either the PingOne domain or a custom domain, if configured.

VSIDs can be used in both SP and IdP-initiated requests. For example, if the application team completes integrations based on the metadata you provided, the application is expected to send each of its SAML 2.0 AuthnRequest messages using a URL in which the embedded VSID matches the intended purpose, such as development, testing, or production.

For IdP-initiated single sign-on (SSO) requests, you can obtain URLs for each configured VSID on the Overview tab of the SAML application.

While VSIDs provide configuration flexibility, they can also present security risks, such as impersonation and misuse, that you can take measures to protect against, as described in the following sections.