Shibboleth handler invoked at an unconfigured location

reda sabir sabiretude at
Wed May 18 05:26:31 EDT 2016


I found  a more simple solution:
 In some implementation of SAML, we can set the scope of cookies. For
instance, I can try to make all websites have a common domain name like and so the websites will be:, and so on. This will allow me to share the cookie between
the websites by setting the cookie scope to 2 or set the cookie domain Can we do this in Shibboleth SP. I've found this in the
<<The SP uses a setting called cookieProps
<> that
controls the properties used in the creation of all of the cookies it sets.
In particular, whether the cookie is limited to https requests, the domain
and path, and other properties such as the HttpOnly flag can be set by the
deployer and so will vary between sites. However, by default in the latest
version, the cookies are scoped to the fully-qualified host, with a path of
"/" (the whole host), and the HttpOnly flag set. They are not marked
"secure" by default due to the prevalence of testing done without https,
but this is a recommended change.>>
However, I didn't found how we can modify the scope of Cookie.


2016-05-17 19:40 GMT+02:00 Peter Schober <peter.schober at>:

> * reda sabir <sabiretude at> [2016-05-17 18:30]:
> > And now I understand, me,  why you have difficulties to accept the
> solution
> > of One SP with Multiple IDP. I was so engaged on the technical part
> > (Shibolleth) that I didn't realize that it's not possible.
> > As you have said we can't have SSO for the simple reason: The session
> > cookies can't be sent to another vhost  because they have different FQDN
> > and at the end, the only thing that associate me the user with a session
> in
> > Server is Cookies. So I'm in trouble.
> If the vhosts share a common DNS domain you could try to forgo
> SAML-based SSO (involving a set of IDPs) and instead use a shared
> domain cookie across all services. (Either the Shibboleth SP's session
> cookie or an application cookie initially bootstrapped from one Shib
> SP session and shared across all vhosts).
> > We can say then it's impossible to have SSO with one SP and multiple
> Only if you mandate that each vhost can only be accessed from a
> different IDP, even though you want all vhosts to be accessible from
> all IDPs. (That's a contradiction to some degree.)
> > So a solution for my case could be to make some proxy where I could send
> a
> > cookie when I'm authenticated and if not it will resend me to the right
> > IDP.
> While you could have a common authentication system for all IDPs
> (basically implementing another SSO system to protect access to the
> IDPs) that would essentially cause all IDPs appear as one system, with
> one login screen (unless you integrate IDP-specific branding into that
> abstracted authentication system).
> > Can we do this in Shibboleth?
> It's always about the details.
> > I mean I know there's IDP Discovery but can it work by taking into
> > account parameters (in header or in request GET or POST). For
> > example, if I pass it will redirect me to
> > and so on? Or if I pass the it will send me to it?
> Sorry, I can't wrap my head around this now.
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list