0

Having successfully integrated my old web forms app with an ADFS server I got to thinking about how the process works as a whole. The old app passes the user to the remote ADFS, then eventually the user arrives back in our server having a signed-in identity of [email protected] but I'm not entirely clear on whether I'm supposed to trust that's right, or whether I'm supposed to try and ensure it's right.

Supposing that a rogue actor at somedomain.com replaces the sign on at the remote end or manipulates it in some way such that my local server ends up being told that [email protected] signed in (when it was actually tom.hacker@somedomain,com), or worse that [email protected] signed in, what do we do with such situations?

Is this handled already by the auth process such that we can be sure there are some local rules that enforce the federated server may only return users with some characteristic such as "must really be a user of somedomain.com, for which you know this identity server is responsible" ?

When we hand off authentication to a third party, and get the "user X auth'd successfully", do we need to be wary about whether it's truly user X and whether the server confirming the identity truly has authority to do so for the user given?

At the moment I'm thinking I should also implement my own local check that the announced user matches a pattern to ensure the federated server isn't used to break into other domains' accounts and also implement 2FA to give some extra check that the user announced truly is that person

3 Answers 3

1

You have to indeed no technical way to verify that a federated identity provider actually verifies user identity on authentication (e.g by requesting username and password). You may audit and test the provider. The provider should state how users are authenticated (e.g. username and password and a second factor in addition). You may be able to check that with an own user account at the federated provider. Alternatively you could ensure that users from a federated provider do only get access to resources which are owned by the same party. It is then in their own interest to use proper authentication mechanisms.

0

The service provider (you) cannot control this, it is the main (if not only) responsibility of the Identity Provider (ADFS).

SP main responsibilities:

  • Ensure user is authenticated based on IDP login assertion message
  • If the message contains user groups, use them (if possible)
  • Create a user if nonexistant in service provider - this is optional but better than getting support emails on Sunday evening asking why the user can't login
0

Supposing that a rogue actor at somedomain.com replaces the sign on at the remote end or manipulates it in some way...

If a rogue actor has compromised the identity server then you are definitely sunk.

Of course, if your organization decided to handle authentication themselves, and a rogue actor compromised your own authentication server, you'd be in exactly the same boat.

Hopefully the team running the authentication server is as good as or better than you at securing it. That would be an important criterion when selecting an identity provider.

At the moment I'm thinking I should also implement my own local check that the announced user matches a pattern to ensure the federated server isn't used to break into other domains' accounts and also implement 2FA to give some extra check that the user announced truly is that person

Hopefully your identity server already performs 2FA, so you'd actually be implementing 3FA. The main downside to these things is the operating cost and user friction. Plus there's always a chance your 3FA system could get compromised too. It's up to your business to assess the risk, cost, and benefit.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .