We have a SAML 2.0 integration with one of our vendors. The vendor portal application supports log ins for multiple affiliates (each of which is hosted on its own domain) Even though this shows up on the SP side as multiple ACS & SLO urls, these affiliate domains metadata all have the same entityID. As a result, AM cannot import all of them due to duplicate entityIDs.
As a workaround, we combined the SP metadata and imported it using multiple ACS and SLO urls in the same metadata. With this configuration, we can still perform SignOn successfully using all 8 affiliates however for SLO, the redirect happens to the last SLO url from the metadata for all affiliates.
Since this is a limitation on the SP side, how can this be addressed on the PingAM side?
I would contact PingIdentity support to find out wether this feature is supported, and if yes, wether the SLO behaviour is an expected outcome.
The workaround would be to have one realm per affiliate, I know, that’s not ideal.
Another possibility is to import the single SP metadata into multiple SPs (one per affinilate, different Entity ID for each). Use the IDP mapper script to change the SP id on the fly, based on the domain? I have not tested this, though, but this might be possible?
true enough.
However, I am stumbling over the fact that “multiple associates share the same entity id”. and, each associate represents a distinct DNS domain and uses unique login and logout URLs.
Is this not counter to the premise and standards of SAML?
I am not entirely clear; explicitly please define which systems act as the SP and IDP.
If having to continue with this workaround, we would need to perform an extension. Of course, I would not place bets on the successful outcome of any upgrade without a full analysis before the integration.
Its is mentioned by my colleague that each associate’s configuration could be associated with a unique realm… this is the path I too would consider.
@patrick_diligent@grpensa I do have a ticket with Forgerock and they have recommended that the SP follow SAML standards i.e. use multiple entityIDs per affiliate
For the one realm per affiliate option, I’m guessing that there won’t be an issue importing a remote SP entity that has the same entityID in another realm. Is that correct?
I will check with my team if this can be considered/proved out, but in theory, it won’t make any sense as all these realms will still share/point to the same ID store
@grpensa Forgerock is our IdP and the portal application (with multiple affiliate domains) is the SP
Can we pass a RelayState from the SP to the Forgerock Idp during the IdPSLOPOST flow and if the IDP then will redirect the user back to the RelayState. This way, the correct SLO url can be provided to the IdP
Currently (without RelayState) the “Federation” logs suggest that AM looks at the payload and says that the ReleyState was not passed/missing
I have to admit that if I were responding to the SR, I too would say “stick to the standards. All affiliates in a SAML solution MUST be identified with a unique entityID.”
But the notion of multiple realms will allow for the workaround of this poor situation where a singular entityID is used with many associates.
Think of the realm as strictly a means of scoping a configuration. In this case one could have multiple realms, with unique SAML COT configurations, thus allowing the import of this poorly defined data.
This is a common misnomer. No where is it defined that distinct realms require a configuration of distinct user stores. In fact quite often I will scope a solution where 1 realm uses server based sessions, another uses client based sessions, for the very identical user store.
But if you ever migrate to Ping Advanced cloud, this is where trouble lurks in - only two realms there, so this is when I would get back to the third party, and ask, hey can you do something about it?