How to setup Shibboleth SP for a multi-tenant application

[田 登]

Peter, Thank you for your great information.

> You can do authorization per org (though using the org's entityID is
> also a bad model, better to base authorization on the attributes sent,
> i.e., ABAC) and you can initiate logins to different IDPs based on
> vhost or path (and there are alternatives to that, too, by using IDP
> discovery) -- all without the use of Overrides or cerating dozens of
> virtual SPs.

I didn't know what's the better/best solution when using Shibboleth as
my sp in the front of my SaaS application.

I simply want to use one single SP (here Shibboleth) instance, and the
Shibboleth sp need be configured to serve more than one orgnization
using different idps.

It seems you recommend that vhost or path be used for this purpose,
since my SaaS application only has one global URL serving all the
members across different orgnizations, I would like to have a try with
virtual directories (pointing to the same physical location).

My service need be online 24x7, I cannot afford to restart my services,
so I considered using the Overrides settings of Shibboleth, because
settings file of Shibboleth will be reloaded automatically once its
timestamp is changed. Is this reasonable ?

-Daniel


On 2018/02/09 21:41, Peter Schober wrote:
> * den at scsk.jp <den at scsk.jp> [2018-02-09 10:43]:
>> But my application has only one global URL, I want to know, whether
>> I could add this SSO feature supporting multi tenant application
>> (with only one server instance)
> 
> "Only one global URL" is the recommened model and the Shib SP supports
> it out of the box. Your service URL is your service URL, no matter
> who is accessing it, that's federation.
> 
> Multi-tenency is something else: You virtually multiply the service
> artifically in order to pretent that each tenent had its own
> instance.
> 
>>  <Host name="service.university.org" authType="shibboleth" requireSession="true">
> 
> That's not what you said above, though? Here you're creating separate
> service access URL for each organisation (here
> "university.org"). That's not recommended, despite its popularity in
> SaaS offerings.
> Or have you already fallen into the trap of deploying one
> ("physically") separate SP for each customer's instance of your
> application? That arguably would be worse, IMO.
> 
>>          <ApplicationOverride id="same-app_aliasA" entityID="https://idp_A.university.org/shibboleth">
> 
> So Instead Of Posting Configuration snippets why not start with
> describing what exactly it is you're trying to do?
> 
> You can do authorization per org (though using the org's entityID is
> also a bad model, better to base authorization on the attributes sent,
> i.e., ABAC) and you can initiate logins to different IDPs based on
> vhost or path (and there are alternatives to that, too, by using IDP
> discovery) -- all without the use of Overrides or cerating dozens of
> virtual SPs.
> 
> -peter
>