Shibboleth handler invoked at an unconfigured location

[reda sabir]

Hello,

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
company.com and so the websites will be: site1.company.com,
site2.company.com 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
company.com. Can we do this in Shibboleth SP. I've found this in the
documentation:
<<The SP uses a setting called cookieProps
<https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions> 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.

Reda


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

> * reda sabir <sabiretude at gmail.com> [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
> FQDN.
>
> 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 site1.com it will redirect me to idp.site1.com
> > and so on? Or if I pass the idp.site1.com 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 shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160518/d544fc0b/attachment.html>