Using a single SP endpoint to handle multiple IdPs

[MartinFalatic]

If I wanted one endpoint that can service multiple IdPs, it would be advantageous to be able to peek at the encrypted data to get information as to which user the request came in from, and in turn use that to determine which cert to verify the signature against.

But is such a thing possible with this library (again, without parameters or unique endpoints)? Multiple targets would work, but would add their own security considerations.

I could disassemble and decrypt the payload myself to get that initial information, but that would duplicate code (though it might come down to that).

[MartinFalatic]

OneLogin_Saml2_Settings and OneLogin_Saml2_Response appear to do the job here - I still end up using OneLogin_Saml2_Auth when I have the certificate(s) of interest, but this preprocessing allows me to narrow down the list to something manageable.

However, if you have any other thoughts on the matter I'd welcome them.

[pitbulk]

My recommendation is to create different endpoints per IdP and then you can load its SAML settings and then process the Response.

If you have 1 unique endpoint,

• what happens if 1 user is registered in multiple endpoints?
• what happens if there isn't a direct way to relate a user with an IdP (For example imagine you don't match users on IdPs based on the domains, and the user does not exist yet on the final app).

[MartinFalatic]

• The "endpoint" that matches their IdP is the only one we're interested in.
• The user is always related to one (or more) IdPs - and if they aren't in the system their first association should be with that IdP.

I appreciate the input - I realize this isn't ideal for all situations, but for the given constraints this single endpoint does the job. When I first started with this package I wasn't sure if it could even work (thus my question).

[pitbulk]

You can implement the X IdP -> 1 unique endpoint concept.
Your SP data will be unique, the IdP data will change based on something you will need to figure out.

Recognize the user to later retrieve a relation to an IdP, as I mentioned, isn't easy/secure.

My proposal: You can read the Issuer of the SAMLResponse and then recover its IdP data if is registered on your SP.

The Response class has the get_issuers method.

P.S With the current implementation, you always gonna need to parse the SAMLResponse 2 times, 1 to retrieve the Issuer, another to validate the SAMLResponse if you do it at the Auth class.
So I recommend you in order to improve performance to extend the Auth and SAMLResponse classes to accept a Response object (the one already processed when retrieving the Issuer) on the processSSO method.

[MartinFalatic]

That's basically what I ended up doing for this iteration.

[lm-sousa]

This might be a good feature addition to this package, if the authors agree.
It's something I will be working on for a future iteration of a project I'm involved in.
@MartinFalatic Are you able to share your code and/or create a pull request?

[MartinFalatic]

I don't have code that I can share, but if I were going to do this in a more scalable way (for handling lots of providers) I'd do what @pitbulk suggested and extend the classes. Time constraints and a limited handful of providers didn't make that a priority.