Symantec Access Management

Can SiteMinder bridge multiple IDPs for a single SP considering this SP is already configured with SiteMinder and is capable of pointing to only one IDP? The SP needs to integrate with another IDP. Use Case Scenario is as below:

1. Application X is configured to use SiteMinder as an Identity Provider (IDP).
2. The application X can only be configured to recognize one IDP.
3. The application X is the Service Provider (SP).
4. Application Y uses its own IDP (=Y), rather than the SiteMinder.
5. We need to perform SSO initiated from application Y to the application X over a web connection.

Is it possible for SiteMinder to facilitate this bridging, something on the line of PingFederate FederationHub?

Any help is much appreciated!

Hi Sandeep,

SAML 2.0 Local SP Entity Configuration - CA Single Sign-On - 12.7 - CA Technologies Documentation

SAML 2.0 Local SP Entity Configuration - CA Single Sign-On - 12.7 - CA Technologies Documentation 

There might be other configuration limitation regarding IDP side /redirectjsp location for different partnership, but that can be customized as work around. It all depends on your use case flow and what is required.

If you look for something like PingFederate FederationHub, then please open a new IDEA from this community to let product management team know your requirement, so that can enhance it in future release.

Regards,

Hongxu

Hi Sandeep,

You can configure a partnership to let users select an identity provider such as Facebook or Twitter for authentication. The credential handling service that is installed on CA Access Gateway lets you configure a partnership to display a credential selector page with multiple identity providers as user authentication choices.

You could try to use Credential selector for your use case. 

Configure Social Sign-on - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation 

hope this helps.

Thanks,
Sharan

Can you make X as  just an application and not as SP  and make your current SiteMinder to act as SP((use redirect mode for header or open format cookie etc for what app needs after consuming SAML response/attributes) for it ? if you can do so, you can make another standalone WAOPACK or SPS instance(s) to be an IdP and at the same time allow other IdP's to interface with Application X solving your problem.

AroraS

Yes CA SSO can perform the same functions as "PingFederate Federation Hub" to a good degree. I love they way PING markets this as a marquee feature. 

Federation hub use cases 

Bridging an IdP to an SP 

Bridging an IdP to multiple SPs 

Bridging multiple IdPs to an SP 

Bridging multiple IdPs to multiple SPs 

Circling back to CA SSO. The same instance of CA SSO can act as an IdP and also as an SP using two different Partnerships.

Partnership-A : CA SSO is SP and Application-Y is IdP. Create "SP -> IdP Partnership".

Partnership-B : CA SSO is IdP and Application-X is SP. Create "IdP -> SP Partnership".

* * * Assuming both Partnership use the same Identity Store.

Here is where the magic happens, within Partnership-A, in the TARGET field, define the "IdP Initiated URL for Partnership-B" i.e. https://FQDN/affwebservices/public/saml2sso?SPID=X.

Here is how the flow would work for the use case "We need to perform SSO initiated from application Y to the application X over a web connection".

1. Application-Y will send a SAML Assertion to CA SSO (acting as SP). This will invoke Partnership-A.
2. CA SSO (acting as SP) will consume the SAML Assertion, authenticate the user, generate a SMSession, Persist Attributes from SAML Assertion into Session Store (using Persist Authentication Session Variables feature).
3. CA SSO (acting as SP), will then issue a 302 redirect to the URL defined in TARGET within Partnership-A.
4. TARGET URL is https://FQDN/affwebservices/public/saml2sso?SPID=X.
5. This will trigger Partnership-B (CA SSO acting as IdP).
6. Since user is already authenticated and has a SMSession, Partnership-B (assuming has the same UD / IdentityStore as Partnership-A) will read attributes from Session Store "and/or" user directory. Inject that into a SAML Assertion. Then POST to Application-X.

However like I mentioned, if the use case is SSO it is possible.

Regards

Hubert

KB Kaladhar.Brahmanapally further corrected me that "Persist Authentication Session Variables" as per doc saves the Originating IssuerID (ProviderID) in SStore as well, in addition to the Assertion Attributes. 

Application Integration (Relying Party) - CA Single Sign-On - 12.52 SP2 - CA Technologies Documentation  

We can in a way send the Originating IssuerID (using Persist Authentication Session Variables within Partnership-A) as an Additional Assertion Attribute configured in Partnership-B on Step-6. The key difference is the IssuerID in the SAML Assertion Statement will be of CA SSO as IdP (not Originating IdP), however in Assertion Attribute we will find the Originating IssuerID.