18:00:04 #startmeeting fas-openid-class (2013-02-22) 18:00:04 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:06 #meetingname fas-openid-class 18:00:06 The meeting name has been set to 'fas-openid-class' 18:00:15 #topic Introduction 18:00:31 Hello, I wonder who is around right now? 18:00:38 (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 okay, let's just try it 18:02:15 so, for the people who don't know: FAS-OpenID is the new OpenID provider for the Fedora Account system 18:02:37 if you have any questions, please do not hesitate to ask them 18:03:27 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 #topic OpenID flow 18:04:10 okay, so a quick recap on the way OpenID works. let's start with the terminology: 18:04:26 there is an user, which would login to a website 18:05:21 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 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 the user browses to the jenkins website, and clicks the login button 18:07:26 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 but in both cases, the relying party gets the URL of an OpenID provider 18:08:46 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 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 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 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 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 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 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 ah. ok, thats where that url is found. interesting. thanks. 18:13:13 to continue: the OpenID provider sends the url with the authentication details as another HTTP redirect to the user 18:13:28 then the user's browser makes this request to the relying party 18:14:17 this url is something like /completeAuthentication?openid.mode=authenticated&openid.identity=puiterwijk.id.fedoraproject.org&openid.signature=..... 18:14:39 it contains a lot more values, but I will come to that later 18:15:21 at this moment, the relying party has a lot of information on the user 18:15:42 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 as you acn see in my example, it also contains an openid.signature= 18:16:24 this signature is calculated with the key the relying party and provider exchange in the start of the protocol 18:16:59 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 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 if either of those checks fail, it will just abort the protocol 18:18:15 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 at this moment, the openid protocol has ended, and the user is authenticated 18:18:59 are there any questions on this part? 18:19:07 how much of this exchange is over https vs http? or could it be different depending on sites? 18:20:23 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 although there are a few OpenID providers that also use https for this, most don't 18:21:14 (the relying party has to use what the provider asks it to do) 18:21:50 is everything relying on GET? (since GET actually has a size limit) 18:22:22 pingou: that depends, by default it uses GET, but it can use POST 18:22:38 and it will do so if it is exceeding those limits 18:22:58 automatically or does it has to be specified? 18:23:15 that depends on the library that the provider and/or relying party uses 18:23:29 in our case? 18:23:34 python-openid, the one used for FAS-OpenID and a lot more, does it automatically 18:23:44 How is the key exchange between the RP and the Provider secured when that transmission uses http? 18:24:12 abadger1999: the assumption is that a Man In The Middle is practically impossible for a datacenter 18:24:36 yeah, since the user and RP won't be on the same net or with the ability to sniff. 18:24:56 indeed 18:24:59 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 nirik: FAS-OpenID does use that, if it has a valid certificate ;) 18:26:06 (something where the openid provider and hte relying party communicate over the open internet) 18:26:51 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 abadger1999: as I mentioned, the relying party relies on the provider to perform the necessary authentication and to be secure 18:28:27 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 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 right 18:29:20 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 #topic OpenID information and extensions 18:30:20 (if anyone has questions regarding the previous section, just ask or keep them for the end, whatever you prefer) 18:31:04 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 the OpenID identity has to be an URL controlled by the provider, but it is user-specific 18:32:06 most providers do something like . or / 18:32:11 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 nirik: it already is fixed to not do that ;) 18:32:57 good. that always annoyed me about our current one 18:33:11 FAS-OpenID only authorizes users to use .id.stg.fedoraproject.org for the staging one, and .id.fedoraproject.org 18:33:31 those URL's are configurable, but these are the ones I currently have (it's very easy to change though) 18:34:10 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 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 that is the reason there are some extensions 18:35:55 some are by the same people who created OpenID, but there are also some external ones 18:37:12 the provider will publish a list of all extensions it supports 18:37:39 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 one example of such an extension is the Simple Registration extension 18:38:13 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 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 if the provider get's asked to add an extension it does not support, it is supposed to just ignore it 18:39:57 ok 18:39:58 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 jamielinux: the logs will get published, so you can read them afterwards ;) 18:40:45 puiterwijk: Indeed I will :) 18:41:06 (Or just scroll up in weechat.) 18:41:20 but this means that the extension requests and responses are piggybacked on the original openid request and response 18:41:39 an example would be visible in the example URL I just sent 18:42:02 recall I had the URL: /completeAuthentication?openid.mode=authenticated&openid.identity=puiterwijk.id.fedoraproject.org&openid.signature=..... 18:43:11 if this response would also contain simple registration extension (which I will explain i na minute), the following gets appended: &openid.ns.sreg=&openid.sreg.nickname=puiterwijk&openid.sreg.fullname=Patrick%20Uiterwijk, etc 18:43:13 (the openid.identity doesn't start with a http://?) 18:43:30 pingou: it does 18:43:34 k 18:43:44 http://RPsite/ right? 18:43:56 nirik: no 18:44:10 for me, the complete openid.identity would be: http://puiterwijk.id.fedoraproject.org/ 18:44:42 a subdomain of the provider 18:44:43 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 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 pingou: it can be, but as long as the provider controls the URL it's fine 18:45:12 nirik: yeah, agreed 18:45:14 oki 18:45:41 nirik: sorry, I meant this as an example of the parameters it sends 18:45:58 right. carry on. 18:46:14 okay, are there any other questions regarding the extension system itself and the piggybacking? 18:46:40 #topic Extensions: Simple Registration 18:47:05 since all is in GET 18:47:23 Okay, the Simple Registration extension, or "sreg" as the openid namespace is, is one of the simplest extensions 18:47:27 pingou: what do you mean? 18:47:44 it all get logged into the access log, right? 18:48:01 pingou: yes, it would 18:48:13 I was just wondering if that could give problem if a machin get corrupted 18:48:38 machine* 18:48:49 pingou: you mean the logging machine? 18:49:06 puiterwijk: yes 18:49:39 pingou: well, the attacker would find out the user's OpenID identity, and maybe the values provided by extensions etc, yes 18:50:18 so for us, things which are already available via zodbot 18:50:18 pingou: that's why I force FAS-OpenID to use POST if the relying party supports it 18:50:25 nothing else? 18:50:40 pingou: yep. the username, fullname, email, timezone and group information 18:51:00 still available via zodbot :) 18:51:06 indeed 18:51:31 pingou: any more questions right now? 18:51:40 nope 18:51:43 okay 18:51:52 so, I was talking on the Simple Registration extension 18:52:06 this extension is meant to provide user information to the relying party 18:52:36 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 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 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 are there any questions on it? 18:54:53 (sreg) 18:54:55 query: does this obey fas's privacy flag? 18:55:33 nirik: no 18:55:43 nirik: note -- this is theoretically the user logging in 18:55:54 so they should have access to all that information anyway. 18:55:58 but FAS-OpenID does show which information it will send back to the relying party in case the user accepts it 18:55:59 ah... ok. 18:56:27 can the user decide only to send some info? 18:56:28 puiterwijk: can the user choose which info is returned and which isnt? 18:56:29 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 pingou: jinx. ;) 18:56:37 nirik: gmta :) 18:56:46 heh all three of us :-) 18:56:50 nirik, pingou, abadger1999: that depends 18:57:03 with sreg, the relying party can send two lists of fields it is interested in: 18:57:11 a requested list, and a required list 18:57:41 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 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 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 does this answer those three questions? 18:59:08 * nirik nods. 18:59:09 yes 18:59:21 abadger1999: ? 18:59:41 18:59:44 okay 18:59:54 that was the easiest extension 19:00:05 #topic Attribute Exchange extension 19:00:10 #undo 19:00:10 Removing item from minutes: 19:00:20 #topic Extensions: Attribute Exchange 19:00:55 okay, the Attribute Exchange (namespace ax) extension is primarily an extended simple registration extension 19:01:33 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 where sreg has a list of predefined accepted fields, ax requests contain uri's that indicate the pieces of information requested 19:02:23 would one normally run both this and simple? or attibute exchange replaces simple and extends it? 19:02:54 well, AX is normally used for provider-specific purposes 19:03:18 for example: google uses it to pass authentication tokens to be used with Oauth after the protocol (hybrid OpenID/Oauth) 19:03:38 are they compatible? 19:03:57 pingou: yes, all extensions can be used at the same time, as they have different namespaces 19:04:26 as I showed in my example url, all piggybacked information is in a namespace: &openid.sreg.fullname=Patrick%20Uiterwijk 19:04:28 but if the provider has ax and the RP asks for sa, will it work? 19:04:36 s/sa/sreg/ 19:05:15 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 ok, thanks 19:05:52 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 for example: there is not URI specified to be used if the RP wants the fullname 19:06:36 and both the Relying Party and the Provider have to recognize it 19:07:10 that's why AX is primarily used for provider-specific details that don't warrant an extension of it's own 19:07:34 are there any other AX questions? 19:08:14 brl. 19:08:18 nope 19:08:32 current FAS-OpenID implementation status: not. FAS-OpenID does not have ax 19:08:55 #topic Extensions: Teams 19:09:00 will it? 19:09:20 pingou: well, I have no fields we can use for AX, but if I would have any, it will 19:10:01 Okay, the teams (or in our terms "groups") extension, is an extension that originates from Launchpad 19:10:34 This is also the reason it is called "teams extension" rather than "groups extension", because launchpad only has "teams" 19:11:10 this extension gives the RP the option to ask if the user is a member of a list of groups 19:11:43 so the relying party will add a list of teams, like &openid.teams.query_membership=sysadmin,packager,... 19:12:17 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 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 current FAS-OpenID implementation status: it provides this teams extension, with one internal extension 19:13:58 this internal extension means that there is a "magic" group name, which it will interpret as "*" 19:14:24 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 Cool 19:14:39 +1 19:14:56 any questions on this? 19:15:28 #topic Extensions: Provider Authentication Policy Extension 19:15:53 Okay, the Provider Authentication Policy Extension, with namespace pape, is an extension aimed for security 19:16:59 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 I will explain them in two parts, as the last two are tightly linked together 19:17:58 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 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 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 almost always, there is some specific timeout, after which the provider requires re-authentication 19:22:00 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 for example: in FAS-OpenID, there is a timeout of one hour, after the user must re-authenticate 19:23:09 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 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 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 are there any questions on this? 19:24:50 nope 19:25:04 looks nice 19:25:13 okay, then there is the other part of pape: the authentication policies and authentication levels 19:25:31 those are pretty tightly linked together, so I will mention them at the same time 19:25:54 sometimes, knowing that the authentication happened in the last X minutes isn't enough for the relying party 19:26:35 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 both the authentication policies and the authentication levels provide this information 19:28:27 the authentication policy can be one or more of the several: 19:28:45 "none", which means nothing special has been used to authenticate the user 19:29:15 "multi-factor", which means that a token with a One Time Password was used 19:29:38 "physical multi-factor", which means that a PHYSICAL token with a One Time Password was used 19:30:08 or "phishing-resistant", which means that a client certificate was used for authentication 19:30:36 as you can understand, combinations of those, except for none, are possible 19:31:04 the other way the provider can use to communicate the level of authentication done is an Authentication Level 19:31:43 can the client specify what he wants? 19:31:51 the authentication level system provides about the same information, but the authentication levels are specified by the NIST 19:32:23 pingou: yes, the relying party can specify that it requires a physical multi-factor authentication for example 19:32:40 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 puiterwijk: I'm thinking before the relying party 19:33:09 pingou: ah, the client is not able the require anything no 19:33:10 I wouldn't make that distinction. 19:33:18 ok 19:33:24 If we did, it would be something that the relying party would do though. 19:33:30 the relying party is the only one who can require a specific minimum authentication policy 19:34:05 abadger1999: we've started this discussion, I was hoping this might be a new approach :) 19:34:10 pingou: but for CLI, I have another idea, but I will work that out soon, and let you know about it ;) 19:34:14 19:34:19 puiterwijk: cool 19:35:25 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 are there any more PAPE-related questions? 19:36:04 * pingou has none 19:36:07 #topic Extensions: CLA 19:36:17 oh, wait 19:36:19 #undo 19:36:19 Removing item from minutes: 19:36:35 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 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 nirik: the provider publishes a list of all extensions it supports 19:38:00 puiterwijk: PAPE levels: 19:38:14 abadger1999: you mean which levels NIST has specified? 19:38:24 puiterwijk: Are we going to call yubikey physical multi-factor and googleauth multi-factor ? 19:38:34 puiterwijk: I don't suppose there's a survey or list of what major providers do anywhere is there? ;) 19:38:36 or are we going to call both of the m physical multi-factor? 19:38:38 puiterwijk: is there a page for human as well 19:38:54 abadger1999: yes, but "physical multi-factor" implicates "multi-factor" as well. but indeed: googleauth is just multi-factor 19:39:00 nirik: nope, not yet 19:39:05 Thanks. 19:39:08 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 pingou: although I could come up with one for FAS-OpenID, but the is no specification for such a page 19:40:06 nirik: physical is specified to be a device that is only used for the purpose of generating OTP's 19:40:23 puiterwijk: for people using it to know which info can be returned 19:40:44 pingou: you see all the information it returns when you use it. or is that not what you mean? 19:41:26 puiterwijk: I was thinking more something like: id.fp.o/extensions -> this RP supports the extensions X, Y and Z 19:41:34 Something that's easily read by a human -- like: This server supports the PAPE extension , teams extension , etc 19:41:35 pingou: sure, I could create such a page 19:41:46 puiterwijk: which can be linked to your specifications and also advertized a little bit your work 19:41:50 but there is no specification on that 19:41:58 abadger1999: gmta, again :) 19:42:01 pingou: sure, I will add that :) 19:42:13 :-) 19:42:14 abadger1999: oh and jnix 19:42:18 okay, any other PAPE questions? 19:42:22 jinx* 19:42:42 okay, let's try CLA again 19:42:49 #topic Extensions: CLA 19:43:11 The CLA extension is my first extension, and it is also very simple 19:43:47 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 at the end of the protocol, the provider returns a list with CLA URI's which the user has indeed signed 19:44:57 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 so this was primarily meant to support cla_plus_one requirements or CLA requirements for our applications 19:46:26 does anyone have questions on this plugin? 19:46:47 * nirik has none 19:46:48 current FAS-OpenID implementation status: fully implemented 19:47:05 surprise, surprise! :) 19:47:50 okay, that was the last extension 19:47:53 #topic Questions 19:48:14 how easy is it in Flask-fas-openid to change the login mechanism? 19:48:15 Are there any questions regarding this explenation of OpenID, the extensions, or anything else OpenID? 19:48:24 pingou: what do you mean? 19:48:27 (as in to require OTP or not, to requires CLA+1 or not) 19:48:55 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 puiterwijk: to add on - how hard is it to make the auth selectable per-user? 19:49:22 pingou: to require OTP, we would need to modify it a bit to add the PAPE extension 19:49:25 so I could say I would like 2fa login required 19:49:42 but some other user wouldn't need it 19:49:59 puiterwijk: we'd need to have this in a way that sometime it's on, sometime it's not 19:50:00 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 ok 19:50:28 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 puiterwijk: but can these config element be changed while running ? 19:51:24 pingou: yes, app config can be changed while running, but I can't see what you are aiming for? 19:51:53 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 puiterwijk: basically, enforcing OTP on website and deactivating it for CLI 19:52:16 (or at least enforcing OTP on website when possible) 19:52:24 pingou: ah. I could also make a decorator like @otp_required, or something like that 19:52:51 so then you can have specific functions that do require OTP (web) and some that don't (CLI) 19:53:12 puiterwijk: or just according to the coming request require the OTP or not 19:53:39 it wouldn't be too hard to add those things 19:53:48 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 and my suggestion would fix this all, but as I said: I'm working on that ;) 19:54:22 I kinda of agree, but I don't quite see how to make a stateless api otherwise 19:54:36 puiterwijk: care to share? 19:54:54 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 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 abadger1999: it uses the default flask session system to store the authentication status 19:56:12 puiterwijk: an API key then, similar to what we do in copr? 19:56:37 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 pingou: so why not the session cookie? 19:57:00 abadger1999: it is a sort of session cookie, but a token could be limited to what it is allowed to do 19:57:03 abadger1999: not stateless 19:57:11 I think an api key would defeat the purpose of the pape extension? 19:57:29 abadger1999: yes, so that's why we could put limits on its use 19:57:39 pingou: I'll bite then... why is stateless important in this case? 19:58:17 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 pingou: you should still be able to -- curl can use a cookie jar. 19:58:59 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 abadger1999: I guess we should work on a dummy :) 19:59:43 pingou: yeah, then we'll see what the issues might be. 20:00:13 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 btw, flask-fas was contacting FAS for every requests 20:00:36 do we want this in flask-as-openid? 20:00:39 pingou: yes, but flask-fas-openid doesn't do that 20:00:45 pingou: not if we can help it. 20:01:07 pingou, abadger1999: it doesn't. as I said: it stores your informaton in the flask session 20:01:07 flask_fas was using the tg1 visit/identity framework. 20:01:08 puiterwijk: so I see, the question was more: is it desirable :) 20:01:43 that required us to hit fas periodically to remain connected/not hit the idle timeout. 20:01:51 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 pingou: that is true. 20:02:22 I have no clear opinion on this, I'm just asking what we want :) 20:02:28 pingou: the session also contains the last authentication time. the application could use this information 20:02:52 puiterwijk: that's something we could put in the flask-fas-openid itself 20:02:53 (part of the PAPE auth timeout is that it provides the date/time of the last authentication) 20:03:05 pingou: flask-fas-openid does have that information 20:03:13 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 puiterwijk: I mean the checking how long it's been since the last auth 20:03:36 pingou: it could, it just doesn't yet 20:03:47 puiterwijk: so I see 20:03:47 abadger1999: 20:04:42 are there any other questions you have right now? 20:05:15 #info For more information, just contact puiterwijk on freenode 20:06:05 okay, then I wonder now: who stayed until the end, so who is still reading? 20:06:17 (just curious) 20:06:21 #endmeeting