SAML BOX
SAML BOX is brought to you by Boston Identity
SAML BOX
SAML BOX is brought to you by Boston Identity
The purpose of this platform is to provide a readily available IDP or SP for your development and integration testing.
SAML Entities are identified by their Entity ID - use unique IDs to prevent overwrites.
The SAML BOX platform consists of two core components working together:
For Service Provider (SP), we use Spring Security SAML 6.4.3. This handles the complete SAML flow when acting as SP, including:
For Identity Provider (IDP), we leverage Keycloak 26.1.2, as Spring doesn't natively support IDP functionality. Keycloak provides:
SAML integration requires mutual metadata exchange between SP and IDP:
Both SAML SP and IDP metadata can be downloaded here: SAML BOX SP Metadata and SAML BOX IDP Metadata. Your corresponding partner metadata must be uploaded to establish trust relationships. Metadata is identified by Entity ID - ensure uniqueness when creating new entities.
There are two types of workflows in SAML: SP-Initiated SSO and IDP-Initiated SSO. (If you are interested in learning more details, you can check out the tutorial blogs here).
In SP-Init SSO, a SAML AuthnRequest is sent to IDP and IDP will generate a response after validating a user and send back to SP. For that SAML AuthnRequest, there are various things we can configure to tweak the AuthnRequest so that IDP can respond differently based on the ask. Here are some of them that you can play with in SAML BOX.
In SAML, bindings are methods used to transport SAML messages between IDP and SP. There are different bindings defined in the SAML specification:
HTTP POST is the most used while HTTP Redirect is still seen.
SAML BOX supports switching between HTTP POST and HTTP Redirect. Note that this is regarding the SAML Authentication Request Binding, which is the request that sent from SP to IDP, not SAML Response which is sent from IDP to SP.
SAML Response binding can be different from Request binding. In theory, it can be either HTTP POST or HTTP Redirect. However, SAML BOX supports only HTTP POST here.
Regarding SAML Response from IDP, only HTTP POST bindings is supported by SAML BOX.
NameID-Format depicts how the subject value (the value that identifies the user authenticated to IDP) returned in the SAML response should be interpreted by SP. For example, if it's shown as 'emailAddress', the subject value should be interpreted as an email value. Here are some NameID-Format values:
SAML BOX supports selecting one of them or custom format value.
The signature information is not required in the SAML Request, but is good to have. In this case, IDP can verify the signature using the Public Cert provided (e.g. in SP Metadata) to make sure the request is not tampered.
You can specify whether SAML BOX should add a signature when sending the SAML request.
Single Logout allows a user to log out from all sessions across multiple applications (SPs) plus IDP itself in a single action. In this case, a user doesn't need to manually logout each app.
SAML Box supports SP-init Single Logout, where a SAML Single Logout request is sent to IDP.
Here for SAML BOX, when a Single Logout response is sent back, SAML BOX will validate and process it.
Note that it's IDP's responsibility to process that request and send logout response to other SPs. Also, signature is required in the SLO response for SAML BOX to process it.
Once the logout is done, the SAML BOX session will be killed, which can be seen from the session info section in SAML BOX UI.
IDP-init Single Logout (unsolicited single logout, similar to IDP-init single sign-on) may not be supported here due to the limitation of Keycloak.
While SAML response signature is required, SAML response encryption is optional. The former protects data integrity of the response and the latter protects the data confidentiality of the response. When security level is high, SAML encryption might be needed, and signature is usually required too. Note that IDP usually signs response first and then encrypt.
When SAML BOX acts as SP, it supports SAML response encryption.
A signature is required when encryption is enabled.
IDP uses SP's public cert to encrypt the response and SP will decrypt it using its private key.
As Spring Security SAML is NOT supporting IDP yet, Keycloak is used here as IDP provider.
Keycloak is an Open Source Identity and Access Management platform. It adds authentication to applications and secure services with minimum effort, and it provides user federation, strong authentication, user management, fine-grained authorization, etc.
SAML BOX leverages Keycloak APIs to fulfill the IDP role. When a SAML SP client is registered (Keycloak calls SP as client, same as in OAuth/OIDC), a list of settings is available for this specific SP. Note that since Keycloak is a centralized IAM platform, it can register multiple SPs and each SP will have its own specific settings for the login flow.
Normally an IDP generates a SAML response based on the incoming SAML request. Occasionally, IDP can generate an unsolicited SAML response and directly send to SP, and this is called IDP-Initiated SSO. This flow is useful when SP can't generate SAML request but can accept SAML response.
SAML BOX supports IDP-init SSO flow when acting as IDP.
Similar to SAML Request Bindings, the different binding types can be used in the SAML response too. SAML BOX (Keycloak) supports both HTTP POST and HTTP Redirect when acting as IDP, which can be specified in the SAML BOX settings.
Some NameID-formats are supported by Keycloak:
When a NameID-format is selected, that selected one will be the format returned in the SAML response.
The signature for SAML Response is mandatory and can be at either Assertion level or the entire Message level or both (check here for more info).
SAML BOX supports encryption when acting as an IDP. Note that an encryption public cert is required when uploading SP metadata.