Question
Common Wealth Bank of Australia
IN
Last activity: 24 May 2019 6:24 EDT
Pega Federated SP server for SAML SSO
Landscape
We are running a Pega platform which is hosting pega instances for multiple projects. The load balancer is common for the platform but the pega instances are separate for each of the project (i.e. Each of the project will have its own Pega Database)
Problem Statement
SSO setup has to be done separately for each of the projects on the platform though the IDP and the set of attributes returned as part of the SAML response are same. So, we are planning to do a single integration between the IDP and the Pega Platform
Design Approach
Setup a dedicated Pega instance for the platform which will potentially host the ACS endpoints acting as router of the SAML Response
These ACS endpoints will receive the SAML Response from the IDP & route them to the respective tenant of the Pega platform
The tenant will then validate the SAML token and finally authenticates the user
Though the above solution theoretically works but becomes a single point of failure (considering the huge customer base that the ACS has to handle as part of the login flow in a dozen of pega applications)
Also this violates the Pega's OOTB SSO design of having the ACS in the same instance of the SP
Any thoughts on this solution would be highly appreciated.
Pegasystems Inc.
US
Hi,
I don't think you can setup the ACS this way.
When using Service Provider initiated requests we are creating a database record that is pointed to by the RelayState parameter that we send to the IDP. The record contains the underlying RelayState URL and the ACS opens the record and uses that URL to post the SAMLResponse to for final authentication.
The URL that is stored in this record is not a static URL. It's the URL used in the initial request by the user. So this could contain a SnapSart URL, the initial Mashup URL, etc.
I also don't think you are gaining much with a design like this.
Are you trying to avoid having a separate relationships at the IDP for each environment? So you would use the SAML SP Entity Identification in each SAML AuthService defined in each of the environments? That breaks the concept of Service Provider and IDP circle of trust which is really what is configured at IDP level and SP level with meta data exchange and configuration.
Hope these thoughts are useful,
--Chris
Common Wealth Bank of Australia
IN
Hi Chris,
Thanks a lot for responding to my query.
Apologies for the delay in reply.
Yes, we are trying to avoid the effort involved in engaging the IDP team to perform the exact same steps for each of the Pega project onboarded into our Pega platform
Also a common integration with the IDP and the Pega platform would enable authentication/SSO automatically for the new project as we auto scale (spin up the new project environment)
I am aware about the opaque UUID sent as the relay state ID instead of the URL. In order to tackle this, I had the below two options
Proposed State - Option 1
Whenever the relay state ID is generated in SP, insert the relay state ID along with its relay state URL into the Pega database pertaining to the environment where the common ACS api is hosted. (i.e. kind of moving the relay state table (pr_data_saml_logininfo) logic to the common Pega environment layer)
Proposed State - Option 2
Hi Chris,
Thanks a lot for responding to my query.
Apologies for the delay in reply.
Yes, we are trying to avoid the effort involved in engaging the IDP team to perform the exact same steps for each of the Pega project onboarded into our Pega platform
Also a common integration with the IDP and the Pega platform would enable authentication/SSO automatically for the new project as we auto scale (spin up the new project environment)
I am aware about the opaque UUID sent as the relay state ID instead of the URL. In order to tackle this, I had the below two options
Proposed State - Option 1
Whenever the relay state ID is generated in SP, insert the relay state ID along with its relay state URL into the Pega database pertaining to the environment where the common ACS api is hosted. (i.e. kind of moving the relay state table (pr_data_saml_logininfo) logic to the common Pega environment layer)
Proposed State - Option 2
Send the relay state URL directly to the IDP (instead of opaque relay state ID) along with the SAML Request so that when the IDP sends the SAML response to the common ACS layer, the ACS can post the SAML response to URL obtained from the relaystate parameter
But i am not sure if this will defeat the SAML security model (Still in an IDP-initiated SAML flow the relaystate URL is directly passed to the SP over the network) . Also all the applications are internal (hosted in intranet & not exposed to internet)
SP - IDP trust circle
- In both the above options though the SP Entity ID is configured common across all the Pega projects (separate physical instances) , the SAML Response is parsed & decrypted by the respective instance which has generated the SAML request.
- Although each of the projects has its own Pega DB the idea is that all of the pega instances belong to a single platform (though virtual)
Considering the above two points, do you still believe that these models break SP-IDP circle of trust
Current State
Awaiting your response