openid in the fedora services
TRANSCRIPT
In the Fedora services
Patrick UiterwijkPresented by
Intern, Red Hat, Inc.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
OpenID
Today's Topics
1. What is OpenID?
2. How does it work?
3. Extensions we use
4. Deployment status
What is OpenID?
Federated authentication
URL is identity
Saying WHO you are, rather than WHAT you are
What is OpenID?
How does it work?
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
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
But.....It's not that simple(though this is all the user sees)
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
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
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
Extensions we use
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
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
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
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
Deployment status
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
FedoraHosted trac login
COPR
Tagger
Hyperkitty
Jenkins
Services migrated
Bodhi
Pkgdb
Elections
Wiki
Fedocal
Blockerbugs
.....
Services being migrated
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
Questions?
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.