18:00:04 <puiterwijk> #startmeeting fas-openid-class (2013-02-22)
18:00:04 <zodbot> Meeting started Fri Feb 22 18:00:04 2013 UTC.  The chair is puiterwijk. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:06 <puiterwijk> #meetingname fas-openid-class
18:00:06 <zodbot> The meeting name has been set to 'fas-openid-class'
18:00:15 <puiterwijk> #topic Introduction
18:00:31 <puiterwijk> Hello, I wonder who is around right now?
18:00:38 <puiterwijk> (for the fas-openid talk)
18:00:46 * pingou 
18:01:01 * jamielinux 
18:01:07 * nirik is here.
18:01:09 * satellit_e listening
18:01:39 * abadger1999 here
18:01:48 <puiterwijk> okay, let's just try it
18:02:15 <puiterwijk> so, for the people who don't know: FAS-OpenID is the new OpenID provider for the Fedora Account system
18:02:37 <puiterwijk> if you have any questions, please do not hesitate to ask them
18:03:27 <puiterwijk> today I was planning on telling a bit about the general OpenID flow, the extensions system, and the extensions we have for FAS-OpenID
18:03:38 <puiterwijk> #topic OpenID flow
18:04:10 <puiterwijk> okay, so a quick recap on the way OpenID works. let's start with the terminology:
18:04:26 <puiterwijk> there is an user, which would login to a website
18:05:21 <puiterwijk> if this website accepts login with OpenID, this website is during the OpenID session called the Relying Party, because he relies on the OpenID Provider, the website that "hosts" the OpenID identity to authenticate the user
18:06:18 <puiterwijk> let us, for the sake of example, assume that jenkins is the relying party, or RP for short, and that FAS-OpenID is the provider
18:06:42 <puiterwijk> the user browses to the jenkins website, and clicks the login button
18:07:26 <puiterwijk> at this moment, it depends on what the relying party is configured to do: either it asks the user for the url of his OpenID provider or it uses the one it is configured to use automatically
18:08:04 <puiterwijk> but in both cases, the relying party gets the URL of an OpenID provider
18:08:46 <puiterwijk> at this moment, the relying party connects to the OpenID provider directly, to execute a key exchange protocol, for the rest of the OpenID protocol
18:09:17 <puiterwijk> at this same instance, the provider also sends an url to the relying party where the user should be redirected for authentication
18:09:54 <puiterwijk> then the relying party sends this url as a HTTP 302 redirect to the user's web browser, which then connects to the OpenID provider's website
18:10:32 <puiterwijk> here, the user authenticates with username/password, and maybe some other factors, to the provider, to prove he is authorized to use it as an OpenID identity provider
18:11:32 <puiterwijk> after the server is sure (enough) that the user is authorized, it generates a new return URL to forward the user to, based on the URL of the website the user wanted to log in to, but with all of the authentication details that website should know
18:11:57 <nirik> question: what sort of information is exchanged via the RP -> openid provider link? just that they are sending a user to authenticate? since the auth details are not sent there?
18:12:37 <puiterwijk> nirik: at this moment, there is just a key exchange (random bits) and the url to which the RP should redirect the user to complete authentication
18:12:58 <nirik> ah. ok, thats where that url is found. interesting. thanks.
18:13:13 <puiterwijk> to continue: the OpenID provider sends the url with the authentication details as another HTTP redirect to the user
18:13:28 <puiterwijk> then the user's browser makes this request to the relying party
18:14:17 <puiterwijk> this url is something like /completeAuthentication?openid.mode=authenticated&openid.identity=puiterwijk.id.fedoraproject.org&openid.signature=.....
18:14:39 <puiterwijk> it contains a lot more values, but I will come to that later
18:15:21 <puiterwijk> at this moment, the relying party has a lot of information on the user
18:15:42 <puiterwijk> but it can not be sure that this is provided by the openid provider, or by the user just entering his details in the get url
18:16:04 <puiterwijk> as you acn see in my example, it also contains an openid.signature=
18:16:24 <puiterwijk> this signature is calculated with the key the relying party and provider exchange in the start of the protocol
18:16:59 <puiterwijk> so apart from the relying party and provider, nobody is expected to have access, especially the user is not able to see this key
18:17:31 <puiterwijk> so the RP checks if the signature indeed signs the data that is returned in the URL, and if it is signed by the exchanged key
18:17:46 <puiterwijk> if either of those checks fail, it will just abort the protocol
18:18:15 <puiterwijk> if this succeeeds, the user has succesfully authenticated, and the relying party relies on the openid provider to have communicated the valid details
18:18:42 <puiterwijk> at this moment, the openid protocol has ended, and the user is authenticated
18:18:59 <puiterwijk> are there any questions on this part?
18:19:07 <nirik> how much of this exchange is over https vs http? or could it be different depending on sites?
18:20:23 <puiterwijk> nirik: that depends on the provider and relying party, but most often the communication between the user and relying party/provider is done with HTTPS, but the communication between the RP and provider is on HTTP
18:21:02 <puiterwijk> although there are a few OpenID providers that also use https for this, most don't
18:21:14 <puiterwijk> (the relying party has to use what the provider asks it to do)
18:21:50 <pingou> is everything relying on GET? (since GET actually has a size limit)
18:22:22 <puiterwijk> pingou: that depends, by default it uses GET, but it can use POST
18:22:38 <puiterwijk> and it will do so if it is exceeding those limits
18:22:58 <pingou> automatically or does it has to be specified?
18:23:15 <puiterwijk> that depends on the library that the provider and/or relying party uses
18:23:29 <pingou> in our case?
18:23:34 <puiterwijk> python-openid, the one used for FAS-OpenID and a lot more, does it automatically
18:23:44 <abadger1999> How is the key exchange between the RP and the Provider secured when that transmission uses http?
18:24:12 <puiterwijk> abadger1999: the assumption is that a Man In The Middle is practically impossible for a datacenter
18:24:36 <nirik> yeah, since the user and RP won't be on the same net or with the ability to sniff.
18:24:56 <puiterwijk> indeed
18:24:59 <abadger1999> puiterwijk: ah. So that's imagining that it's an intra-organization openid server, not something like launchpad or fas-openid?
18:25:34 * nirik favors using https everywhere if we can.
18:25:57 <puiterwijk> nirik: FAS-OpenID does use that, if it has a valid certificate ;)
18:26:06 <abadger1999> (something where the openid provider and hte relying party communicate over the open internet)
18:26:51 <puiterwijk> abadger1999: for both inter- and intra-organization, the assumption is that if the user is able to spoof those connections, he can just use his own openid provider to authenticate
18:27:26 <puiterwijk> abadger1999: as I mentioned, the relying party relies on the provider to perform the necessary authentication and to be secure
18:28:27 <puiterwijk> nirik: the only reason I have that disabled for FAS-OpenID currently is because our certificates don't match id.stg.fedoraproject.org
18:28:52 <nirik> another question (that may be just later): what information can the provider send back to the RP? anything they want, but the RP might not care?
18:28:55 <nirik> right
18:29:20 <puiterwijk> nirik: that is something for the next part, but I can already start on that if there are no more questions?
18:29:41 * nirik has no more on the flow.
18:29:56 <puiterwijk> #topic OpenID information and extensions
18:30:20 <puiterwijk> (if anyone has questions regarding the previous section, just ask or keep them for the end, whatever you prefer)
18:31:04 <puiterwijk> so, by default the OpenID provider provides the relying party with very few details on the user. By default, it will only provide an OpenID identity, which is just a URL
18:31:45 <puiterwijk> the OpenID identity has to be an URL controlled by the provider, but it is user-specific
18:32:06 <puiterwijk> most providers do something like <username>.<provider> or <provider>/<username>
18:32:11 <nirik> as a side note, I think our current provider lets you use multiple different urls, so they appear as different users to RP's... we should try and make the new one not do that. :)
18:32:29 <puiterwijk> nirik: it already is fixed to not do that ;)
18:32:57 <nirik> good. that always annoyed me about our current one
18:33:11 <puiterwijk> FAS-OpenID only authorizes users to use <username>.id.stg.fedoraproject.org for the staging one, and <username>.id.fedoraproject.org
18:33:31 <puiterwijk> those URL's are configurable, but these are the ones I currently have (it's very easy to change though)
18:34:10 <puiterwijk> some providers use a more privacy-friendly OpenID url, like Google (it uses something like a hash, I am not entirely sure on that, but it looks like that)
18:34:52 <puiterwijk> but as you can understand, by default OpenID provider very few details on the user it authenticated, but the relying party would like to know more details on the user
18:35:26 <puiterwijk> that is the reason there are some extensions
18:35:55 <puiterwijk> some are by the same people who created OpenID, but there are also some external ones
18:37:12 <puiterwijk> the provider will publish a list of all extensions it supports
18:37:39 <puiterwijk> and the relying party can add those it is interested in to the request, and then the provider can do something with the,m
18:38:12 <puiterwijk> one example of such an extension is the Simple Registration extension
18:38:13 <nirik> it adds them after it's gotten a list from the provider? or just adds them and hopes the provider can do something?
18:38:38 <puiterwijk> nirik: it should check the list, but it doesn't have to. It can also just send it, and hope the provider supports it
18:39:01 <puiterwijk> if the provider get's asked to add an extension it does not support, it is supposed to just ignore it
18:39:57 <nirik> ok
18:39:58 <puiterwijk> but the other way around is also valid: the provider can just append any extensions he knows to the response, and the relying party should ignore it if it doesn't support them
18:40:19 * jamielinux has to go, but thanks for the (half) lesson!
18:40:26 * nirik nods to the use of Postel's Law‎.
18:40:38 <puiterwijk> jamielinux: the logs will get published, so you can read them afterwards ;)
18:40:45 <jamielinux> puiterwijk: Indeed I will :)
18:41:06 <jamielinux> (Or just scroll up in weechat.)
18:41:20 <puiterwijk> but this means that the extension requests and responses are piggybacked on the original openid request and response
18:41:39 <puiterwijk> an example would be visible in the example URL I just sent
18:42:02 <puiterwijk> recall I had the URL: /completeAuthentication?openid.mode=authenticated&openid.identity=puiterwijk.id.fedoraproject.org&openid.signature=.....
18:43:11 <puiterwijk> if this response would also contain simple registration extension (which I will explain i na minute), the following gets appended: &openid.ns.sreg=<url to sreg specification>&openid.sreg.nickname=puiterwijk&openid.sreg.fullname=Patrick%20Uiterwijk, etc
18:43:13 <pingou> (the openid.identity doesn't start with a http://?)
18:43:30 <puiterwijk> pingou: it does
18:43:34 <pingou> k
18:43:44 <nirik> http://RPsite/ right?
18:43:56 <puiterwijk> nirik: no
18:44:10 <puiterwijk> for me, the complete openid.identity would be: http://puiterwijk.id.fedoraproject.org/
18:44:42 <pingou> a subdomain of the provider
18:44:43 <nirik> well, I meant the response there... that should be what the provider sends to the user browser as a redirect and is a request to the RP site, right?
18:44:44 <puiterwijk> as mentioned, the provider will need to control that URL, and thus can validate requests to that URL to be indeed from the valid user
18:45:01 <puiterwijk> pingou: it can be, but as long as the provider controls the URL it's fine
18:45:12 <puiterwijk> nirik: yeah, agreed
18:45:14 <pingou> oki
18:45:41 <puiterwijk> nirik: sorry, I meant this as an example of the parameters it sends
18:45:58 <nirik> right. carry on.
18:46:14 <puiterwijk> okay, are there any other questions regarding the extension system itself and the piggybacking?
18:46:40 <puiterwijk> #topic Extensions: Simple Registration
18:47:05 <pingou> since all is in GET
18:47:23 <puiterwijk> Okay, the Simple Registration extension, or "sreg" as the openid namespace is, is one of the simplest extensions
18:47:27 <puiterwijk> pingou: what do you mean?
18:47:44 <pingou> it all get logged into the access log, right?
18:48:01 <puiterwijk> pingou: yes, it would
18:48:13 <pingou> I was just wondering if that could give problem if a machin get corrupted
18:48:38 <pingou> machine*
18:48:49 <puiterwijk> pingou: you mean the logging machine?
18:49:06 <pingou> puiterwijk: yes
18:49:39 <puiterwijk> pingou: well, the attacker would find out the user's OpenID identity, and maybe the values provided by extensions etc, yes
18:50:18 <pingou> so for us, things which are already available via zodbot
18:50:18 <puiterwijk> pingou: that's why I force FAS-OpenID to use POST if the relying party supports it
18:50:25 <pingou> nothing else?
18:50:40 <puiterwijk> pingou: yep. the username, fullname, email, timezone and group information
18:51:00 <pingou> still available via zodbot :)
18:51:06 <puiterwijk> indeed
18:51:31 <puiterwijk> pingou: any more questions right now?
18:51:40 <pingou> nope
18:51:43 <puiterwijk> okay
18:51:52 <puiterwijk> so, I was talking on the Simple Registration extension
18:52:06 <puiterwijk> this extension is meant to provide user information to the relying party
18:52:36 <puiterwijk> it is the primary extension that is used to provide the full name, email address, time zone, country, etc to the relying party
18:53:15 <puiterwijk> the relying party will send a list of fields it is interested in, and the provider will send the values of those fields back
18:54:14 <puiterwijk> implementation status in FAS-OpenID: it is completely implemented, but we only support fullname, nickname, email and time zone, as those are the only pieces of information we have on the user that sreg can provide
18:54:49 <puiterwijk> are there any questions on it?
18:54:53 <puiterwijk> (sreg)
18:54:55 <nirik> query: does this obey fas's privacy flag?
18:55:33 <puiterwijk> nirik: no
18:55:43 <abadger1999> nirik: note -- this is theoretically the user logging in
18:55:54 <abadger1999> so they should have access to all that information anyway.
18:55:58 <puiterwijk> but FAS-OpenID does show which information it will send back to the relying party in case the user accepts it
18:55:59 <nirik> ah... ok.
18:56:27 <nirik> can the user decide only to send some info?
18:56:28 <pingou> puiterwijk: can the user choose which info is returned and which isnt?
18:56:29 <abadger1999> I suppose they might want to be able to opt-out of sending individual pieces of the data but I don't know if that's a pain to do/common/etc.
18:56:36 <nirik> pingou: jinx. ;)
18:56:37 <pingou> nirik: gmta :)
18:56:46 <abadger1999> heh  all three of us :-)
18:56:50 <puiterwijk> nirik, pingou, abadger1999: that depends
18:57:03 <puiterwijk> with sreg, the relying party can send two lists of fields it is interested in:
18:57:11 <puiterwijk> a requested list, and a required list
18:57:41 <puiterwijk> if the provider doesn't return any of the information in the required list, most relying parties will just abort the authentication
18:58:13 <puiterwijk> currently there is no option for users in FAS-OpenID, but this will be added in a later version by checkboxes for the requested fields
18:58:43 <puiterwijk> but users do get the option to either send the information request, or to abort the protocol, before any information is sent
18:59:02 <puiterwijk> does this answer those three questions?
18:59:08 * nirik nods.
18:59:09 <pingou> yes
18:59:21 <puiterwijk> abadger1999: ?
18:59:41 <abadger1999> <nod>
18:59:44 <puiterwijk> okay
18:59:54 <puiterwijk> that was the easiest extension
19:00:05 <puiterwijk> #topic Attribute Exchange extension
19:00:10 <puiterwijk> #undo
19:00:10 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x29cbfc50>
19:00:20 <puiterwijk> #topic Extensions: Attribute Exchange
19:00:55 <puiterwijk> okay, the Attribute Exchange (namespace ax) extension is primarily an extended simple registration extension
19:01:33 <puiterwijk> ax also has a list of requested "fields" and returned pieces of information, but it can provide practially anything that is just a normal string value
19:02:09 <puiterwijk> where sreg has a list of predefined accepted fields, ax requests contain uri's that indicate the pieces of information requested
19:02:23 <nirik> would one normally run both this and simple? or attibute exchange replaces simple and extends it?
19:02:54 <puiterwijk> well, AX is normally used for provider-specific purposes
19:03:18 <puiterwijk> for example: google uses it to pass authentication tokens to be used with Oauth after the protocol (hybrid OpenID/Oauth)
19:03:38 <pingou> are they compatible?
19:03:57 <puiterwijk> pingou: yes, all extensions can be used at the same time, as they have different namespaces
19:04:26 <puiterwijk> as I showed in my example url, all piggybacked information is in a namespace: &openid.sreg.fullname=Patrick%20Uiterwijk
19:04:28 <pingou> but if the provider has ax and the RP asks for sa, will it work?
19:04:36 <pingou> s/sa/sreg/
19:05:15 <puiterwijk> no, then the provider will see that the relying party does not ask for ax and will just ignore it, and the RP will not get any sreg information returned because the provider doesn't support it
19:05:29 <pingou> ok, thanks
19:05:52 <puiterwijk> so while AX could be used for the same purposes as sreg, it normally is not used for this, because ax has too few real fields defined
19:06:20 <puiterwijk> for example: there is not URI specified to be used if the RP wants the fullname
19:06:36 <puiterwijk> and both the Relying Party and the Provider have to recognize it
19:07:10 <puiterwijk> that's why AX is primarily used for provider-specific details that don't warrant an extension of it's own
19:07:34 <puiterwijk> are there any other AX questions?
19:08:14 <pingou> brl.
19:08:18 <pingou> nope
19:08:32 <puiterwijk> current FAS-OpenID implementation status: not. FAS-OpenID does not have ax
19:08:55 <puiterwijk> #topic Extensions: Teams
19:09:00 <pingou> will it?
19:09:20 <puiterwijk> pingou: well, I have no fields we can use for AX, but if I would have any, it will
19:10:01 <puiterwijk> Okay, the teams (or in our terms "groups") extension, is an extension that originates from Launchpad
19:10:34 <puiterwijk> This is also the reason it is called "teams extension" rather than "groups extension", because launchpad only has "teams"
19:11:10 <puiterwijk> this extension gives the RP the option to ask if the user is a member of a list of groups
19:11:43 <puiterwijk> so the relying party will add a list of teams, like &openid.teams.query_membership=sysadmin,packager,...
19:12:17 <puiterwijk> after authenticating, the provider will check of which groups the user is indeed a member of, and will return the intersection of these two sets
19:13:04 <puiterwijk> so it will return a list of groups, and a group is in that list if and only if the user is a member of that group AND the group is in the list requested by the relying party
19:13:39 <puiterwijk> current FAS-OpenID implementation status: it provides this teams extension, with one internal extension
19:13:58 <puiterwijk> this internal extension means that there is a "magic" group name, which it will interpret as "*"
19:14:24 <puiterwijk> so if the relying party asks for this group name, it will get a list back of all of the user's groups
19:14:35 <abadger1999> <nod>  Cool
19:14:39 <pingou> +1
19:14:56 <puiterwijk> any questions on this?
19:15:28 <puiterwijk> #topic Extensions: Provider Authentication Policy Extension
19:15:53 <puiterwijk> Okay, the Provider Authentication Policy Extension, with namespace pape, is an extension aimed for security
19:16:59 <puiterwijk> one can say it consists of two or three seperate parts: an authentication timeout part, an authentication policy, and an authentication level
19:17:17 <puiterwijk> I will explain them in two parts, as the last two are tightly linked together
19:17:58 <puiterwijk> the timeout part means that the relying party can request of the openid provider to make sure that the user has authenticated somewhere in the last X seconds
19:19:57 <puiterwijk> as an OpenID provider will almost always remember the user's sign-in session, there might have been some time between two uses of the provider, which gives the possibility that the user forgot to logout, and later walks away, and that someone else gets the keyboard and mouse and tries to use an application that uses openid
19:20:45 <puiterwijk> as the user has already logged in to the provider, it could immediately say that the user is already authenticated, and immediately return success to the relying party
19:21:16 <puiterwijk> almost always, there is some specific timeout, after which the provider requires re-authentication
19:22:00 <puiterwijk> but if the relying party wants to be sure the user has re-authenticated somewhere in the last few minutes, it can specify a different timeout
19:22:25 <puiterwijk> for example: in FAS-OpenID, there is a timeout of one hour, after the user must re-authenticate
19:23:09 <puiterwijk> but there might be an application which is very security-sensitive, and thus might want the last authentication to the provider to be less than (for example) 5 minutes ago
19:23:36 <puiterwijk> so that if the last time the user authenticated himself to the provider was more then 5 minutes ago, the provider should ask for the password again
19:24:24 <puiterwijk> please note: these timeouts are provider-side timeouts, it doesn't say anything about the timeout of the user's session on the relying parties website
19:24:38 <puiterwijk> are there any questions on this?
19:24:50 <nirik> nope
19:25:04 <pingou> looks nice
19:25:13 <puiterwijk> okay, then there is the other part of pape: the authentication policies and authentication levels
19:25:31 <puiterwijk> those are pretty tightly linked together, so I will mention them at the same time
19:25:54 <puiterwijk> sometimes, knowing that the authentication happened in the last X minutes isn't enough for the relying party
19:26:35 <puiterwijk> the relying party might also want to know on what ways the user authenticated: just a username/password, or did he also use for example a token for second-factor
19:27:37 <puiterwijk> both the authentication policies and the authentication levels provide this information
19:28:27 <puiterwijk> the authentication policy can be one or more of the several:
19:28:45 <puiterwijk> "none", which means nothing special has been used to authenticate the user
19:29:15 <puiterwijk> "multi-factor", which means that a token with a One Time Password was used
19:29:38 <puiterwijk> "physical multi-factor", which means that a PHYSICAL token with a One Time Password was used
19:30:08 <puiterwijk> or "phishing-resistant", which means that a client certificate was used for authentication
19:30:36 <puiterwijk> as you can understand, combinations of those, except for none, are possible
19:31:04 <puiterwijk> the other way the provider can use to communicate the level of authentication done is an Authentication Level
19:31:43 <pingou> can the client specify what he wants?
19:31:51 <puiterwijk> the authentication level system provides about the same information, but the authentication levels are specified by the NIST
19:32:23 <puiterwijk> pingou: yes, the relying party can specify that it requires a physical multi-factor authentication for example
19:32:40 <pingou> I'm thinking for CLI app we might not want to enforce the OTP, and if the website was able to make the distingtion CLI/web-requests and ask for authentication w/ or w/o OTP that might solves some problems
19:32:48 <pingou> puiterwijk: I'm thinking before the relying party
19:33:09 <puiterwijk> pingou: ah, the client is not able the require anything no
19:33:10 <abadger1999> I wouldn't make that distinction.
19:33:18 <pingou> ok
19:33:24 <abadger1999> If we did, it would be something that the relying party would do though.
19:33:30 <puiterwijk> the relying party is the only one who can require a specific minimum authentication policy
19:34:05 <pingou> abadger1999: we've started this discussion, I was hoping this might be a new approach :)
19:34:10 <puiterwijk> pingou: but for CLI, I have another idea, but I will work that out soon, and let you know about it ;)
19:34:14 <abadger1999> <nod>
19:34:19 <pingou> puiterwijk: cool
19:35:25 <puiterwijk> but as said: the authentication levels do approximately the same, but then based on specifications and requirements for the levels as published by the NIST
19:35:41 <puiterwijk> are there any more PAPE-related questions?
19:36:04 * pingou has none
19:36:07 <puiterwijk> #topic Extensions: CLA
19:36:17 <puiterwijk> oh, wait
19:36:19 <puiterwijk> #undo
19:36:19 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x286e7f10>
19:36:35 <nirik> a more general question (perhaps better at the end)... is there a way to tell what extensions some RP or provider supports? or you just have to use it and see?
19:37:31 <puiterwijk> FAS-OpenID implementation status: authentication timeout completely supported, and it is able to provide the policies and levels, but we always return NONE, as we do not yet have yubikey login support in FAS for both username/password and yubikey
19:37:59 <puiterwijk> nirik: the provider publishes a list of all extensions it supports
19:38:00 <abadger1999> puiterwijk: PAPE levels:
19:38:14 <puiterwijk> abadger1999: you mean which levels NIST has specified?
19:38:24 <abadger1999> puiterwijk: Are we going to call yubikey physical multi-factor  and googleauth multi-factor ?
19:38:34 <nirik> puiterwijk: I don't suppose there's a survey or list of what major providers do anywhere is there? ;)
19:38:36 <abadger1999> or are we going to call both of the m physical multi-factor?
19:38:38 <pingou> puiterwijk: is there a page for human as well
19:38:54 <puiterwijk> abadger1999: yes, but "physical multi-factor" implicates "multi-factor" as well. but indeed: googleauth is just multi-factor
19:39:00 <puiterwijk> nirik: nope, not yet
19:39:05 <abadger1999> <nod> Thanks.
19:39:08 <puiterwijk> pingou: no, no defined one
19:39:24 * nirik isn't sure I would call google auth not physical. I guess it depends what they mean
19:39:26 <puiterwijk> pingou: although I could come up with one for FAS-OpenID, but the is no specification for such a page
19:40:06 <puiterwijk> nirik: physical is specified to be a device that is only used for the purpose of generating OTP's
19:40:23 <pingou> puiterwijk: for people using it to know which info can be returned
19:40:44 <puiterwijk> pingou: you see all the information it returns when you use it. or is that not what you mean?
19:41:26 <pingou> puiterwijk: I was thinking more something like: id.fp.o/extensions -> this RP supports the extensions X, Y and Z
19:41:34 <abadger1999> Something that's easily read by a human -- like: This server supports the PAPE extension <specification url>, teams extension <url>, etc
19:41:35 <puiterwijk> pingou: sure, I could create such a page
19:41:46 <pingou> puiterwijk: which can be linked to your specifications and also advertized a little bit your work
19:41:50 <puiterwijk> but there is no specification on that
19:41:58 <pingou> abadger1999: gmta, again :)
19:42:01 <puiterwijk> pingou: sure, I will add that  :)
19:42:13 <abadger1999> :-)
19:42:14 <pingou> abadger1999: oh and jnix
19:42:18 <puiterwijk> okay, any other PAPE questions?
19:42:22 <pingou> jinx*
19:42:42 <puiterwijk> okay, let's try CLA again
19:42:49 <puiterwijk> #topic Extensions: CLA
19:43:11 <puiterwijk> The CLA extension is my first extension, and it is also very simple
19:43:47 <puiterwijk> with the CLA extension, the relying party can send a number of URI's indicating CLA's, and ask if the user has signed any (or all) of them
19:44:14 <puiterwijk> at the end of the protocol, the provider returns a list with CLA URI's which the user has indeed signed
19:44:57 <puiterwijk> so we have URL's for cla_redhat, cla_fpca, etc, and will returns if the user has signed any of them
19:45:56 <puiterwijk> so this was primarily meant to support cla_plus_one requirements or CLA requirements for our applications
19:46:26 <puiterwijk> does anyone have questions on this plugin?
19:46:47 * nirik has none
19:46:48 <puiterwijk> current FAS-OpenID implementation status: fully implemented
19:47:05 <puiterwijk> surprise, surprise! :)
19:47:50 <puiterwijk> okay, that was the last extension
19:47:53 <puiterwijk> #topic Questions
19:48:14 <pingou> how easy is it in Flask-fas-openid to change the login mechanism?
19:48:15 <puiterwijk> Are there any questions regarding this explenation of OpenID, the extensions, or anything else OpenID?
19:48:24 <puiterwijk> pingou: what do you mean?
19:48:27 <pingou> (as in to require OTP or not, to requires CLA+1 or not)
19:48:55 <puiterwijk> pingou: it supports the same decorations as flask-fas, so it also has @cla_plus_one_required, and that's all that's required
19:49:13 <skvidal> puiterwijk: to add on - how hard is it to make the auth selectable per-user?
19:49:22 <puiterwijk> pingou: to require OTP, we would need to modify it a bit to add the PAPE extension
19:49:25 <skvidal> so I could say I would like 2fa login required
19:49:42 <skvidal> but some other user wouldn't need it
19:49:59 <pingou> puiterwijk: we'd need to have this in a way that sometime it's on, sometime it's not
19:50:00 <puiterwijk> skvidal: that was what I suggested a little while back. It would not be very hard at all, as I built it so that it can be easily added
19:50:09 <skvidal> ok
19:50:28 <puiterwijk> pingou: that wouldn't be too hard to add. I could just add a new configuration variable like FAS_OPENID_REQUIRE_OTP
19:50:51 <pingou> puiterwijk: but can these config element be changed while running ?
19:51:24 <puiterwijk> pingou: yes, app config can be changed while running, but I can't see what you are aiming for?
19:51:53 <puiterwijk> pingou: I get the idea that you have an intention with it that I'm not seeing, so what would you want to do with it?
19:51:57 <pingou> puiterwijk: basically, enforcing OTP on website and deactivating it for CLI
19:52:16 <pingou> (or at least enforcing OTP on website when possible)
19:52:24 <puiterwijk> pingou: ah. I could also make a decorator like @otp_required, or something like that
19:52:51 <puiterwijk> so then you can have specific functions that do require OTP (web) and some that don't (CLI)
19:53:12 <pingou> puiterwijk: or just according to the coming request require the OTP or not
19:53:39 <puiterwijk> it wouldn't be too hard to add those things
19:53:48 <pingou> CLI would rely on a specific header being added, if this header is present -> no OTP
19:53:50 * abadger1999 doesn't think we'd want to enforce on website and deactivate for cli
19:54:02 * puiterwijk agrees with abadger1999
19:54:16 <puiterwijk> and my suggestion would fix this all, but as I said: I'm working on that ;)
19:54:22 <pingou> I kinda of agree, but I don't quite see how to make a stateless api otherwise
19:54:36 <pingou> puiterwijk: care to share?
19:54:54 <abadger1999> puiterwijk: For the flask_fas_openid provider, does it talk to fas-openid for every request or does it also have a session cookie for the application?
19:55:31 <puiterwijk> pingou: it comes down to another hybrid OpenID & Oauth implementation, so a user could get a token which it can provide to the client to use to act on his behalf
19:55:57 <puiterwijk> abadger1999: it uses the default flask session system to store the authentication status
19:56:12 <pingou> puiterwijk: an API key then, similar to what we do in copr?
19:56:37 <puiterwijk> pingou: yes, a sort of API key (I'm not that familiar with copr yet to say it's the same though)
19:56:37 <abadger1999> pingou: so why not the session cookie?
19:57:00 <puiterwijk> abadger1999: it is a sort of session cookie, but a token could be limited to what it is allowed to do
19:57:03 <pingou> abadger1999: not stateless
19:57:11 <abadger1999> I think an api key would defeat the purpose of the pape extension?
19:57:29 <puiterwijk> abadger1999: yes, so that's why we could put limits on its use
19:57:39 <abadger1999> pingou: I'll bite then... why is stateless important in this case?
19:58:17 <pingou> abadger1999: I guess it's just my way of seeing an API, we should be able to query it with curl in the shell
19:58:33 <abadger1999> pingou: you should still be able to -- curl can use a cookie jar.
19:58:59 <puiterwijk> another advantage of using tokens is that the configuration wouldn't need to contain a password, and we could revoke a token if it ever leaked
19:59:27 <pingou> abadger1999: I guess we should work on a dummy :)
19:59:43 <abadger1999> pingou: yeah, then we'll see what the issues might be.
20:00:13 <puiterwijk> you could also change the password, but that means you would have to change all other applications that use the same user, while you could use a token per application
20:00:25 <pingou> btw, flask-fas was contacting FAS for every requests
20:00:36 <pingou> do we want this in flask-as-openid?
20:00:39 <puiterwijk> pingou: yes, but flask-fas-openid doesn't do that
20:00:45 <abadger1999> pingou: not if we can help it.
20:01:07 <puiterwijk> pingou, abadger1999: it doesn't. as I said: it stores your informaton in the flask session
20:01:07 <abadger1999> flask_fas was using the tg1 visit/identity framework.
20:01:08 <pingou> puiterwijk: so I see, the question was more: is it desirable :)
20:01:43 <abadger1999> that required us to hit fas periodically to remain connected/not hit the idle timeout.
20:01:51 <pingou> abadger1999: but then we rely on the app session management not on the 'you have not logged into fas over the last 15min, bye'
20:01:59 <abadger1999> pingou: that is true.
20:02:22 <pingou> I have no clear opinion on this, I'm just asking what we want :)
20:02:28 <puiterwijk> pingou: the session also contains the last authentication time. the application could use this information
20:02:52 <pingou> puiterwijk: that's something we could put in the flask-fas-openid itself
20:02:53 <puiterwijk> (part of the PAPE auth timeout is that it provides the date/time of the last authentication)
20:03:05 <puiterwijk> pingou: flask-fas-openid does have that information
20:03:13 <abadger1999> we'll have two sesson management pieces now -- the fas-openid server will have some sesion info with a timeout.  the individual applications can/will have a separate piece of session information
20:03:19 <pingou> puiterwijk: I mean the checking how long it's been since the last auth
20:03:36 <puiterwijk> pingou: it could, it just doesn't yet
20:03:47 <pingou> puiterwijk: so I see
20:03:47 <puiterwijk> abadger1999: <nod>
20:04:42 <puiterwijk> are there any other questions you have right now?
20:05:15 <puiterwijk> #info For more information, just contact puiterwijk on freenode
20:06:05 <puiterwijk> okay, then I wonder now: who stayed until the end, so who is still reading?
20:06:17 <puiterwijk> (just curious)
20:06:21 <puiterwijk> #endmeeting