Virtual Provider
Virtual Providers (VPs) are very useful when we need to federate with external providers, but we don’t want to expose all these providers to our internal services. VPs are also used to enhance or adapt an external provider. For example, we can connect our SAML Service Providers with an external OpendID Connect Identity Provider (like Google Sign-in) without changing the SPs. This is also a common scenario, connecting cloud authentication services (IDPs) to our existing set of Service Providers.
Another advantage of using a VP to connect to external IDPs is that we now can control SSO session and other features that are not supported by all SSO protocols.
In this tutorial we will configure a VP that will connect multiple SPs with external IDPs. From the SPs perspective, there is a single IDP available, and from the external IDPs there is only a single SP. Both roles are realized by the Virtual Provider.
Here is the Identity Appliance we are using for this example:
How it works
The Virtual Provider element represents both a Service Provider facing all connected Identity Providers, and an Identity Provider federating users with all connected Service Providers. You can connect both internal or external IDPs to a VP. This is useful when we want to allow users to authenticate either using our internal service, or using external IDPs like cloud authentication (Google, Facebook, Linkedin, Twitter, etc).
By default, the VP will use the IDP whose federated connection is set as preferred. You can control which IDP should be used. You can control which IDP will be used by the VP. One way of doing so is by using the VP IDP Initiated URL where you can specify the target SP, but also the target IDP.
To get the SAML Metadata for each virtual component, you can access the VP SAML 2.0 Section, and scroll the properties sheet to the side you want to export: SP Side or IDP Side. If you have enabled SAML Metadata service, the Virtual Provider Entity ID can be used as metadata URL as well, you have one for each role: SP and IDP.
Identity Provider Selection
Identity Provider selection strategies apply not only when using VPs, but when multiple IDPs are available to an SP. In this case, multiple IDPs are available to the SP Side of our VP. You can implement your own custom IDP selection strategy component, and deploy it as a platform extension, but this is outside the scope of this tutorial.
Let’s take a look at some of the available strategies:
Preferred: The IDP whose federated connection is marked as preferred will be selected.
Requested: The IDP requested will be selected. This requires using a special JOSSO URL, since SAML does not support it.
Requesting a specific IDP
https://sso.mycompany.com/IDBUS/VPT-1/VP-IDP-PROXY/SAML2/SSO/IDP_INITIATE?atricore_sp_alias=aHR0cHM6Ly9teS50ZW5uaXMuY29tLmF1&atricore_idp_alias=aHR0cHM6Ly9zc28udGVubmlzLmNvbS5hdS9JREJVUy9UQU5BVi9HT09HTEUtSURQL1NBTUwyL01E
When using VPs, you must provide both SP and IDP aliases. Replace appliance and VP names with your own values.
User Selected: JOSSO will present a screen to the user with the available options. This screen can be customized as part of the branding support.
Previously Selected: JOSSO will use the previously selected IDP.
WIA: JOSSO will select the IDP that can authenticate the user using Windows Integrated Authentication, used to select IDPs based on windows domains.
These strategies combine, so that you can configure things like Requested, then preferred which means that if a requested IDP is found it will be selected, otherwise the preferred will be used.
Virtual Identity Provider Settings
The VP contains settings for both the IDP and the SP side. As IDP you can control attributes like session timeout, user identifier, attribute profiles, user repositories, etc.
Enhancing User Information
You can connect an Identity Source to your Virtual Provider, allowing you to enhance the user information available to SPs with your users repository. Provisioning is not covered in this tutorial, but you can use the Atricore ID platform to also keep user repositories synchronized. JOSSO will use the received user identifier to access the repository and obtain user attributes and roles.
Attribute Profiles
Since version 2.4.2, JOSSO supports defining attribute profiles. These profiles can be used to configure the reported attributes an IDP is including in an assertion. You can control which attributes are reported, and which name the attribute will have.
In our case, we can use this to consolidate attributes from different external IDPs. For instance, if IDP 1 uses emailaddress and IDP 2 uses emailaccount to report the user email, we can create a profile that maps these attributes to email.
Keep in mind that when using attribute profiles you must explicitly report all attributes. Only those listed will be used when the VP issues assertions to connected SPs.
Session Management
Since SAML does not provide session management support, the Virtual provider will manage its own SSO session when connected with external IDPs. Otherwise it will rely on the internal IDP session state. You can control the session timeout from the VP Core section.
Auditing
JOSSO will generate audit trails for both the Virtual SP and Virtual IDP side of the provider.
External Identity Providers
There are two external IDPs represented in our model. These services will be federating identity with our Virtual SP. A single SP is connected to them, therefore hiding the complexity of our actual deployment. We need to provide the Virutal Provider SP metadata to those systems, when configuring the federated connection.
Internal Service Providers
These are SPs that use JOSSO Agents technology to SSO enable applications. Nothing special needs to be configured at the SP level to connect them to the VP.
External Service Providers
These are SPs that have a federated connection with the Virtual IDP side of our VP. Nothing special needs to be configured on these SPs. One thing to keep in mind is that since SAML does not support VPs, there is no way for these SPs to request a particular IDP from those available when issuing an Authentication Request. It is up to the VP to select the actual IDP. One option is to use IDP-initiated instead of SP-initiated authentication. The other option is to enable IDP selection to users on the JOSSO side. This is done by changing the Identity Appliance IDP selection settings.