Shibboleth handler invoked at an unconfigured location

[reda sabir]

Hello again,

I want to start by thanking you for all your suggestion. Therefore, I
didn't understand all the points that you have given but I could answer
your question:

   - The project that I'm working for oblige me to write one SP for
   multiple websites with the fact that each website have it's own IdP. Why
   one SP was chosen?:  The architect has chosen that because of SSO. Each IdP
   has a personalized login page for the website and we can not afford that
   someone see a login page of an other siteweb even if the user store is the
   same. BUT when we are login in a website, we are then authenticated in all
   websites (This is not a constraint of the solution but the behavior wanted).

Now my knowledge let me think that we can not write all the previous
behavior in the metadata. We need to write some codes or use an
implementation that allow such things. Shibboleth was proposed because it
seems that this behavior is allowed with the previous settings (each vhost
is linked to an applicationID). But if you say that there's also a better
and simple alternative, please just develop your idea by taking some
example of configuration (write some pseudo configuration).

Anyway, I'm very grateful for your contribution

Reda

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

> * reda sabir <sabiretude at gmail.com> [2016-05-17 09:18]:
> > So let's summarize our exchange to solve the problem :
> >
> >    - I need to build an SP that will secure multiple websites (each
> website
> >    have it's own FQDN and it's own IDP). This means that if I
> authenticate
> >    into one of my websites, I won't do it again for another one until I
> log
> >    out.
>
> Each web site having "its own IDP" could mean that each website can
> only be accessed from one specific IDP, and access would be denied
> when trying to access it from any other IDP (i.e., after having
> established a session with another IDP, e.g. from accessing a
> different vhost on that server first).
> If that's the intended meaning, and the use of tying vhost to IDP
> merely serves the purpose of avoid IDP Discovery, then you can do that
> with the entityID content setting on each vhost (avoiding discovery)
> *plus* by adding access control rules on each vhost (avoiding access
> from one IDP to a vhost that defaults to another IDP).
> You'd write those access control rules based on SAML Attributes, or,
> if all else fails, by using the IDP's entityID itself in an ACL rule.
>
> Or it could mean that each vhost defaults to a specific IDP but that
> accessing it from other IDPs is fine, too.  Then the steps are the
> same as above, only the access control rules would be different (not
> limiting each vhost to one IDP, but limiting the resource to
> authorized subjects, as you'd usually do).
> -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/20160517/ed1ec6dd/attachment-0001.html>