Hi Thai, If the "Email" link is to http://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 URL http://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 -~----------~----~----~----~------~----~------~--~---
