Symantec Access Management

mjeanjacques wrote:

I noticed that the CA bookshelf mentioned nothing about SAML 2.0 Auth Scheme for setting up a partnership federation at the SP side, but I do see that requirement for Legacy Federation. Is that still needed for partnership Federation?
What are the major differences between Legacy Federation Vs Partnership Federation in R12.51?

You do not need to configure authentication schemes with the partnership federation model. If you are setting up your local site to act as a SAML 2.0 SP, you need to:

1. Configure your Local SP and remote IdP entites.

2. Configure an SP -to- IdP partnership. The partnership wizard will take you through the configuration steps to configure this partnership.

An authentication scheme is not required.

The key difference between partnership federation and legacy federation is the configuration model. Both models provide federated single sign-on and logout between business partners. However, partnership federation focuses on configuring entities (business partners) and partnerships between entities. The UI screens reinforce this model that you are setting up federated relationships. With the partnership model, you don't have to configure individual SiteMinder components, such as domains, affiliates, authentication schemes. Legacy federation requires that you configure the individual SiteMinder components and it does not show the relationship between partners as clearly as partnership federation.

The SiteMinder 12.51 bookshelf has a document "Federation in Your Enterprise" that discusses the different federation deployments. There is a Partnership Federation Guide specific to the patnership model. The SiteMinder 12.51 bookshelf is available on SupportOnline at the following link:

https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf.html

Note: The most recent release of SiteMinder is 12.52.

Just to add a little more to the differences:

At the SP's side target realm where you will be federating to, is protected by different authentication schemes based on the federation configuration model as below.

1. Legacy Federation Model

    * The TARGET realm must be protected by the SAML Authentication Scheme.

2. Partnership Federation Model

    * The TARGET realm is protected by any regular authentication schemes.

If you look at the legacy model, the target realm must be protected by saml authentication scheme so in case if you wanted non-federated users to access, you would have a problem.

Non-federated users could SSO to the TARGET realm after logging onto other SP's realms but cannot directly logon to the TARGET.

On the other hand, Partnership Federation Model does not have this requirement and you are to protect the TARGET realm with normal authentication schemes.

This allows both federated and non-federated users to access and also get challenged if the user did not have a valid session.

Now here is a more realistic difference.

For Partnership Federation Model, there can be some creativity to it by protecting the SP's target realm using HTML Forms authentication scheme and setting the authentication scheme target to SP's AuthnRequest or IDP's Unsolicited service url to automate the federation.

That way, all users will be redirected to initiate federation in case if the user did not have a valid session.

==> this is not possible for Legacy Federation Model. You must have a link to initiate federation.

Hi Kim,

You mentioned:

For Partnership Federation Model, there can be some creativity to it by protecting the SP's target realm using HTML Forms authentication scheme and setting the authentication scheme target to SP's AuthnRequest or IDP's Unsolicited service url to automate the federation.

If I did above, will the non-federated user have problem to access?

Hi, Kar Meng.

Yes, if you try that, the non-federated users will also be sent to federate if they did not have a valid session.

Then again, you can be more creative and use a credential selector to give options to users whether they choose to federate or login locally.

Cheers,

Kim