multiple assertion consumer services

[dcwatson]

I'd like to be able to support multiple assertionConsumerService entries for a single SP. I believe this boils down to the assertionConsumerService setting accepting a dict (for backwards compatibility using a single ACS) or a list, where each item would also have an "index" key (maybe optional to use the position in the list). Obviously the metadata output would need to be updated, and I'd like to be able to pass in an ACS index into the authentication request to tell it which ACS URL to use.

I don't mind doing the work to create a PR for this, I just wanted to make sure it was something you were interested in supporting.

Thanks for all your work on this library!

[pitbulk]

The implementation seems ok. I will review it deeper to validate.

btw, I'm trying to understand what use case are you trying to cover with multiple ACS endpoint.
do you plan to support HTTP-POST and HTTP-Redirect or just different endpoints for HTTP-POST?

[dcwatson]

Different POST endpoints. I'd like a single SP that can connect to multiple IdPs, but be able to know which IdP a login came from by which ACS endpoint was POSTed to. And ideally I want to know all this before I parse the SAML response, i.e. based on the URL, so I can properly handle ADFS lowercasing (for instance). Imagine a Django app with an IdP model and a single set of views (metadata/login/acs) and URLs like:

/sso/metadata/
/sso/login/<slug>/
/sso/acs/<slug>/

[pitbulk]

The use case you describe is already possible with:

/sso/metadata/<slug>/
/sso/login/<slug>/
/sso/acs/<slug>/

So each slug is associated with a python3-saml setting, and there you can define an specific IdP + advanced settings.

See for example: https://github.com/MindPointGroup/django-saml2-pro-auth
Even at python-social-auth you can define multiple IdPs.

[dcwatson]

True, I guess a better example would be using the same SP for multiple sites that potentially want different attributes or session handling or the like. There are plenty of shibboleth examples with multiple POST ACS to different locations, just seems like it would be nice for this library to support that as well.

[pitbulk]

if a site want different attributes, then a different SP need to be used since "requested atrributes" are set at SP level, not at endpoint level.

I underestand that in some corner cases, makes sense to offer different endpoints to process the same SAMLResponse but processing it different.

That can be easily managed by an extra POST parameter (not related with SAML).

I will think about pros/cons adding that feature and let you know.
Right now Im worried about:

• Adding complexity to the code.
• Why only ACS and not also SLS.
• More documentation required to add that feature.

[dcwatson]

Right, we want to request the superset of attributes for all sites from the IdP, then do per-site mapping at the SP level. Obviously up to you whether you want to support this feature. I can add more tests or docs if you decide you want it.

…

On Fri, Jun 22, 2018 at 7:30 AM Sixto Martin ***@***.***> wrote: if a site want different attributes, then a different SP need to be used since "requested atrributes" are set at SP level, not at endpoint level. I underestand that in some corner cases, makes sense to offer different endpoints to process the same SAMLResponse but processing it different. That can be easily managed by an extra POST parameter (not related with SAML). I will think about pros/cons adding that feature and let you know. Right now Im worried about: - Adding complexity to the code. - Why only ACS and not also SLS. - More documentation required to add that feature. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#102 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAR6RQT-QLAmtXYnUlp53abiaYgPh19jks5t_NVqgaJpZM4Uykfl> .