search

SAML-Toolkits / python3-saml

MIT License
670 stars 302 forks source link

Generic metadata, not tied to an IdP #176

Open JEphron opened 4 years ago

JEphron commented 4 years ago

Consider a situation where python3-saml is being used to service many SAML-enabled users across multiple IdPs. As the library requires a complete Settings object to generate the metadata, every organization with an IdP configuration needs their own distinct metadata endpoint (possibly distinguished by just a query parameter, but still we need to load up their IdP configuration before we can return the metadata). Is this a fundamental restriction of SAML, or could this library support a "one-size-fits-all" metadata endpoint to be shared by customers regardless of their IdP?

pitbulk commented 4 years ago

There are ways to handle the approach of 1 unique SP serving multiple IdPs.

1) Discover IdP by a Parameter. The SP endpoints will have an extra parameter 'idp' with a number that identifies the registered IdP, so when a SP receive a SAMLResponse at the ACS URL, it will get the idp parameter, retrieve the idp metadata, build the settings and then process the SAMLResponse

2) Read the Issuer from the SAMLResponse and see if it matches a registered IdP Entity ID. That method, in my opinion, is worst, but also does the trick.

JEphron commented 4 years ago

Sure, those are reasonable options for the auth endpoints. I'm asking specifically about the metadata endpoint. Do you 100% need the IdP configuration in order to generate the metadata?

coler-j commented 2 years ago

Read the Issuer from the SAMLResponse and see if it matches a registered IdP Entity ID. That method, in my opinion, is worst, but also does the trick.

@pitbulk resurrecting old issue, but why do you think this is the worst way to do things? I am just looking at implementing this at the moment. Just wondering what the pitfalls were. I have a recollection of some IdPs not having different Issuer URIs across tenants (maybe WS-Federation?)... but have not gotten that far yet.

pitbulk commented 2 years ago

Method 2 will require you to:

  1. Inspect the SAMLResponse first in order to extract the Audience value element.
  2. Loop over all the registered IdP settings and verify that one matches such Audience value.

In addition, you will need to implement something in order to avoid tenant A registering the IdP Entity ID of tenant B in order to try to impersonate it. Is important to isolate properly tenants, see for example this severe bug Office 365 experienced: https://bratec.si/security/2016/04/27/road-to-hell-paved-with-saml-assertions.html