Virtual server IDs provide more configuration flexibility in cases where you need to identify your server differently when connecting to a partner in one connection for multiple environments or in multiple connections where the partner also supports multiple federation IDs.
Connecting to a partner in one connection
This is a use case where you need to connect to multiple environments serviced by the same partner using one federation ID—multiplexing one SP connection to access multiple subdomain accounts in Microsoft Office 365.
Suppose both the marketing and the engineering departments of contoso.com (the IdP) have their own departmental subdomains, marketing.contoso.com and engineering.contoso.com. They are both registered in Office 365 (the SP) under the parent domain, contoso.com.
In this scenario, the PingFederate IdP server can be configured to include both marketing.contoso.com and engineering.contoso.com as the virtual server IDs in the Office 365 SP connection. Each virtual server ID has its own set of protocol endpoints, which can be obtained in the connection metadata (see Metadata export and System-services endpoints for more information).
After providing the protocol endpoints information to Office 365, when Office 365 sends login requests to PingFederate, PingFederate picks the correct IdP adapter to authenticate the end users based on the virtual server ID in the requests.
For each successful login, PingFederate builds an assertion with issuer being set to the corresponding virtual server ID. When Office 365 receives the assertion, it creates the end user session with the right subdomain settings based on the issuer value in the assertion.
Connecting to a partner in multiple connections
In this use case, you connect to your partner in multiple connections. In each connection, you identify yourself and your partner differently.
For example, you as the SP provide separate environments for the end users based on their regions. Your IdP operates in two regions, Europe (EU) and North America (NA); their federation IDs are eu.idp.local and na.idp.local, respectively.
In the PingFederate SP server, you can create two IdP connections to federate identities for end users from both regions as follows:
|Partner's federation ID||Your virtual server ID|
|IdP connection #1||
|IdP connection #2||
Based on the issuer (the partner's federation ID) and the audience values (your virtual server ID), PingFederate determines at runtime which IdP connection the assertion is intended for, validates as per the connection settings, and passes attribute values to the SP adapter to create the end-user session.
Working with multiple virtual server IDs
You can assign virtual server IDs either as an IdP during configuration of an SP connection (see Identifying the SP) or as an SP configuring an IdP connection (see Identifying the partner) for both Browser SSO Profiles and WS-Trust STS (for access to identity-enabled web services).
If a connection has only one virtual server ID, it becomes the default virtual server ID for the connection. If the list contains several entries, you must specify one of them as the default virtual server ID for that connection. The default virtual server ID is used when no virtual server ID information is included in a request (see IdP endpoints as an IdP or SP endpoints as an SP).
In a connection with multiple virtual server IDs, you can optionally restrict each adapter added to the connection to certain virtual server IDs to enhance the end-user experience (see Restricting an authentication source to certain virtual server IDs and Restricting a target session to certain virtual server IDs).
You can also restrict each token processor or token generator added to a WS-Trust STS SP connection or IdP connection, (see Restricting a token processor to certain virtual server IDs or Restricting a token generator to certain virtual server IDs).
To protect against unauthorized access, configure Issuance Criteria to verify virtual server ID in conjunction with other conditions, such as group membership information. For more information, see Defining issuance criteria for IdP Browser SSO or Defining issuance criteria for SP Browser SSO.