| puiterwijk | so let me summarize: | 11:32 |
|---|---|---|
| puiterwijk | in OAuth, there is defined a protected resource, this is the function you want to call or the data you want to retrieve | 11:33 |
| puiterwijk | you also have the resource server, this is the server hosting the resource | 11:33 |
| puiterwijk | then the client, this is the application that wants to access the resource hosted on the resource server | 11:34 |
| abadger1999 | <nod> | 11:35 |
| puiterwijk | next up we have the resource owner: the user or system that's authorized to give clients access to the resource. for example: the resource owner for the resource "full name of puiterwijk" hosted on resource server FAS would be me | 11:35 |
| puiterwijk | and we have the authorization server (the first role that does not include "resource" :)), which is the server that grants tokens and codes | 11:35 |
| puiterwijk | let me skip a bit to the part which we have been discussing so far: oauth has an "access token", which is based of a client-id and a client-secret which gives access to the resource on the authority of the resource owner by the client | 11:36 |
| puiterwijk | s/by the client/to the client/ | 11:37 |
| abadger1999 | okay -- I think I'll need an example to understand how the resource server, authorization server, and resource owner relate later. | 11:37 |
| puiterwijk | abadger1999: okay, I can give an example | 11:38 |
| puiterwijk | resource: the full name of "puiterwijk" | 11:38 |
| puiterwijk | resource server: FAS | 11:38 |
| puiterwijk | resource owner: puiterwijk | 11:38 |
| puiterwijk | authorization server: FAS-OpenID (by example) | 11:38 |
| abadger1999 | ah okay, I understand | 11:39 |
| abadger1999 | I was thinking resouce owner was another server -- but it's the entity that owns the resource. | 11:39 |
| puiterwijk | yep | 11:39 |
| abadger1999 | got it | 11:39 |
| puiterwijk | can be a server or a user | 11:39 |
| puiterwijk | now it gets complicated :) | 11:40 |
| puiterwijk | so the client needs this "access token", which grants access to the resource | 11:40 |
| puiterwijk | now there are a few described ways of gaining them | 11:41 |
| puiterwijk | the first one is an authorization code: the client redirects the user to the authorization server, which authenticates the user and asks for authorization, and then returns the authorization code | 11:41 |
| puiterwijk | this is NOT usable as access token, it can only be used to request an access token | 11:42 |
| puiterwijk | as such, it can only be used one time | 11:42 |
| puiterwijk | as soon as a token is issued for the authorization code, the authorization code expires, as the client now has an access code | 11:43 |
| abadger1999 | puiterwijk: does the authorization code only work to grant a specific access token? | 11:43 |
| puiterwijk | abadger1999: what do you mean? | 11:43 |
| abadger1999 | Is the code specific to a certain resource? Or could I use it for several different resources? | 11:44 |
| abadger1999 | For instance, only usable to retrieve my full name from the fas server. | 11:45 |
| puiterwijk | no, the authorization code is specific to the authorization given, and is thus limited to what the resource owner agreed to | 11:45 |
| abadger1999 | err... retrieve a token to do that. | 11:45 |
| abadger1999 | okay cool. | 11:45 |
| puiterwijk | the authorization tokens are only meant so that the user can't see the access token | 11:46 |
| abadger1999 | puiterwijk: does the authorization server needs to know about the range of tokens or is what token is requested sent to it on demand by the resource server somehow? | 11:46 |
| puiterwijk | abadger1999: yes | 11:47 |
| puiterwijk | okay, let me start from the beginning of the auth-code protocol, as I skipped some important parts ;) | 11:47 |
| abadger1999 | :-) | 11:47 |
| cluecrowd | this the right place to say "localhost.localdomain" wtf? | 11:47 |
| puiterwijk | please note: this system is primarily used for web applications as client | 11:47 |
| puiterwijk | cluecrowd: that depends on where that is? if it's your own system, I'd go to #fedora | 11:48 |
| puiterwijk | abadger1999: so for example pep8bot with github | 11:48 |
| puiterwijk | abadger1999: so let me use pep8bot as an example | 11:49 |
| puiterwijk | 1. I browse to pep8.me | 11:49 |
| abadger1999 | <nod> | 11:49 |
| puiterwijk | 2. pep8 wants to gget access to my repository list (including private) | 11:49 |
| puiterwijk | so: 3. pep8 registers itself with the authorization server and requests an client-id | 11:50 |
| puiterwijk | during this step, it also provides the server with a list of permissions it would like to have | 11:50 |
| puiterwijk | 4. pep8 gets an url from the authorization server to which it should redirect the user to authorize the app | 11:51 |
| puiterwijk | 5. pep8 redirects the user to that url | 11:51 |
| puiterwijk | 6. the user now arrives at the authorization server, and after logging in can see a list of permissions requested by which app | 11:52 |
| puiterwijk | 7. either the user accepts or rejects this list | 11:52 |
| puiterwijk | 8.a. the user rejects: he gets returned to the app with an error, and here ends the protocol | 11:52 |
| puiterwijk | 8.b. the user accepts: the authorization server generates a new authorization code, and forwards the user back to the app with this authorization code in the request | 11:53 |
| puiterwijk | (from here on, I assume path b was chosen) | 11:53 |
| puiterwijk | 9. the app receives the request from the user with the authorization code, and uses it to request an access token from the authorization server | 11:54 |
| puiterwijk | 10. the authorization server generates a new access token with the same authorizations the user accepted, and returns this to the app | 11:55 |
| puiterwijk | 11. the app stores its access token, and uses this to request the protected resource from the resource server | 11:55 |
| puiterwijk | abadger1999: I hope this clarifies some things? | 11:56 |
| abadger1999 | puiterwijk: 12. the resource server verifies that the access token is valid through some means (could query the authorization server or the authz server could have forwarded the list of valid access tokens to it) ? | 11:57 |
| puiterwijk | abadger1999: correct | 11:57 |
| abadger1999 | puiterwijk: cool. makes sense | 11:57 |
| puiterwijk | or the token could contain the permissions in itself, being signed by the authorization server. | 11:57 |
| puiterwijk | although this would make expiring harder, but it is mentioned as a possibility in the spec | 11:58 |
| puiterwijk | okay, so that is just one of the four ways to retrieve an access token.. I told you OAuth is big ;) | 11:59 |
| puiterwijk | abadger1999: you want me to continue these ways to get the access tokens, or do you want me to explain what happens afterwards? | 11:59 |
| abadger1999 | hmm.. if you have time, i guess the other ways to get access tokens | 12:00 |
| puiterwijk | sure, I have all the time you need ;) | 12:00 |
| abadger1999 | cool :-) | 12:00 |
| puiterwijk | the second way: "Implicit", which is a shortcut of the previous one, where the user gets the access tokens directly | 12:01 |
| puiterwijk | this is primarily meant if the client is implemented in browser, like a completely browser-side javascript client | 12:01 |
| puiterwijk | as here it doesn't make sense to use the authorization code, as the token will get retrieved by the same system anyway, so they skip that | 12:02 |
| puiterwijk | the third defined way to retrieve an access token is the "Resource owner password credentials": here the resource owner provides his password to the app, which it uses to retrieve an access token. so here the app still needs the password, but it can throw this away after it receives an access token | 12:03 |
| abadger1999 | puiterwijk: would that also be the way a CLI or desktop app would use to get the token? | 12:03 |
| abadger1999 | (the implicit way, that is) | 12:04 |
| puiterwijk | abadger1999: could be, but we could also chose the password system, or even the fourth system: "Client credentials" | 12:04 |
| abadger1999 | k. /me listens to the fourth option | 12:04 |
| puiterwijk | sorry, /me had misremembered the fourth option | 12:05 |
| puiterwijk | the fourth is meant if the client is the resource server by itself, to define it can access its own resources by authenticating itself | 12:06 |
| puiterwijk | abadger1999: I would suggest CLI apps to use the "resource owner password credentials" way, and desktop apps to use the implicit way | 12:07 |
| abadger1999 | in the third option, where does the username +password go? directly from the client app to the resource server? | 12:08 |
| puiterwijk | this is because it's much harder to use a web-service from an CLI client I think | 12:08 |
| puiterwijk | no | 12:08 |
| puiterwijk | in the third option, the client uses the username+password to request an access token | 12:08 |
| puiterwijk | after this, the client can forget the username+password, and just use the access token | 12:08 |
| abadger1999 | k. so it still goes to the authz server. | 12:08 |
| puiterwijk | yes, as mentioned: these are the ways to get an access token | 12:09 |
| puiterwijk | all access tokens are provided by the authz server | 12:09 |
| puiterwijk | so every authorization is passed by the authorization on one way or the other | 12:10 |
| abadger1999 | for the fourth method; how does it prove that it is the resource server itself? | 12:10 |
| puiterwijk | abadger1999: undefined... :/ | 12:11 |
| abadger1999 | puiterwijk: okay. so it could be implemented as "special user+password that represents the auth server", for instance? | 12:11 |
| puiterwijk | ho | 12:12 |
| abadger1999 | and then it's really equivalent to the third option? | 12:12 |
| puiterwijk | oh, yep | 12:12 |
| puiterwijk | although the "special user+password" represent the client | 12:12 |
| puiterwijk | the fourth way is meant if FAS would request a resource from FAS | 12:12 |
| puiterwijk | (for example) | 12:13 |
| puiterwijk | so if client == resource server | 12:13 |
| puiterwijk | I think using that fourth way is too much overkill for us for the moment, but still wanted to mention it to be complete ;) | 12:13 |
| abadger1999 | yeah -- I'm just trying to figure out when the client would request something from itself and if there's a specialcase in how it needs to auth (or if it's just for the flexibility of letting it auth in a different manner) | 12:13 |
| abadger1999 | s/client/resource server/ | 12:14 |
| abadger1999 | they're client == resource server so the sentence is the same, but it seems clearer if I had said resource server there :-) | 12:14 |
| puiterwijk | it's meant when you have/want real tight seperation between tenants for example, so that the resource server has to get authorization to retrieve information from another tenant ;) | 12:15 |
| abadger1999 | okay. | 12:15 |
| puiterwijk | so that one's quite overkill for us | 12:15 |
| abadger1999 | <nod> | 12:15 |
| puiterwijk | okay, those are the ways to get an access token | 12:16 |
| puiterwijk | OAuth also provides the possibility of "rekeying", or refreshing the token | 12:17 |
| puiterwijk | with the access token, the authorization server can also provide a refresh token | 12:17 |
| puiterwijk | then the access token could have a very short validity time, like a week or so, after which it becomes invalid | 12:18 |
| puiterwijk | at this moment, the application can request a new access token by using the refresh token | 12:18 |
| puiterwijk | (and the refresh token itself can ALSO have an expiry date) | 12:19 |
| puiterwijk | and most probably, the refreshed access tokens would have the same authorizations, although they are allowed to have a different authorization-set | 12:20 |
| abadger1999 | security-wise, what does a refresh token give you as opposed to just allowing longer validity on the access token? | 12:21 |
| abadger1999 | are they supposed to be kept in different places? | 12:21 |
| puiterwijk | abadger1999: it gives you the rekeying | 12:21 |
| puiterwijk | the token is used to encrypt the signatures | 12:21 |
| abadger1999 | or just to ensure that the access is actually being used? | 12:21 |
| puiterwijk | and if you use the same token too much, it might leak too much information (and is suspectable to brute-forcing) | 12:21 |
| puiterwijk | the refreshing is used so that the application doesn't use the access code for long periods of time, after which it could be cracked | 12:22 |
| abadger1999 | okay -- so it's to limit the amount of cyphertext that's possibly intercepted that has been encrypted or signed using a single access token? | 12:23 |
| puiterwijk | indeed | 12:23 |
| puiterwijk | and the amount of time the same key is used | 12:23 |
| abadger1999 | okay. it isn't intended to protect against the access token itself being stolen. | 12:23 |
| puiterwijk | no | 12:23 |
| abadger1999 | got it. okay. | 12:24 |
| puiterwijk | and that's the basics of OAuth | 12:24 |
| abadger1999 | okay-- so getting back to an earlier question: | 12:26 |
| abadger1999 | [11:46:44] <abadger1999> puiterwijk: does the authorization server needs to know about the range of tokens or is what token is requested sent to it on demand by the resource server somehow? | 12:26 |
| abadger1999 | [11:47:04] <puiterwijk> abadger1999: yes | 12:26 |
| puiterwijk | I will scroll back to that logs, as I'm not sure anymore about the context | 12:26 |
| abadger1999 | was a that a yes to the authz server knowing ahead of time what tokens it can grant? | 12:27 |
| abadger1999 | <nod> | 12:27 |
| puiterwijk | abadger1999: I have to say I don't really understand anymore what you mean. could you clarify your question a bit? | 12:28 |
| abadger1999 | So the client makes a request to the authz server for resource X, Y, Z for resource owner foo. Does the authz server have to know ahead of time that it is responsible for authorizing requests for resource X, Y, and Z? | 12:29 |
| puiterwijk | so you want to know if it has to know up-front that it can provide authorization for "full name of puiterwijk" and "ssh key of puiterwijk"? | 12:30 |
| abadger1999 | Or can it say "Foo authenticated with me and said it was okay to access these resources so here's an access token. It's up to you (the client) to find out if the resource server will accept it." | 12:30 |
| abadger1999 | puiterwijk: correct. | 12:30 |
| puiterwijk | abadger1999: have to say again... undefined, so we can choose whichever is most fortunate for us | 12:31 |
| puiterwijk | ah no, officially this is undefined | 12:32 |
| puiterwijk | but there is defined that the user has to approve the authorizations it grants | 12:32 |
| abadger1999 | <nod> | 12:32 |
| puiterwijk | my interpretation says that means the user should be shown a user-friendly description of the authorizations | 12:32 |
| abadger1999 | what is the format of the resource information so that the user can know what they are approving? | 12:33 |
| puiterwijk | officially, undefined. I would assume the user gets to see a list of permissions, like "file a bug report in bugzilla" and "create an update in bodhi" | 12:34 |
| puiterwijk | s/assume/like to see/ | 12:34 |
| abadger1999 | I'm just wondering if it gives you room to write a short symbolic name or a one sentence description or a paragraph description. | 12:34 |
| puiterwijk | it gives you roo mfor both | 12:34 |
| abadger1999 | k | 12:34 |
| puiterwijk | s/roo mfor/room for/ | 12:35 |
| puiterwijk | both/either | 12:35 |
| abadger1999 | is oauth intended to be very granular in its permissions? | 12:35 |
| puiterwijk | "undefined" | 12:35 |
| abadger1999 | okay -- so it could be "function by function" or it could be "anything this resource server provides" | 12:35 |
| puiterwijk | (sorry about having to say much "undefined"'s, but that was what is meant by that it will produce many non-interoperable clients) | 12:35 |
| puiterwijk | yep, or a mix of both | 12:36 |
| abadger1999 | and that's just a question of how the resource server was coded. | 12:36 |
| abadger1999 | k | 12:36 |
| abadger1999 | a client can ask for a set of permissions (give me access to resource X and resource Y). | 12:36 |
| abadger1999 | what implementation details are specified about how that works? | 12:37 |
| abadger1999 | authz server returns one authorization code that liss all of the permissions? | 12:37 |
| abadger1999 | or one for each permission | 12:37 |
| abadger1999 | resource server returns one access token or several? | 12:38 |
| cluecrowd | one | 12:38 |
| abadger1999 | cluecrowd: for both of those questions, I assume? | 12:39 |
| puiterwijk | one access token per combination of app and set of permissions | 12:39 |
| abadger1999 | k | 12:39 |
| abadger1999 | puiterwijk: app + client + permissions? | 12:39 |
| puiterwijk | abadger1999: sorry, client + permissions | 12:39 |
| abadger1999 | ah okay. | 12:40 |
| puiterwijk | one token could give access to multiple apps | 12:40 |
| abadger1999 | oh -- i see my confusion. I don't think we strixtly defined "app" | 12:40 |
| abadger1999 | are you using it to mean client? | 12:41 |
| puiterwijk | "app" = "resource server" | 12:41 |
| puiterwijk | in the last case | 12:41 |
| puiterwijk | one token is bound to a single client, but could grant access to multiple "resources" on multiple "resource servers", as long as all resources are owned by the same resource owner | 12:42 |
| puiterwijk | or at least | 12:42 |
| puiterwijk | doesn't have to be the same resource owner | 12:43 |
| puiterwijk | but the resource owner needs to have the required permissions to grant that set of permissions | 12:43 |
| abadger1999 | okay -- how does that work? the client combines access tokens it received from multiple resource servers into one? | 12:43 |
| puiterwijk | no, it received the access token from the authz server | 12:44 |
| abadger1999 | (I'm not sure we'll need this... but I'm not sure how this works) | 12:44 |
| puiterwijk | so for example: if an application requested it, I could grant it a token to give it the permissions "create an update for sslsplit on bodhi" and "update the ssh key for puiterwijk in FAS", in a single token | 12:45 |
| cluecrowd | the token is just a blob, the permissions associated with it are server side, the client doesn't what it has until it tries to do something | 12:46 |
| cluecrowd | then its either allowed or not | 12:46 |
| abadger1999 | i thought the authorization code came from the authz server. then that was used to request an access token from the resource server? | 12:46 |
| puiterwijk | abadger1999: no, both authorization codes and access tokens are provided by the authz server | 12:47 |
| puiterwijk | and then the resource server checks the token (either by contacting the authz server or by checking the list the authz server sent to him, or whatever) | 12:47 |
| puiterwijk | but all tokens and codes are granted by the authorization server | 12:48 |
| abadger1999 | okay. | 12:48 |
| abadger1999 | so that's how the client can have an access token that grants permissions on multiple resource servers. got it. | 12:49 |
| puiterwijk | okay, great :) | 12:49 |
| abadger1999 | so a client should have one access token from all the authz servers that it talks to (usually, ther'd be only one) each token would grant a set of permissions that the user had authorized for all the resource servers that acknowledge that particular authz server as being canonical for them. | 12:51 |
| abadger1999 | does that sound right? | 12:52 |
| puiterwijk | yep, indeed | 12:52 |
| abadger1999 | cool. | 12:52 |
| puiterwijk | (although the word "canonical" makes me feel bad :)) | 12:52 |
| abadger1999 | hehe :-) | 12:52 |
| puiterwijk | let's call it "being authorative for them", right? :) | 12:53 |
| puiterwijk | s/right/agreed/ | 12:53 |
| abadger1999 | puiterwijk: the mapping of access token to permissions is not contained in the token, correct? it's something that the authz server negotiated with the resource owner and then the authz server tells the resource servers about? | 12:54 |
| puiterwijk | abadger1999: could be both | 12:54 |
| puiterwijk | but we should prefer that way indeed | 12:54 |
| abadger1999 | okay. | 12:54 |
| abadger1999 | puiterwijk: okay, I think this is pretty clear in my head now. | 12:55 |
| abadger1999 | so some questions about how we might want to use this in fedora... | 12:55 |
| puiterwijk | the other would be to encode it in the token, and sign it, but as I mentioned earlier that would make premature expiration harder | 12:55 |
| puiterwijk | yeah? | 12:55 |
| abadger1999 | does it make sense to conceptually separate a session authorization from this concept? | 12:56 |
| puiterwijk | "session authorization" being a web-session where the user signed in? | 12:57 |
| abadger1999 | in my mind, sessions last minutes to hours and are intended to let the server reasonably assume that this user is the same one who signed in a "little while ago". | 12:57 |
| abadger1999 | puiterwijk: yeah -- that's where it would come from I think. | 12:57 |
| abadger1999 | some web sites (like bz.redhat.com) seem to keep a session around for months but... I kinda thnk that's an abuse of sessions. | 12:58 |
| puiterwijk | access tokens are mostly days to weeks, and are intented to let the server assume that this is the same app that got permissions | 12:58 |
| abadger1999 | puiterwijk: something that lasts for weeks to years seems like it's better suited to access tokens like this. | 12:58 |
| puiterwijk | I kind-of-agree | 12:59 |
| puiterwijk | except that that's why we have refresh tokens;) | 12:59 |
| puiterwijk | but otherwise: yeah | 12:59 |
| abadger1999 | puiterwijk: <nod> so does this sound like an okay conceptual split to you? or is it not beneficial to split this up like this? | 12:59 |
| puiterwijk | well, it does, but to me sessions are not just "short-term tokens": sessions are something where we know the user is currently controlling everything | 13:00 |
| puiterwijk | a token is an authorization given by the user to the app keeping the token to perform a specific set of actions on his/her bahalf | 13:00 |
| puiterwijk | s/bahalf/behalf/ | 13:01 |
| abadger1999 | puiterwijk: ah. okay so conceptually sessions prove the user is present. access tokens show that the user has granted this client permission to perform an action for them. | 13:01 |
| puiterwijk | indeed | 13:01 |
| abadger1999 | the user could be present using the client or not present. but the idea of the client sitting between the user and the resource server is the important distinction ? | 13:02 |
| puiterwijk | indeed | 13:02 |
| puiterwijk | the idea is that the user is not directly in control of what's happening, but that he delegated a set of tasks to a client | 13:03 |
| puiterwijk | the fact that he might be influencing it isn't taken into consideration | 13:03 |
| abadger1999 | <nod> | 13:03 |
| puiterwijk | for example with fasClient: we delegate the creation of users and updating of ssh keys to fasClient | 13:04 |
| puiterwijk | but I do not delegate responding on a bugzilla ticket to bugzilla | 13:04 |
| abadger1999 | right. where it gets grey to me is how we want to categorize something like pkgdb-cli | 13:04 |
| abadger1999 | or /usr/bin/bugzilla (from python-bugzilla) | 13:05 |
| puiterwijk | /usr/bin/bugzilla would be delegating to me, as I'm not accessing the resource server directly | 13:05 |
| puiterwijk | but that's how I see it. I do agree with you that it is a bit of a grey area | 13:06 |
| abadger1999 | puiterwijk: well... but as we talked baout the other night, you aren't doing so directly when you browse to the website in firefox either. | 13:06 |
| abadger1999 | but I do agree that it is nice to have less things that you have to trust :-) | 13:06 |
| puiterwijk | I personally would go for tokens for CLI tools as well, as you might script those | 13:07 |
| abadger1999 | puiterwijk: is there a problem with having a library that allows you to use either method? | 13:08 |
| puiterwijk | abadger1999: there wouldn't be a problem, but it would be hard to build and maintain, I'd think | 13:08 |
| puiterwijk | I would think that we should just use tokens for that, but maybe tokens with a validity of an hour or so | 13:08 |
| abadger1999 | tangent -- when using a token to communicate with a server, should a session be issued? Or should a session never be issued for that use case? | 13:09 |
| puiterwijk | I think you mostly use APIs in a stateless way, so I'd say: no sessions | 13:09 |
| abadger1999 | puiterwijk: the hting is... I think I would want to have different permissions if I was running the cli client myself vs having it run from cron. | 13:09 |
| abadger1999 | well that's one of the things. | 13:09 |
| puiterwijk | abadger1999: +1 on the different permissions | 13:10 |
| puiterwijk | and about the sessions for tokens: | 13:10 |
| abadger1999 | the other one is that I'd want to protect the credentials for the one I run from the cli differently. | 13:10 |
| puiterwijk | +1 on that as well | 13:10 |
| abadger1999 | ie: if I can build and push packages with the cli, I might want to use my otp to confirm it. | 13:10 |
| <-- abompard has left this server (Ping timeout: 252 seconds). | 13:10 | |
| puiterwijk | about the sessions: I would not care if there is used any session, as long as the authentication status is not mentioned in it | 13:11 |
| abadger1999 | but if I have a cron job that checks for builds of packages that are deps of packages I own, I'd be fine with it using an access token saved on the filesystem. | 13:11 |
| puiterwijk | <nod> | 13:11 |
| puiterwijk | but for this, we could also use tokens with different validity periods | 13:12 |
| abadger1999 | puiterwijk: by authentication status, you mean whether it's valid or expired? Or whether something else? | 13:12 |
| puiterwijk | like a 5-minutes (or 1-hour, or whatever) token for CLI, approximating sessions, and a 1-month (or longer) token for the cron job | 13:12 |
| abadger1999 | <nod> | 13:12 |
| puiterwijk | abadger1999: any information on the token or any information on whether the client was authenticated | 13:13 |
| puiterwijk | so I would be fine with storing things like "previous-action" in a session, but not to store "authenticated-as: puiterwijk" or "permissions: create-update,view-updates,..." in a session | 13:13 |
| puiterwijk | (please note that this is my personal preference) | 13:14 |
| puiterwijk | this is primarily because the client can send the token on any request, and we might want to check its validity on every request | 13:14 |
| abadger1999 | ah... so when i'm talkign about sessions... I guess I'm rally just talking about the value that identifies you to the server. | 13:15 |
| abadger1999 | *I guess I'm really | 13:15 |
| puiterwijk | ah, then I wouldn't be a proponent of that | 13:15 |
| abadger1999 | the value is basically a secret key (and perhaps some form of uid) | 13:15 |
| puiterwijk | yeah, I understand | 13:15 |
| puiterwijk | but what would be the advantage? | 13:15 |
| puiterwijk | then the resource server needs to check that secret key, instead of the token | 13:16 |
| puiterwijk | but it still needs to check it | 13:16 |
| puiterwijk | so I don't see the advantage of using that | 13:17 |
| abadger1999 | <nod> I'm trying to figure that out. Is there a value in having a different mechanism to show "User is present and interacting with the resource server" vs "User has delegated permission to this client to act on their behalf" | 13:17 |
| puiterwijk | ah, yeah, there could be value | 13:18 |
| puiterwijk | namely: if the user is present, the permissions wouldn't need to be checked as tightly | 13:18 |
| abadger1999 | <nod> | 13:18 |
| puiterwijk | so if the user is present we might created an "*@*" permissions token | 13:18 |
| puiterwijk | (so: every permission on every resource server) | 13:18 |
| puiterwijk | but as this could be done with tokens, I would not see any reason to support both | 13:19 |
| puiterwijk | the only advantage would be that it saves a few roundtrips to the authz server, but we would just have to make that very efficient anyway | 13:20 |
| abadger1999 | <nod> So same mechanism but tokens that have different permissions and we treat in different ways. | 13:20 |
| puiterwijk | we treat them the same, but just a "*@*" permission instead of a real list of permissions | 13:21 |
| abadger1999 | by treat differently... I meant the client would need to know -- this is a token that I should not automatically save to disk, for instance. | 13:21 |
| puiterwijk | ah, yeah, agreed then | 13:21 |
| puiterwijk | (hmmm, I might want to look into when to use "then" and when to use "than" in English :)) | 13:22 |
| abadger1999 | (heh, most english speakers have given up figuring out the distinction ;-) | 13:22 |
| puiterwijk | (okay, I know now, sorry if I evr did that wrong :)) | 13:22 |
| puiterwijk | (well, according to the site I just saw "than" is comparisons, and "then" is time or order) | 13:23 |
| puiterwijk | but anyway, I agree on that | 13:24 |
| abadger1999 | puiterwijk: so... some things to think about... how hard will it be to create this infrastructure? (write an authorization server. Add permissions to apps [can cheat initially and have a permission for the whole app]. Have the app talk to the authorization server to confirm whether the client that presented a token is allowed to perform the desired action) | 13:25 |
| puiterwijk | abadger1999: with my recent experience on OpenID, I think I could implement this pretty easily | 13:26 |
| puiterwijk | both the server-side and a library for python to use it | 13:26 |
| [Notice] -GitHub150 to #fedora-apps- [fedmsg] ralphbean created feature/tweet-as-hub (+2 new commits): http://git.io/_NyKVA | 13:26 | |
| [Notice] -GitHub150 to #fedora-apps- fedmsg/feature/tweet-as-hub 8aefb3c Ralph Bean: Some PEP8. | 13:26 | |
| [Notice] -GitHub150 to #fedora-apps- fedmsg/feature/tweet-as-hub 9d2ab13 Ralph Bean: Reorganize fedmsg-tweet into a single-purpose hub like the other daemons. | 13:26 | |
| abadger1999 | puiterwijk: Okay. I'm liking this then. | 13:26 |
| puiterwijk | abadger1999: okay, do I have permission to start on it then? ;) | 13:27 |
| abadger1999 | puiterwijk: next step -- write up the important bits and ask whether other people like it? | 13:27 |
| puiterwijk | at least some basic showcase, so I can show something | 13:27 |
| abadger1999 | puiterwijk: I can summarize what we talked about here and send it to the mailing list. | 13:27 |
| puiterwijk | abadger1999: that would be nice yeah | 13:27 |
| abadger1999 | puiterwijk: yeah -- if you want to get started on coding, I think this is desirable. | 13:27 |
| puiterwijk | and as I said: I would be glad to take "control" in te FAS-OAuth project as well, if you would let me :) | 13:28 |
| abadger1999 | puiterwijk: yep, yo're welcome to take ownership of that too :-) | 13:28 |
| puiterwijk | hmmm, "control" sounds too powerful | 13:28 |
| puiterwijk | okay, thanks :) | 13:28 |
| abadger1999 | "responsibility for" ;-) | 13:28 |
| puiterwijk | yeah, that's what I was looking for, thanks :) | 13:28 |
| [Notice] -GitHub43 to #fedora-apps- [fedmsg] ralphbean opened pull request #124: Feature/tweet as hub (develop...feature/tweet-as-hub) http://git.io/m3KGPQ | 13:29 | |
| abadger1999 | puiterwijk: oh one other thing -- skvidal mentioned that one thing he liked about api tokens is that a compromised token doesn't give you anywhere near the same amount of access as a compromised fas password. | 13:29 |
| abadger1999 | we'll have to think about how that interacts with our "*@*" tokens. | 13:30 |
| puiterwijk | abadger1999: that's correct, since you could make sure a token never has the possibility to change a password | 13:30 |
| puiterwijk | you could say that even *@* does not have permissions to change password/email in FAS | 13:30 |
| abadger1999 | puiterwijk: <nod> yeah, I'd agree with that. | 13:30 |
| puiterwijk | and you won't be able to use tokens to login to the web interfaces, so you can't use that either with just a token :) | 13:31 |
| abadger1999 | puiterwijk: he was thinkng in terms of an api token for copr wouldn't give you access to bodhi or pkgdb as well, though. we'd have to think about that as well. | 13:31 |
| puiterwijk | well, that's because a token has a specific set of permissions | 13:32 |
| abadger1999 | puiterwijk: yeah -- but my vision is that anything you can do on the web ui (with limits like password changing) you can do via the api :-) | 13:32 |
| puiterwijk | and every permission is for a specific resource server | 13:32 |
| puiterwijk | yeah, I agree. but then a token would have to be requested for all permissions an app would want to do | 13:32 |
| puiterwijk | s/do/have/ | 13:33 |
| puiterwijk | but with "permissions", you won't have something like "view", but rather you'd have "bodhi.view" and "copr.view.builds" and "copr.submitbuild" | 13:34 |
| puiterwijk | so a permission is app-specific | 13:34 |
| abadger1999 | puiterwijk: <nod> But we were talking about -- if the user has just logged in; how could we represent that? | 13:35 |
| puiterwijk | so it's not that you have permission "edit" for "copr,bodhi", but rather you would have "copr.edit,bodhi.edit" | 13:35 |
| puiterwijk | abadger1999: what do you mean? | 13:35 |
| abadger1999 | puiterwijk: well. when were you thinking we'd use the "*@*" token? | 13:36 |
| puiterwijk | if the user is present at the machine | 13:37 |
| puiterwijk | ah, I think you mean that tokens provide more security, but a "*@*" token doesn't? | 13:37 |
| abadger1999 | how do we want to determine that? | 13:37 |
| abadger1999 | right. | 13:37 |
| puiterwijk | I agree on that, but I can't see any real ways to prevent that | 13:37 |
| puiterwijk | except for giving the user to enter his password if the token requires more permissions | 13:37 |
| abadger1999 | so we want to allow the user to do all their business without asking them to reconfirm their identity all the time. But we also don't want that token to be left lying around to be stolen by someone. | 13:38 |
| puiterwijk | so that it's a "*@*/require-password-on-extending" | 13:38 |
| puiterwijk | indeed | 13:38 |
| puiterwijk | that's why I suggested an expiration time of a short time | 13:38 |
| cluecrowd | like kerberos | 13:38 |
| * puiterwijk doesn't see where kerberos fits in, as that uses a key-requesting-key system... | 13:39 | |
| abadger1999 | puiterwijk: <nod> So something like we currently have for session cookies? Short time period (no more than 24 hours, hopefully much less). and when it expires, user has to reenter password/otp to get a new "*@*" token? | 13:39 |
| puiterwijk | abadger1999: what I would suggest: issue tokens with a validity time of +- 5 minutes, and refresh tokens of about 15 or so | 13:39 |
| puiterwijk | yes, indeed | 13:40 |
| abadger1999 | puiterwijk: wfm. | 13:40 |
| puiterwijk | abadger1999: "wfm"? | 13:40 |
| abadger1999 | works for me. | 13:40 |
| puiterwijk | ah, ok, cool :) | 13:40 |
| * abadger1999 wonders if we could get away with requiring an otp to get a '*@*' token | 13:40 | |
| * puiterwijk also wonders the same | 13:41 | |
| puiterwijk | abadger1999: shall I create the fas-oauth repos on fh.o and github? :) | 13:41 |
| abadger1999 | puiterwijk: go for it :-) | 13:41 |
| puiterwijk | \o/ just when my previous project is about to hit production, I get a next nice project :) | 13:42 |
| puiterwijk|cue | puiterwijk: Error: "o/" is not a valid command. | 13:42 |
| abadger1999 | puiterwijk: you only need to create the fedorahosted one if you want it ... I think most of us have become happy with the github repos :-) | 13:42 |
| puiterwijk | xD | 13:42 |
| abadger1999 | hehe :-) | 13:42 |
| puiterwijk | puiterwijk|cue: part #fedora-apps | 13:42 |
| <-- puiterwijk|cue has left this channel ("puiterwijk"). | 13:42 | |
| puiterwijk | okay, I might want to reconfig it tto use another prefix :) | 13:43 |
| abadger1999 | :-) | 13:43 |
| puiterwijk | but I prefer fedorahosted, because there I can show my responsibility, because I'll be the only one able to commit.. muahaha :) | 13:43 |
| abadger1999 | hehee :-) | 13:43 |
| puiterwijk | for FAS-OpenID, the fh.o is the main copy, and github is just a mirror :) | 13:44 |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!