openid in the fedora services

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.

patrick@fedoraproject.orgContact: