Question : Multiple tenant SP has to offer ACS dynamically

[Malshtur]

Hello,

I am working to port SAML to a multi tenant application where each tenant has its own database. So every tenant manage its own users, objects, etc.

The issue I am trying to resolve has to do with our authentication scheme requiring to specify what tenant the user authenticates to. I have considered the three following approaches :

• Use RelayState : I would rather have all the informations packed in the AuthnRequest and Response. Security can be an issue and it feels somehow not natural.
• Use different AssertionConsumerService : At metadata level it is an issue. The application could create a new tenant leading to obsolete metadata not referencing the new ACS conresponding to the new tenant. Each tenant creation leads to metadata changes. Not acceptable in my case.
• Use different AssertionConsumerServiceUrl : in AuthnRequest with mandatory signature and checking that urls are pertinent offers me the flexibility I hope to have. It would lead to the least amount of modification in configuration. No metadata modification

The latter is my preffered way to go but I can't wrap my finger around if it is possible with djangosaml2. Could you point me in the right direction if you support it ? If it is not the case I am only trying to find how to do it at pysaml2 level but I have no luck so far.

Thanks for your time.

[peppelinux]

Yes, option 3 is very good

you just have to inherit https://github.com/IdentityPython/djangosaml2/blob/master/djangosaml2/views.py#L408 and then you can do overload of the method post_login, custom_redirect or whatever

then you have to map your new ACS to a specific urls (urls.py of your project) and also map it in the metadata, defining its url/webpath in the pysaml2 configuration, here (to get signed metadata automatically):

https://github.com/IdentityPython/djangosaml2/blob/master/docs/source/contents/setup.rst#pysaml2-specific-files-and-configuration

[Malshtur]

Thanks for your reactivity and the details, truly fast !

Just to be sure we are talking about the same thing, in saml-core : `AssertionConsumerServiceURL [Optional] Specifies by value the location to which the message MUST be returned to the requester. The responder MUST ensure by some means that the value specified is in fact associated with the requester. [SAMLMeta] provides one possible mechanism; signing the enclosing

message is another. This attribute is mutually exclusive with the AssertionConsumerServiceIndex attribute and is typically accompanied by the ProtocolBinding attribute.` From your response, I guess that it would lead to metadata modification on SP side and to update them on the IDP too. This is problematic in many deployment. So that is why I wanted to use the second option : signing the enclosing AuthnRequest and have the AssertionConsumerServiceUrl dynamically set in the request without changing the metadata. I hope that I am a bit clearer and please forgive me if I did not understand you the first time. EDIT: Did you mention the hook or overload to do something like selecting the tenant right after reponse is received in order to pass it to the application level ? EDIT 2 : For clarity, what I was thinking is having a new AssertionConsumerService without altering the in metadata as offers the AssertionConsumerServiceUrl field in AuthnRequest.

[peppelinux]

for the security of the solution the IDP should only response to a known ACS, taken from the metadata of the requester

[Malshtur]

In general, i completly agree but if and only if the AuthnRequest is signed then the underlying security is the same because it is based on the same cryptographic keys.

The only case i could think of is that the underlying SP is vulnerable to injections that could lead to sign an AuthnRequest with a malicious AssertionConsumerServiceUrl. This could also modify metadata nonetheless.

The standard allows both as I mentionned above, but if I were to use djangosaml2 as you explained I have to share metadata dynamically between SP and IDP to refresh the list of AssertionConsumerService, right ?

[peppelinux]

right