2

I understand the basic flow of SAML but is still unclear to me where the passwords are stored.

This image shows "APP VERIFIES SAML RESPONSE & LOGS USER IN" from onelogin looks like the password is stored on the APP the SP. enter image description here

But this other one enter image description here suggests the password is stored on the IdP (talentlms).

Where are the passwords stored?

If passwords are saved on the IdP (onelogin) side and are compromised, the attacker could access all the sites, as the attacker would have the master password?

Improve this question
3
  • 1
    The identity provider controls identity validation; this means verifying credentials or other information. How the IdP validates that identity (whether it's via saved passwords, or via a directory service that verifies credentials, or via some other means that doesn't use a password at all) is up to the IdP and its configuration. Commented Aug 24, 2017 at 16:44
  • But your question is confusing, because you are assuming that the IdP somehow has a password vault where that's not necessary; the concept of a "master password" doesn't really make sense. Commented Aug 24, 2017 at 16:46
  • 1
    Why are you concluding that "verify SAML response" means validating a password when the rest of the flow clearly states that the IDP "IDs user"? Commented Aug 24, 2017 at 17:05

2 Answers 2

Reset to default
2

The SP has no knowledge of the password that authenticated the user. All the SP cares about is that an IdP an SP trusts sent it a token that says the user is authenticated. This token is not related to the password in any way. The token is signed by the IdP using a private key, and validated by the SP using the related public key.

Given that, authentication of the user occurs by the IdP. It doesn't have to be a password, but it often is.

Improve this answer
2

IdP's primary role is to "authenticate" the identity claimed by the user - and assure the SP that the user's identity has been verified.

For this, (most commonly), the password must be verified by the IdP - and hence it is stored with the IdP.

In a properly implemented system the SP should never be in a position to "access" the password and/or any other mechanism used to verify the identity of the user. So it is never stored with the SP.

How it works:

Typically, the IdP provides the user with a verifiable token that indicates to an SP that an authentication has been performed successfully. The user passes this on to the SP as "proof of successful authentication". Needless to say, the SP doesn't take the user's word for it. So the SP verifies this token with the IdP and only after confirming that the token is valid, proceeds to the next step (usually the authorization step).

In case of compromise of the IdP: Yes, a compromise on the IdP's side does have higher impact. However, the IdP doesn't need to know all the credentials needed to access the SP's application. So a carefully architected SP application would use at least one attribute of the user; and not use just the token to open up access. The IdP would not aware of that attribute and hence would not be able to access the SP app, masquerading as a user. Hopefully, this is not over-engineered to the level of authentication.

However, I must confess I haven't seen this in practice. Most SPs are thankful just to get the IdP integration working well enough and leave it at that. :)

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.