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

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

1. 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.
2. 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