14:33:17 <mizmo> #startmeeting
14:33:17 <zodbot> Meeting started Sun Aug 11 14:33:17 2013 UTC.  The chair is mizmo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:33:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:33:28 <mizmo> first let me tell you about different parts required for openid
14:33:34 <mizmo> there's the provider, the server that hosts the openid
14:33:46 <mizmo> the web app that hosts the identiy, the url of the website
14:33:55 <mizmo> then the relying party - the website where the user is trying to log in
14:34:25 <mizmo> the user goes to open id relying party
14:34:30 <mizmo> click on log in button
14:34:37 <mizmo> gets redirected to the open id provider
14:34:44 <mizmo> the user auths to the provider
14:34:55 <mizmo> the provider redirect them to the relying party as authenticated
14:34:56 <mizmo> demo
14:35:12 <mizmo> he's going to ask.fedoraproject.org
14:35:18 <mizmo> ask.fedoraproject.org is the relying party
14:35:20 <mizmo> clicks on login
14:35:26 <mizmo> clicks 'open id'
14:36:13 <mizmo> forwards you to the open id provider
14:36:17 <mizmo> which is the fedora open id provider
14:36:27 <mizmo> as you can see, the url here - this is no longer ask.fedoraproject.org
14:36:48 <mizmo> now you're returned to the website you came from
14:36:54 <mizmo> and as you can see, it recognizes me as a valid user
14:36:59 <mizmo> without prompting me for a password here
14:37:12 <mizmo> but it's not as simple as it seems
14:37:21 <mizmo> this is all the user will see, but there are some probs with impementing this
14:37:33 <mizmo> 1) how do you know as the consumer where to redirect the user for auth?
14:37:46 <mizmo> 2) how does the consumer know for sure the user didn't just browse to its return page claming to be authenticated
14:37:48 <mizmo> ?
14:37:58 <mizmo> well, for the first part -
14:38:14 <mizmo> the consumer does a request to the url the user provider
14:38:38 <mizmo> it's a stateful operation
14:38:46 <mizmo> ebfore redirecting the consumer/relying party and provider exchange a key
14:38:53 <mizmo> that they use later on to verify that info is provider by the provider
14:39:06 <mizmo> otherwise you'd be able to send a req to openid saying you were auth'ed without provider knowing about it
14:39:11 <mizmo> the other way is stateless
14:39:34 <mizmo> where the consumer and providing party... the provider generates a key and returnsi n the resonse
14:39:44 <mizmo> whatever happens, the response is validated by requesting a check against thep rovider
14:39:47 <mizmo> yes this is correct
14:39:54 <mizmo> that's the basi cprocess of open id
14:40:02 <mizmo> but in the fedora services group we have some extra features
14:40:16 <mizmo> we also want to provider other services when you log in
14:40:31 <mizmo> if you want to ask the person's email address, then it will ask that and you can provide it
14:40:39 <mizmo> simple registration - provides inf oback to relying party -
14:40:45 <mizmo> nickname, email, time zone
14:40:57 <mizmo> this will prefill your registration details on the relying party site
14:41:06 <mizmo> another website which accepts open id is...
14:41:09 <mizmo> i cant see it, stream is burry
14:41:11 <mizmo> blurry
14:41:16 <flock-ectr103> stackoverflow
14:41:20 <mizmo> ah okay thanks
14:41:40 <mizmo> fedora openid allows this information, asks which information would you like to return to the original website
14:41:57 <mizmo> so if stack overflow asked my name or email address it would show up here
14:42:03 <mizmo> and ask me if i wantd to provide it to the other website
14:42:11 <mizmo> back to stack overrflow... i am authenticated
14:42:52 <mizmo> q: info provided, is there a restriction or can we add more information?
14:43:06 <mizmo> q: there's always a name?
14:43:09 <mizmo> a: yes name is always there
14:43:24 <mizmo> a: not coming from openid by default, comes from registration extension
14:43:47 <mizmo> a: also info exchange extension - more general a lot more things... but we dont use it, this info is all we need
14:44:02 <mizmo> a: the registration extension a way to exchange more general info about a user
14:44:08 <mizmo> next extension we have is provider extension
14:44:17 <mizmo> provider can say to relying party
14:44:31 <mizmo> username and password or more sure of this user because i've used OTP and approved OTP
14:44:48 <mizmo> relying party can use this to determine sensitive/confidential information provided
14:45:18 <mizmo> relying party can require OTP to trust user - if no OTP won't trust user at all
14:45:30 <mizmo> relying party can also require things like, user must have authenticated within past 5 minutes
14:45:50 <mizmo> make sure the user is at the keyboard
14:46:36 <mizmo> another extension - teams
14:46:41 <mizmo> provide group memebership information about users
14:46:52 <mizmo> for example, if app wants to know if you're a packager
14:47:03 <mizmo> you may get access to a number of features - like create an update - if it knows you're a packager
14:47:08 <mizmo> by default in openid thats not possible
14:47:13 <mizmo> that's why we implemented the teams extesnion
14:47:16 <mizmo> to provide group info
14:47:37 <mizmo> relying party can ask, can you tell me when user logs in if they're a memeber of packager or sys admin
14:48:01 <mizmo> q: if youre a packager...
14:48:22 <mizmo> a: provider is still going to authenticate you if you're not, but it will not say you're a packager. so the groups metadata will be empty
14:48:35 <flock-ectr103> demo
14:49:03 <flock-ectr103> jenkins instance of the infrastructure
14:49:46 <mizmo> right now the number of options here is limited
14:50:18 <mizmo> i will say... let's add this test account to the group
14:50:21 <mizmo> this is a group that has admin access
14:50:33 <mizmo> the next time i log in to jenkins,
14:50:56 <mizmo> <i wonder is there a way to focus camera? it loioks out of focus, not just from network slowness>
14:51:07 <mizmo> in tht ejenkins group, now i have access to more permissions on jenkins
14:51:15 <mizmo> so that's where we use this extension
14:51:33 <mizmo> another piece of info we require is whether or not the user signed the CLA
14:51:44 <mizmo> need to know if user signed the CLA and is allowed to do certain things
14:52:03 <mizmo> so we wrote this extension
14:52:06 <mizmo> defined by fedora team
14:52:15 <mizmo> q: why is it not using the group extension?
14:52:34 <mizmo> a: we wanted to separate it - we have groups for cla stuff but there's no way to get additional information about a group, if its a cla group or not
14:52:50 <mizmo> q: but if you can request if a person is in a certain group why not request if in cla group?
14:53:01 <mizmo> a: dont want to provide cla information, don't know if cla group or not
14:53:13 <mizmo> a: we can't send the type of the group, have to guess on the group name, but might not always be true
14:53:31 <mizmo> a: we want to know if member of signed cla group (there are many cla groups)
14:53:48 <mizmo> now i'm going to tell you about our current state
14:54:05 <mizmo> account system servers
14:54:22 <mizmo> requires us to keep the api into the account system, always have the application ask for a password which it then sends off to the acct system
14:54:32 <mizmo> only openid should ask for password
14:54:38 <mizmo> then easier to add things like an otp system
14:54:48 <mizmo> current openid provider was rewritten from scratch
14:54:56 <mizmo> old one had issues, was rewritten from scratch
14:55:00 <mizmo> rewrote 6 months ago
14:55:14 <mizmo> running without any major problems so far
14:55:20 <mizmo> ive been using it a lot so i know it's pretty much stable now
14:55:28 <mizmo> now we have that we're starting to convert services over
14:55:30 <mizmo> so far we have
14:55:36 <mizmo> fedorahosted, COPR, tagger, hyperkitty, and jenkins
14:55:49 <mizmo> (hyperkitty is still in development)
14:55:56 <mizmo> currently in process of migrating bodhi, pkgdb, elections, etc.
14:55:58 <mizmo> summary
14:56:15 <mizmo> we're trying to centralize our authentication so apps don't need to ask passwords in orer to get info they need to operate
14:56:32 <mizmo> if website supports extension, they can request the info and user can say what info they want to submit
14:56:38 <mizmo> questions?
14:57:08 <nb> #info if you have questions, contact patrick@fedoraproject.org
14:57:10 <mizmo> q: extension... communication between the provider and the application, it's only after user logs in?
14:57:21 <mizmo> a: yes stateful operation - they exchange a key before, redirects user to auth
14:57:32 <mizmo> a: with stateless mode that key exchange is done afterwards so consumer does not need to store it
14:57:38 <mizmo> any other questions?
14:57:43 <mizmo> none from irc so far
14:57:51 <mizmo> thank you for your attention, and enjoy the rest of flock!
14:57:52 <mizmo> <applause>
14:57:55 <mizmo> #endmeeting