ComponentSpace

Forums



How to broadcast SSO to multiple Service Providers


How to broadcast SSO to multiple Service Providers

Author
Message
demyoliver
demyoliver
New Member
New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)

Group: Forum Members
Posts: 16, Visits: 31
Hi,

My configuration is that I have one IDP and 2 SPs. 
Any SP can do SP initiated SSO via SAMLServiceProvider.InitiateSSO. What will happen next is that IDP will receive via SAMLIdentityProvider.ReceiveSSO and eventually send SAML response to SP via SAMLIdentityProvider.SendSSO.

The question is how will I be able to send SSO response to ALL service providers associated with the IDP as SAMLIdentityProvider.SendSSO seems to only send it to the calling SP and not all.

Regards,
Demy
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)

Group: Administrators
Posts: 2.2K, Visits: 5.9K
SAML SSO doesn't have a broadcast facility.
SAML SSO is always between one IdP and one SP at any time.
If the user starts at SP1 and initiates SSO to the IdP, they'll be prompted to login if they're not already authenticated at the IdP.
If the same user then browses to SP2, and assuming they're still authenticated at the IdP, SSO will not result in a second login.
So the flow from the IdP's perspective is:
1. User initiates SSO from SP1.
2. Call SAMLIdentityProvider.ReceiveSSO to receive and process authn request from SP1.
3. Login user at IdP.
4. Call SAMLIdentityProvider.SendSSO to create and send a SAML response to SP1.
5. User initiates SSO from SP2.
6. Call SAMLIdentityProvider.ReceiveSSO to receive and process authn request from SP2.
7. User is still logged in at IdP.
8. Call SAMLIdentityProvider.SendSSO to create and send a SAML response to SP2.

Regards
ComponentSpace Development
demyoliver
demyoliver
New Member
New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)

Group: Forum Members
Posts: 16, Visits: 31
ComponentSpace - 1/30/2019
SAML SSO doesn't have a broadcast facility.
SAML SSO is always between one IdP and one SP at any time.
If the user starts at SP1 and initiates SSO to the IdP, they'll be prompted to login if they're not already authenticated at the IdP.
If the same user then browses to SP2, and assuming they're still authenticated at the IdP, SSO will not result in a second login.
So the flow from the IdP's perspective is:
1. User initiates SSO from SP1.
2. Call SAMLIdentityProvider.ReceiveSSO to receive and process authn request from SP1.
3. Login user at IdP.
4. Call SAMLIdentityProvider.SendSSO to create and send a SAML response to SP1.
5. User initiates SSO from SP2.
6. Call SAMLIdentityProvider.ReceiveSSO to receive and process authn request from SP2.
7. User is still logged in at IdP.
8. Call SAMLIdentityProvider.SendSSO to create and send a SAML response to SP2.



demyoliver
demyoliver
New Member
New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)

Group: Forum Members
Posts: 16, Visits: 31
ComponentSpace - 1/30/2019
SAML SSO doesn't have a broadcast facility.
SAML SSO is always between one IdP and one SP at any time.
If the user starts at SP1 and initiates SSO to the IdP, they'll be prompted to login if they're not already authenticated at the IdP.
If the same user then browses to SP2, and assuming they're still authenticated at the IdP, SSO will not result in a second login.
So the flow from the IdP's perspective is:
1. User initiates SSO from SP1.
2. Call SAMLIdentityProvider.ReceiveSSO to receive and process authn request from SP1.
3. Login user at IdP.
4. Call SAMLIdentityProvider.SendSSO to create and send a SAML response to SP1.
5. User initiates SSO from SP2.
6. Call SAMLIdentityProvider.ReceiveSSO to receive and process authn request from SP2.
7. User is still logged in at IdP.
8. Call SAMLIdentityProvider.SendSSO to create and send a SAML response to SP2.

How do you identify step 7? Does this mean that the IDP needs to have a list of all existing logged in user or does SAMLIdentityProvider knows about it already?
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)

Group: Administrators
Posts: 2.2K, Visits: 5.9K
Normally the IdP would use authentication cookies to know whether a user is logged in or not.
It's no different from a non-SSO application where cookies are used to track authenticated users.

Regards
ComponentSpace Development
demyoliver
demyoliver
New Member
New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)

Group: Forum Members
Posts: 16, Visits: 31
ComponentSpace - 3/11/2019
Normally the IdP would use authentication cookies to know whether a user is logged in or not.
It's no different from a non-SSO application where cookies are used to track authenticated users.

Thanks for the answer. Now if I apply SLO is it going to be the same approach?

How do I "broadcast" that a user has logged out from one SP to another before I clear an authenticated user's cookie?
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)ComponentSpace Development (3.2K reputation)

Group: Administrators
Posts: 2.2K, Visits: 5.9K
We recommend clearing the local authentication cookie as the first step before proceeding with the rest of the SLO.
The reason for this is that there are no guarantees all parties involved will successfully participate in the SLO in which case you may not get control back.

The flow for SLO is as follows:
1. SP1 sends logout request to IdP.
2. IdP sends logout request to SP2.
3. SP2 sends logout response to IdP.
4. Steps 2 and 3 repeat for all other SPs.
5. IdP sends logout response to SP1.

All messages are sent via the browser and sequentially.
The sequence can fail at any step if the IdP or SP doesn't respond correctly.
You're better to logout the user locally as soon as possible (ie step 1) rather than waiting for SAML SLO to complete (ie step 5).

Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 2 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Social Logins

Select a Forum....









Forums, Documentation & Knowledge Base - ComponentSpace


Search