Can I allow any SAML Identity Provider on my site?

0
votes

I have a web app that I want to allow my users to log into via SAML. I want to allow them to configure their Identity Provider by providing IdP Login URL, Logout URL, Certificate, etc., or just a metadata url.

Also, some of my customers want to set up and use their own internal Identity Provider.

My question is, once keys are exchanged, signatures are verified, etc., how can I trust that the Identity Provider is safe? When the SAMLResponse comes in (particularly via IdP-initiated SSO), how do I know that the email address in the NameID element relates to a legitimate user who wants to log in? What prevents them from sending my own email address to log in as a site admin?

I have read a lot of the SAML 2.0 spec, and answers here, and blog posts, but I haven't seen a specific solution to this question.

2
samlsaml-2.0

2 Answers

1
votes

Before jumping into your question, I think it is important to be clear about the SSO authentication flow.

For SAML 2.0, there are two parties involved, which are Identity Provider (IdP) and Service Provider (SP). They use protocol endpoint and certificate to do back-channel (server-to-server) communications.

With that said, you have all sorts of networking-layer process to ensure the communication process is secure and no man-in-the-middle attacks would happen.

Then back to your original question, I think it contains the following two topics, if correct:

  1. SAML 2.0 metadata
  2. SAML 2.0 attributes mapping

configure their Identity Provider by providing IdP Login URL, Logout URL, Certificate, etc., or just a metadata url.

These are all SAML 2.0 required metadata, so you can configure it yourself, or trust your partner to do in your way (by in your way I mean the different SAML 2.0 federation servers have its own set of metadata, but generally they should be the same).

once keys are exchanged, signatures are verified, etc., how can I trust that the Identity Provider is safe? When the SAMLResponse comes in (particularly via IdP-initiated SSO), how do I know that the email address in the NameID element relates to a legitimate user who wants to log in? What prevents them from sending my own email address to log in as a site admin?

  1. IdP has to be safe, as if they got hacked (social engineering), they can login to your app.

  2. SAML attributes mapping, aside from the SAML_SUBJECT, there are other attributes you can use to determine what is the role for the SAML_SUBJECT (if we can talking about provisioning), or you can have predefined role mapping to that user (SAML_SUBJECT) to determine the role.

Because SAML is just for authentication and exchange the trusted info for the user, how to use the information in the mutually agreed SAML payload need to be implemented by the SP application.

Regarding the token manipulation that commented by @nzpcmad, I think it is possible, this is so called contract fulfillment in PingFederate when PingFederate talks to SP app via OpenToken adapter. And Okta, OAuth0 both have similar concepts like that.

Hope this answers your question.

0
votes

You can't alter the SAML token because it's signed.

Ultimately, it's up to you to check on all these IDP.

Federation is a manual process for that reason.

If you federate, you trust.