Skyfence offers two methods to integrate with SAML: with and without SAML modifications. We are often asked about the difference between the two and how they work. Before I answer these questions, allow me to begin with a short explanation of what SAML actually is.
SAML (or Security Assertion Markup Language) is a mechanism that allows a user to authenticate in one website (a single sign-on portal, for instance) and then seamlessly use the same login session to access another website (Salesforce.com, for instance). It allows an organization to securely manage identities and bring authentication “in-house,” while making it easier for the end user.
The way it works is by using a signed assertion – which is a fancy name for a ticket. After the user logs in to the authentication site (called “identity provider” or IDP for short), the IDP issues an assertion XML and hands it back to the user’s browser. This XML contains details such as the user name and the site it is intended to be used in. To prove that the assertion is authentic, the IDP signs it, using a private key only it knows. Typically, the IDP may be an on-premise directory, a single sign-on portal solution (e.g., Okta, Ping, Centrify, or others), or a SaaS app in the cloud.
The browser is then redirected and passes the signed assertion to the target website (called “service provider” or SP for short). The SP verifies that the assertion is authentic by validating the signature against a public key it already has knowledge of. This means that in order for this to work, we need to introduce the IDP public key to the service provider beforehand.
So, now we have our SP configured to accept signed assertions from our IDP. Only assertions that are properly signed by the IDP’s private key will be accepted.
Proxy integration without SAML modifications
When using limited integration, the SAML mechanism is used to redirect users to go through the Skyfence proxy instead of going directly to the service. The SAML itself is not modified.
The IDP has a configuration that tells it the address of the service to send SAML assertions to. This address is a simple URL, and it can be modified to redirect the user to the Skyfence proxy URL instead.
This way, unmanaged user devices are automatically monitored by Skyfence without the need for additional configuration.
Proxy integration with SAML modifications
When using proxy enforcement with SAML, the goal is to make sure it is impossible to access the service without first being routed through Skyfence and therefore guarantee that all traffic to the service is protected by Skyfence.
Enforcement works by making the service recognize Skyfence as its IDP, instead of the original one. In the service configuration, we replace the IDP public key with a new Skyfence public key so that the service will only accept SAML assertions signed by Skyfence.
After login at the IDP, the user is redirected to Skyfence along with an IDP-signed assertion. Skyfence will then:
- Validate that the assertion is indeed signed by the true IDP by testing the signature with the IDP public key
- Re-sign the assertion using its own Skyfence private key
- Pass the modified assertion signed by Skyfence to the service provider
The service provider tests the assertion. It is now configured to accept assertions signed by Skyfence and the login is complete.
Skyfence supports leading SAML-based solutions using 3rd-party or integrated single sign-on. To learn more about Skyfence and SAML, request a meeting here.