IdP Initiated SSO

[Scott Spyrison]

Hello,

The deprecated Reference Implementation for SAML-based SSO to Google Apps still works fine with IdP Initiated SSO.  I put up a Proof of Concept to do the same, and it also works fine for our own domain.  Google is accepting our signed SAML response with a valid RelayState.  I opened a support case to inquire whether or not Google would continue to accept these unsolicited responses, and I was redirected to this support forum.  Can a Google employee comment further or commit to an up or down for continued support of IdP initiated SAML SSO?  

I would also like to describe my scenario and current understanding, and perhaps there's an alternative approach someone could suggest.  Our users will be in multiple domains within our overall Google Apps environment.  Most users will have a single account, but some users may have an account in more than one domain.  More than one account would result in more than one link to access Google Apps.  My curent understanding for SAML with multiple domains is:

1. I need to post the SAML response to the ACS for my primary domain, and only to my primary domain
   
2. I need to fully qualify the username in the SAML response, for example us...@foo.edu or us...@bar.foo.edu

Given that a user can have an account in more than one domain, and without delving into the business reasons behind this, my IdP needs to know which link was clicked in order to insert the correct username and domain into the response.  The easiest solution we can think of is to have the link(s) start an IdP initiated process on our side.  If SP initiated is the only option Google will commit to, then I am considering parsing the RelayState to determine which link the user clicked.

Thank you very much for any feedback.

[Robert Norris]

I know from experience that secondary domains do not work with IdP-initiated SSO, only the primary domain. We never got around to confirming with Google whether or not IdP-initiated SSO was supposed to work or was just a leftover from something. We guessed that since it wasn't documented and wasn't exactly a common practice it would be best if we switched SP-initiated.

Something we successfully tested but didn't implement was making a request on the server side to the service URL, extracting the SAML request from the redirect response that came back, filling out the detail and signing it and then giving that back to the user. From the user perspective it looks exactly like IdP-initiated SSO (ie a single redirect). This approach might work for you.

(fyi, this is similar conceptually to the "cached request" approach described in this old forum thread: http://www.google.com/support/forum/p/apps-apis/thread?tid=0dee17907b550ce3)

Cheers,

Rob.

--
You received this message because you are subscribed to the Google Groups "SAML-based Single Sign On for Google Apps" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-apps-saml-sso/-/qT41FkL7BB8J.
To post to this group, send email to google-app...@googlegroups.com.
To unsubscribe from this group, send email to google-apps-saml...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-apps-saml-sso?hl=en.

[Scott Spyrison]

Hi Rob,

I read the "cached request" posting as well. I didn't pick up enough
useful information from that thread to discuss. Are they suggesting
that customers generate assertions valid for 6-12 months? That does
not seem wise. If a "validation window" needs to be set to 6-12
months to support a "cached request" approach, I believe it's at
Google. For example, if they are checking the InResponseTo attribute
to correlate a response to a request, then they (Google) would need to
recognize the cached request ID as valid for an extended period of
time... of course, they can't be checking the InResponseTo attribute,
otherwise IdP-initiated wouldn't work to begin with.

I re-tested IdP-initiated SSO to verify accounts in both my primary
and non-primary domains. As long as I'm posting to the ACS in the
primary domain, and fully-qualifying the Subject's NameID (i.e.
us...@foo.edu or us...@bar.foo.edu), it is successful. Like you, I am
hesitant to pursue this option unless Google will provide some more
formal statement or documentation. Searches have led me repeatedly to
salesforce.com, which seems to support and document IdP-initiated SAML
SSO. That doesn't really have anything to do with anything, except
that it gave me hope Google might support the same approach.

On Jun 19, 8:08 pm, Robert Norris <r...@eatenbyagrue.org> wrote:
> I know from experience that secondary domains do not work with IdP-initiated
> SSO, only the primary domain. We never got around to confirming with Google
> whether or not IdP-initiated SSO was supposed to work or was just a leftover
> from something. We guessed that since it wasn't documented and wasn't
> exactly a common practice it would be best if we switched SP-initiated.
>
> Something we successfully tested but didn't implement was making a request
> on the server side to the service URL, extracting the SAML request from the
> redirect response that came back, filling out the detail and signing it and
> then giving that back to the user. From the user perspective it looks
> exactly like IdP-initiated SSO (ie a single redirect). This approach might
> work for you.
>
> (fyi, this is similar conceptually to the "cached request" approach

> described in this old forum thread:http://www.google.com/support/forum/p/apps-apis/thread?tid=0dee17907b...)
>
> Cheers,
> Rob.

>
> On Sun, Jun 19, 2011 at 2:17 AM, Scott Spyrison <sspyrison....@gmail.com>wrote:
>
>
>
>
>
>
>
> > Hello,
>

> > The deprecated Reference Implementation<http://code.google.com/googleapps/domain/sso/saml_reference_implement...> for

> > SAML-based SSO to Google Apps still works fine with IdP Initiated SSO.  I
> > put up a Proof of Concept to do the same, and it also works fine for our own
> > domain.  Google is accepting our signed SAML response with a valid
> > RelayState.  I opened a support case to inquire whether or not Google would

> > *continue* to accept these unsolicited responses, and I was redirected to

> > this support forum.  Can a Google employee comment further or commit to an
> > up or down for continued support of IdP initiated SAML SSO?
>
> > I would also like to describe my scenario and current understanding, and
> > perhaps there's an alternative approach someone could suggest.  Our users
> > will be in multiple domains within our overall Google Apps environment.
> >  Most users will have a single account, but some users may have an account
> > in more than one domain.  More than one account would result in more than
> > one link to access Google Apps.  My curent understanding for SAML with
> > multiple domains is:
>

> >    1. I need to post the SAML response to the ACS for my primary domain,

> >    and only to my primary domain

> >    2. I need to fully qualify the username in the SAML response, for
> >    example u...@foo.edu or u...@bar.foo.edu

[Robert Norris]

Interesting that you got it to work with secondary domains. At the time we did it (mid last year) we couldn't find any combination of response parameters and ACS URLs that would make it work. We ended up delaying our secondary domain rollout for a few weeks as a result until we figured out a workaround.

We don't actually used "cached requests". It was simply that post that led us to the idea of fetching the SAML request in the backend in order to mimic an IdP-initiated-like workflow.

Unfortunately I can't remember all the details. I'll talk to my colleagues today and try to remember exactly how we arrived at our current implementation. If I discover anything useful I'll let you know.

[Michael Manoochehri]

Hi Scott:

Good questions.

I don't know exactly what you are doing, but it sounds like you might be using a cached RelayState value to make IdP-initiated requests to Google Apps SSO? If this is what you are doing, I would caution you to not depend on a cached RelayState parameter, as we can't guarantee that it will be the same, or valid between requests. Basically, the only SAML SSO flow we officially support is a Resource Provider initiated flow, and we can't guarantee that attempts to use an IdP initiated flow will succeed.

As for the other question, your strategy should work - you should be able to extract an identifier from the RelayState to help you determine which account to provide for your user. 

In situations where you want to mimic an IdP initiated flow, you should be able to fetch the SAML request in the background, follow the HTTP redirects, and extract the RelayState dynamically.

Michael

[Scott Spyrison]

Hi Michael,

Thanks for the reply.  I am not caching a RelayState value from a prior AuthnRequest.  To mimic an IdP initiated flow, I am posting to the ACS URL for my primary domain and including a RelayState value representing the link clicked by the user.  For example, https://mail.google.com/a/foo.edu or https://mail.google.com/a/bar.foo.edu.  

This works fine - but based on your comments I will not move forward with this method because you only officially support SP initiated flow.  Unless you tell me otherwise of course... but everything I have heard so far seems to indicate that Google does not support this.  If it works today, it may not work tomorrow.

Scott

[Michael Manoochehri]

Hi Scott - 

Has your domain transitioned to our new infrastructure yet? (Check the admin control panel). If not, I think that this will potentially break after the transition process.

Michael

[Scott Spyrison]

Hi Michael,

Yes, I have transitioned this domain to the new account
infrastructure, but that's a good point - it was created under the
old, and transitioned to the new. Other services (such as start page)
behave differently for domains that have been transitioned as opposed
to created exclusively under the new. Perhaps this is just another
service behaving differently.

Regardless, I've definitely heard enough to eliminate an IdP initiated
flow as a possible solution.

Thanks,
Scott

> --
> You received this message because you are subscribed to the Google Groups
> "SAML-based Single Sign On for Google Apps" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/google-apps-saml-sso/-/qo0aOmaQItsJ.

[karthick sugumaran]

Hi Scott,

 

I am trying to do the IdP-initiated SSO GoogleApps using PingFederate. Aim is Users in Active Directory wants to authenticate and get into Google Applications as federated single-sign-on. I have done Sp-initiated-SSO PingFederate with GoogleApps. When I am trying to do the IdP-intiatiated SSO in browser getting the error as "The required response parameter RelayState was missing".

Why I am getting this error Please suggest me on this?

One more thing, Is IdP-initiated-SSO possible in GoogleApps with PingFederate??? In this Google forum i have seen that you done IdP initiated with GoogleApps??

Could you Please tell me how to do  and Suggest me, whether IdP-initiated-SSO is possible in GoogleApps with PingFederate or not?

 

 

Thanks & Regards,

Karthick