Shibboleth handler invoked at an unconfigured location

[reda sabir]

I can assure that we are now converging to the right understanding of the
problem. As you have commented, there's two possibilities for the project :

   - Multiple SP and One IDP
   - Multiple IdP and One SP

You have suggested to make multiple SP and write only one IDP, I think it's
the better solution because it's more logical : there's only one user
store. But the thing is we are only responsible for SP part and not IdP :
Believe me when you work in big project, you get this weird and complicated
situation. What's more is that a company deploy IdP part and the SP is done
by our company.What's more the IdP company is our client and they already
chosen the fact that they will create multiple IdP. So given all theses
circonstances, the only solution that is left is Multiple IDP and One SP.

That's why we should stay with multiple vhost with one SP (the entityID is
never overrided, only SSO part and metadata of the idp is changed).

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

> * reda sabir <sabiretude at gmail.com> [2016-05-17 15:16]:
> > - 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).
>
> Commenting on other aspects of the above, at the risk of confusing you
> further -- this is getting ever more complicated and convoluted, not less:
>
> If you're now saying that the IDPs' login pages need to be changed
> depending on the vhost accessed at the SP, then yes: Then each vhost
> at the SP would need to become a logically seperate SP (using
> Overrides), each with its own entityID and its own Metadata. This is
> because the level policy applies to in SAML is the entityID, so the
> IDP would only be able to tell apart SPs with seperate entityIDs.
>
> Now, if you're saying there's only one user store (authentication
> source) shared by all the IDPs, and that the only difference between
> all those IDPs is their login page design, then you could well do all
> this with a single IDP installation:
> The Shibboleth IDP's login page can be branded based on the SP
> accessed. So instead of creating dozens (or whatever the number of
> virtual IDPs were talking about here) of IDPs you could have a
> customized login page for each org unit in a single IDP installation.
>
> Of course branding the IDP login page depending on the SP is
> semi-pointless, as the login page is only shown once as long as your
> browser has an SSO session with the IDP. I.e, starting with a fresh
> browser accessing foo.example.org you might be promoted for login at
> idp.example.org with a foo-specific design. But later accessing
> bar.example.org will NOT prompt the same subject to authenticate at a
> bar-branded login page, instead you'd experience SSO and be logged in
> at the bar SP. (Which is what the subject wants, likely.)
> -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/6d20a80f/attachment.html>