Hi Ram, I don't have any sample code as you described. Maybe someone else in the group has some code they are willing to share.
-alex On Aug 17, 11:24 am, rsakamuri <[EMAIL PROTECTED]> wrote: > Hi Alex, > Can you send me a sample code to send SAMLRespose without SAML Request > for email address > > Thanks > Ram > > On Jul 12, 7:20 am, "Alex (Google)" <[EMAIL PROTECTED]> wrote: > > > Hi Ajit, > > > You could try what I suggested earlier in the thread. Let us know if > > the workaround works for you. > > > -alex > > > On Jul 9, 6:01 am, Ajit <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > We are also facing thisSSOissue, please let me know if there is any > > > possiblesolution. > > > Thanks, > > > Ajit > > > > On Jul 8, 7:10 pm, thai <[EMAIL PROTECTED]> wrote: > > > > > 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 ourSSOservlet. > > > > > > 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 accessSSO > > > > > > servlet from the browser) servlet redirects to our Portal's log-in > > > > > > page > > > > > > 4. Google Apps sends a SAMRequest to ourSSOservlet 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'smailbox. > > > > > > > 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 IFRAMElogout). I haven't been able to > > > > > > > reproduce this behavior. > > > > > > > > Is there any chance theloginform 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 itsmailbox > > > > > > > > > 2. User doesn't press signout button and returns back > > > > > > > > > tologinpage > > > > > > > > > 3. User logins to [EMAIL PROTECTED] and goes to itsmailbox > > > > > > > > > 4. User again doesn't press signout button and returns back > > > > > > > > > tologin > > > > > > > > > page > > > > > > > > > 5. (!!!) And now user try tologintosomebodyelse'smailbox > > > > > > > > > [EMAIL PROTECTED] with any password and he logins successfuly > > > > > > > > > to the > > > > > > > > >mailboxhe 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 tomailbox. > > > > > > > > 2. user DIDN'T press the signout button and go back to > > > > > > > > theloginpage. > > > > > > > > 3. user logged in as [EMAIL PROTECTED] using the same browser > > > > > > > > (and the > > > > > > > > browser has NOT been close and re-open) and get a'smailbox. > > > > > > > > > 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'smailbox. > > > > > > > > > it's the cookies!!! > > > > > > > > > I resolve the problem (not very elegant but it works) by put > > > > > > > > inlogout > > > > > > > > URL in theloginpage. > > > > > > > > <iframe src="https://mail.google.com/a/your.domain.here/? > > > > > > > > logout&hl=en"></iframe> > > > > > > > > > Hope this help! > > > > > > > > > Thai Nguyen- Hide quoted text - > > > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
