SSO Implementation

Raz's gajula.rajashekhar at
Sun Nov 4 21:12:51 EST 2012

You(Nate, Scott & Peter) are doing great job for all our doubts and queries
with a lot of patience, Thanks a lot to you all once again......:)

Finally we are succeeded our requirement in implementation of SAML on our we are going to implement it on our production servers so
kindly share your valuable suggestions to avoid security breaches /
necessary things to do before implementing SAML on production servers.

- Raja.

On Fri, Nov 2, 2012 at 2:05 PM, Peter Schober <peter.schober at>wrote:

> * Raz's <gajula.rajashekhar at> [2012-11-01 19:15]:
> > For us, sessions should be separate for the vhosts (dev & test) even if
> > they are registered at the same IDP so what do you suggest to over come
> the
> > above scenario?
> What kind of real-world set up are you perparing for that requires all
> users to use the same instance of a webbrowser on the same machine,
> with an active session to the IdP? It's far from a common scenario to
> have several users share the same HTTP User Agent at the same time.
> If you want to test several users accessing your apps and sharing the
> same IdP a more realistic scenario (and one which would actually work)
> is using two seperate HTTP User Agents (or one in "private" browsing
> mode, not sharing state with the other).
> Also you're trying to achieve many things at once (without fully
> understanding them, it seems) and mixing them all into an existing,
> rather confused thread:
> User switching in the same browser is one thing, forced authentication
> another. As is configuring your webserver and SAML metadata for one
> vhost per "customer". Logout yet another. (I'm sure I left out a few.)
> I'd concentrate on one thing at a time, and make that work. Them move
> on to the next one,
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the users mailing list