Identity federation and strong authentication

Editor's Notes

• #3: Thank you for inviting me back to Denmark! Sorry today’s keynote is going to be in English. Your English is better than my Danish.
• #4: However, I’m learning a couple words thanks to friends!
• #5: The most important Danish word I know
• #6: This is a magical country of the happiest electrical outlets ever
• #8: Independent consultant out of Boston in the US
• #9: I’ve contributed to a number of open standards around internet security
• #10: I’m an active contributor, editor, and working group chair in several organizations.
• #11: I’m even writing a book about OAuth 2 and it’s up for pre-order now: https://www.manning.com/books/oauth-2-in-action
• #12: Why are we talking about me, anyway? This talk is about identity.
• #13: But not about the same kind of in person introduction that we just did, something that happens online
• #14: When a user meets an application, the application wants to ask one question:
• #15: It can ask for a number of reasons: security, personalization, etc.
• #16: But when the user is sitting there at the application it wants to ask the user for some kind of verifiable indicator of who they are.
• #17: Usually it can just ask the user to present something
• #18: Something like a password: a remembered codeword, a shared secret that we can remember the user by. When the user tells us that password, we believe it’s them.
• #19: But this means that the user needs to make these passwords for every application, and manage them (keeping them secret and unguessable).
• #20: The user’s probably going to re-use the same secret at a bunch of different places.
• #21: And now my application needs to manage these secrets for all different users, and I’m probably going to get that wrong.
• #22: The real problem is that this is a shared secret
• #23: A secret that’s shared isn’t very secret anymore. Two men can keep a secret if one of them is dead.
• #24: We can can hash the secret on the server side, but the user still needs to present it plain.
• #25: What if I had something that could hold all my keys? That helps the user a bit but we’re still relying on secrets.
• #26: And make new ones when needed? That’s even better since I won’t reuse them as much. Granted, at this point, we’re authenticating the presence of the key holder more than anything.
• #27: Since the user presents their secret directly to me, I can replay that secret to others and pretend to be them.
• #29: More detail from the approaches in this talk is available in a whitepaper I wrote for Yubico earlier this year.
• #30: First thing we’re going to try is changing who you ask
• #31: Normally the site asks the user directly who they are
• #32: We’re not going to do that this time and instead ask someone else.
• #33: Enter the identity provider, or IdP.
• #34: Now we’re doing federation between multiple parties.
• #35: OpenID Connect is a federation protocol that helps us to solve this
• #36: The user goes to the site as usual.
• #37: Instead of asking the user for their password, the site sends the user to the IdP to prove who they are.
• #38: User authenticates again, but this time it’s to the IdP
• #39: IdP gives the user an indicator that they’ve logged in
• #40: User hands that indicator back to the site to prove they’ve logged in
• #41: Site can verify the indicator and figure out which user is at the front door. This completes the login process.
• #43: Federation lets us swap out the different modules of the system
• #44: We can run a new IdP with the same user and site, and they look like a new user
• #45: Different users can use the same IdP and site and look like different users
• #46: A user can use their same IdP at multiple sites.
• #47: The federation protocol requires the user to authenticate to the IdP but it doesn’t say how
• #48: The user can swap out their password at any time and the rest of the system still functions
• #49: We can use alternative login mechanisms
• #50: Even invasive biometrics
• #52: In federation you need to trust the IdP to do the right thing, but…
• #53: An Evil IdP can lie to you
• #54: The Evil IdP can tell you that a different user has shown up than was actually there
• #55: The Evil IdP can tell you that someone’s logged in when they haven’t
• #56: Remember that whole passing the user’s credentials around? That turns out to be a really useful use case: calling a secondary service on behalf of a user
• #57: But with a (good) federation protocol, you can’t do that: the second site won’t accept a token sent to the first site.
• #58: Thankfully that’s exactly what OAuth 2 is for, a delegation protocol.
• #59: I know a good book to recommend! https://www.manning.com/books/oauth-2-in-action
• #61: We’re still going to ask the user for something
• #62: We asked them for a shared secret before, but
• #63: But we’re not going to ask for that this time.
• #65: Remember that device that we had before that managed our keys?
• #66: We’re going to look at a device that does something like that, but not with passwords
• #67: Instead of a password, we use the device
• #68: The device creates a key pair for the site
• #69: We send the public key to the site but hang on to the private key.
• #70: When the user goes to log in, we present the device with a challenge to sign.
• #71: The device uses its private key to sign the challenge. If the signature matches the public key that we’ve stored previously, then we’re good and the user has logged in.
• #72: If a different device is used, the signatures won’t match and the user isn’t logged in.
• #73: One device can register keys to multiple sites, and each site gets its own key.
• #75: Remember we’re not talking to the user directly during authentication, we’re talking to the device.
• #76: We’ve got a lot of confidence in whether the device is there or not.
• #77: But we don’t actually know anything about the user at this point. No attributes.
• #78: In fact, anybody could be using the device at the time the keys are validated
• #79: If you lose the device, you’re out of luck
• #80: We can combine our approaches, using the strengths from each
• #82: Remember that we can use any kind of authentication at the IdP
• #83: So let’s use strong authentication with the device, but this time at the IdP
• #84: We can still use the identity federation protocol just like usual
• #85: But now the account at the IdP is protected with a stronger credential than before, ideally in addition to another credential. The strength of this credential can be carried by the federation protocol to the RP. The RP doesn’t need to manage the strong authentication itself to benefit.
• #87: Remember, we can use the federation protocol to get attributes and identity information about the user, but we need to trust that the IdP has authorized the user
• #88: And we can use strong authentication to verify the presence of a keypair device, but we don’t get any information about the user
• #89: We can use them both at the RP at the same time. We get identity and attributes from the IdP and assurance of a known device directly from the second factor.
• #91: OpenID Connect and U2F work very well together. The strengths of these protocols complement each other. They both do authentication, after a fashion, but tell you very different things. OIDC tells you who the user is, according to an IdP, and U2F tells you that a key device is present.
• #92: And now I’m completely out of Danish. Thank you.
• #93: If you have any questions, feel free to contact me.