Hi Alex, Thanks for your prompt response and suggestions. I will try to generate SAMLReponse without the SAMLRequest and see how it goes.
I am wondering how others avoid (or solve) this problem. I tried to argue with the management this is the user's fault that they did not log out or at least quit the browsers. :-) Thai On Jul 7, 6:30 pm, "Alex (Google)" <[EMAIL PROTECTED]> wrote: > Hi Thai, > > If the "Email" link is tohttp://mail.google.com/a/yourdomain.com, > then this is the expected behavior. When the second user clicks on > the "Email" link the Google Apps session is still active, so > mail.google.com will not re-direct to your sign-in URL. > > You could work around this by changing the "Email" link to go directly > to a page (not google.com) which generates a SAMLResponse based on the > current Portal user. This isn't the way it's intended to work, since > you would have to generate the SAMLResponse without a SAMLRequest and > RelayState, but it is one way of avoiding the behavior you describe. > > Even if you modify the "Email" link, if the second were to type in the > URLhttp://mail.google.com/a/yourdomain.com, he would see the first > user's session. Unless the first user clicks "Sign out" in Gmail or > closes the browser, there is no way for Google Apps to distinguish the > second user from the first. > > -alex > > On Jul 7, 5:59 pm, thai <[EMAIL PROTECTED]> wrote: > > > Hi Alex, > > > Please help me out on this problem! > > > Here is the flow of our system: > > > 1. User log-in to our Portal. > > 2. Click on an "Email" link, this link points to our SSO servlet. > > This servlet can determine if a user already logged in to our > > Portal or not. > > 3. If user already logged in to our Portal, the servlet will make a > > SAMLRequest. > > If user haven't logged in (mean user types the URL to access SSO > > servlet from the browser) servlet redirects to our Portal's log-in > > page > > 4. Google Apps sends a SAMRequest to our SSO servlet and the servlet > > will sign and post to ACS, then logged into Google Apps. > > > It had been working fine if users click on the "Sign out" link from > > Google Apps. > > > If a user did not click "Sign out" but just close the Google Apps > > window (or tab) and the browser is not quit. > > > The next user log-in to our Portal and click on the "Email" link: At > > step #3 when the servlet make a SAMLRequest, Google Apps did not send > > back the SAMLrequest but instead log-in to the previous user's session > > and therefore a previous user's mailbox. > > > Could it be a flaw in the design? > > > As you pointed out if I can make a second post to ACS, Google Apps > > will kill the previous session but I can't not make the second > > SAMLRequest and therefore could not make the second post to ACS. > > > Please help! > > > Thanks, > > > Thai > > > On Jul 2, 4:58 pm, "Alex (Google)" <[EMAIL PROTECTED]> wrote: > > > > Hi Thai, > > > > Thanks for the detailed scenarios. When you post another response to > > > the ACS URL, it's suppose to invalidate any existing sessions and > > > create a new session. From what you described it sounds like that's > > > not happening (without the IFRAME logout). I haven't been able to > > > reproduce this behavior. > > > > Is there any chance the login form or the ACS form was cached by the > > > browser? > > > > Btw, we've had reports from other admins that using an IFRAME doesn't > > > set (or clear) cookies in Internet Explorer due to lack of P3P > > > support. Here's an earlier thread on this topic: > > > >http://groups.google.com/group/google-apps-apis/browse_thread/thread/... > > > > -alex > > > > On Jul 2, 12:53 pm, thai <[EMAIL PROTECTED]> wrote: > > > > > Hi there, > > > > > If I read it correctly, the problem is not about the PHP code but it's > > > > about usability. > > > > > > 1. User logins to [EMAIL PROTECTED] and goes to its mailbox > > > > > 2. User doesn't press signout button and returns back to login page > > > > > 3. User logins to [EMAIL PROTECTED] and goes to its mailbox > > > > > 4. User again doesn't press signout button and returns back to login > > > > > page > > > > > 5. (!!!) And now user try to login to somebody else's mailbox > > > > > [EMAIL PROTECTED] with any password and he logins successfuly to the > > > > > mailbox he doesn't own! > > > > > The #2 stated that the user did not press the signout button. This is > > > > where the problem occurred. > > > > It's the cookies that still active. > > > > > I ran into the same problem but I have only one domain. > > > > 1. user logged in as [EMAIL PROTECTED] and went to mailbox. > > > > 2. user DIDN'T press the signout button and go back to the login page. > > > > 3. user logged in as [EMAIL PROTECTED] using the same browser (and the > > > > browser has NOT been close and re-open) and get a's mailbox. > > > > > Same scenario as above but at step #2, user quit (exit, close) the > > > > browser and re-open the browser in step #3: user will get b's mailbox. > > > > > it's the cookies!!! > > > > > I resolve the problem (not very elegant but it works) by put in logout > > > > URL in the login page. > > > > <iframe src="https://mail.google.com/a/your.domain.here/? > > > > logout&hl=en"></iframe> > > > > > Hope this help! > > > > > Thai Nguyen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Apps APIs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-apps-apis?hl=en -~----------~----~----~----~------~----~------~--~---
