OpenID in the Fedora Services

Transcript

1. In the Fedora services Patrick Uiterwijk Presented by Intern, Red Hat, Inc. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. OpenID
2. Today's Topics 1. What is OpenID? 2. How does it work? 3. Extensions we use 4. Deployment status
3. What is OpenID?
4. Federated authentication URL is identity Saying WHO you are, rather than WHAT you are What is OpenID?
5. How does it work?
6. Provider The server that verified an identity Relying Party (RP) The website where the user is trying to log in Endpoint The URL of the provider which accepts and handles OpenID protocol messages Claimed Identifier The identity of the user verified by the Provider Some terminology
7. 1. The user browses to an OpenID Relying Party website (e.g. ask.fedoraproject.org) 2. The user clicks on the Log In button 3. The user enter his/her identity URL (puiterwijk.id.fedoraproject.org) 4. The consumer redirects the user to the provider (id.fedoraproject.org) 5. The user authenticates to the provider 6. The user is redirected back to the original website, being authenticated Simple process
8. But..... It's not that simple (though this is all the user sees)
9. How does the consumer know where to redirect the user for authentication? How does the consumer know for sure that the user didn't just browse to its return page, saying it's authenticated? Some issues
10. Consumer does a request to the URL the user provided Returned HTML contains either of the following: HTML tag saying where the endpoint is HTML tag saying where to find the discovery info HTTP header saying where to find the discovery info Now we are ready to redirect the user, right? Well, maybe.. Discovery
11. Stateful After discovery, the Relying Party exchanges a cryptographic key with the provider which is used for verifying the claim at return. Stateless The key is generated by the provider and returned in the response. Whatever happens, the response is validated by requesting a check against the provider. Two operational modes
12. Extensions we use
13. Provide some basic information about the user to the Relying party: Nickname Email address Timezone Used by lots of relying parties to pre-fill registration forms after authenticating with OpenID. Simple Registration
14. Provide access to what type of authentication was used to verify the user: Username/password OTP token Tamper-proof OTP token Also, the Relying Party can require any specific type to be used for authentication to be successful, or have the authentication time out. Provider Authentication
15. Provide group membership information to the Relying Party Relying party sends list of groups it would like to know if the user is a member of The server returns a list of groups the user is actually a member of Named teams because the spec was written by Launchpad team Teams
16. Provide information to the Relying Party whether or not the user has signed a Contributor License Agreement (or any other form of license agreement) Different URL bases for different OpenID providers Extensions defined by us, Fedora team CLA
17. Deployment status
18. OpenID-provider was rewritten from scratch Had been part of the Fedora Account System for many years, but was not following the standards completely, so not compatible with some Relying Parties Added the teams, CLA and PAPE extensions Has been live for about a year now, without major incidents Current provider
19. FedoraHosted trac login COPR Tagger Hyperkitty Jenkins Services migrated
20. Bodhi Pkgdb Elections Wiki Fedocal Blockerbugs ..... Services being migrated
21. OpenID is being used to centralize our authentication Less custom code because FAS backends are less common than OpenID backends Busy moving all services over to using OpenID Last but not least: we support other people using any of the extensions! Summary
22. Questions? This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. patrick@fedoraproject.org Contact: