SAML - Break SAML flow and redirect to other SP
This document describes how to break the current SAML authentication flow and redirect the user to a different SP. This could be used in scenarios where users should be redirected to default information page when certain conditions are met.
The reader of this document should have some basic knowledge about PhenixID Server.
We will make changes to phenix-store.json, so make sure to have a recent copy/backup of this file.
Overview
The default behavior for PAS is to send the user back to the SP that initiated the authentication request (solicited authentication).
When the authentication starts at the IdP, the user will always be sent to the "default SP" if configured with a "default SP" (unsolicited authentication).
This document describes how to break the current SAML authentication flow and redirect the user to a different SP. This could be used in scenarios where users should be redirected to default information page when certain conditions are met.
This document also contains an example of a simple SAML SP that will just show an "access denied" message. This part of the documentation may not be necesary to follow, as long as another SP to be used as "default SP" exist.
PIPE configuration
1: Make sure to have the current session loaded, by using the SessionLoadValve. This can be done in the beginning of the pipe.
Example:
{
"name": "SessionLoadValve",
"config": {
"id": "{{request.session_id}}"
}
}
2: Add the two valves from the code block below at a good location in the pipe. Make sure the data that should be used for the condition validation exist in the flow.
Make sure to adjust the expression according to your needs.
{
"name": "SessionPropertyRemoveValve",
"description": "Will remove the SAMLRequest from PAS-session if the condition is met (mobile atribute is present).",
"config": {
"name": "SAMLRequest",
"exec_if_expr": "flow.firstItem().containsProperty('mobile')"
}
},
{
"name": "SessionPersistValve",
"description": "Saves the updated PAS-session",
"config": {}
},
3: Add an AssertionProvider that always will redirect user to the "defaultSP" (sourceID).
Make sure to update the parameters according to your configuration (targetEntityID, nameIDAttribute and sourceID)
{
"name": "AssertionProvider",
"description": "Will send the user to the 'accessdenied-SP' if SAMLRequest is missing from PAS-session",
"config": {
"targetEntityID": "a73774bc-9f9f-48ce-955b-99a6664e2beb",
"nameIDAttribute": "userPrincipalName",
"sourceID": "https://pas.company.com/saml/accessdenied",
"skip_if_expr": "session.properties().contains('SAMLRequest')"
}
}
New Default SP - ONLY If PAS is the target of the redirection
SAML SP
Add a new SAML SP to the configuration. Make sure to update the parameters according to your needs.
{
"id" : "https://pas.company.com/saml/accessdenied",
"keystoreSign" : "95daf47c-c263-4732-99b8-a5c83db218fa",
"entityID" : "https://pas.company.com/saml/accessdenied",
"ForceAuthn" : "false"
}
Authenticator
Add the new SP authenticator and update the parameters according to your needs.
Make sure to use the same value for sp and entityID as previously configured for the SAML SP.
{
"id" : "accessdenied",
"alias" : "accessdenied",
"name" : "SAMLServiceProviderAuthN",
"displayName" : "AccessDeniedSP",
"configuration" : {
"successURL" : "/accessdenied/authenticate/accountnotprepared",
"sp" : "https://pas.company.com/saml/accessdenied",
"pipeID" : "pipeAssertionConsumer",
"targetIDP" : "https://pas.company.com",
"acsUrl" : "https://pas.company.com/accessdenied/authenticate/accessdenied",
"entityID" : "https://pas.company.com/saml/accessdenied"
}
}
Add the configuration for the default webpage (registration authenticator).
{
"alias" : "accountnotprepared",
"id" : "accountnotprepared",
"name" : "Registration",
"configuration" : {
"stages" : [ {
"pipeid" : "dummy",
"template" : "C:/Program Files/PhenixID/Server/overlay/auth-http/files/templates/accessdenied.template",
"templateVariables" : {
"overlayCSS" : "/overlay/stylesheets/customer.css"
}
} ]
}
}
Add a template file or use this one as example.
Test
1a: Try to authenticate to any SP in the flow with a user that meet the requirement (mobile attribute missing). User should be redirected to the "access denied SP".
1b: Try to authenticate to any SP in the flow with a user that do NOT meet the requirement (mobile attribute missing). User should be redirected to the SP initiating the request.