On Mon, Mar 11, 2013 at 12:28:47PM -0600, Kevin Fenzi wrote: > > So, if you got a token for 'build new packages in existing copr' and > later went and got a 'make new copr' token in addition to your existing > permission, you would have two tokens? Or you could ask for one new > token with both permissions? Either would be valid? > I believe that either would be valid. puiterwijk can tell us if the spec says something about older tokens being invalidated if a new one is requested but I don't think it would be able to. Say that you have a client running on machine foo and the same software on machine bar. The server wouldn't be able to tell that you had two separate clients that you needed two separate tokens for in this case. > Additionally, you could get a new token for 'change toshios full name' > and get a new token for it, or a new token with it and 'build new > packages in existing copr' in the same token? > According to my understanding, you can do it either way as long as the authentication server is allowed to issue tokens for both. > > .. question:: an access token can contain permissions for multiple > > resource servers. How do we secure the token from being used > > maliciously by a different resource server? ie: I get an access > > token which grants some permissions on both fas and bodhi. I send > > that access token to fas to retrieve some information. What prevents > > fas from hanging onto that token and using it to access the protected > > resources on bodhi that it grants without my knowledge? > > Yeah, good question. > > What does a auth token look like? Just a file with encoded data? Can > you see what a token is issued by or for based on the token? > As discussed later, you could put various pieces of information in here but best practice would seem to indicate it's pretty anonymized (perhaps even just a hash?) The interpretation of what it does is then done on the server. > > - Resource owner password credentials: The resource owner provides > > their credentials (username and password) to the client. The client > > retrieves the access token from the authorization server using the > > credentials. Then it discards the credentials and only keeps the > > access token for further requests. > > This is nasty because the client could save the username/pass and reuse > it for other things, no? > This isn't really any different than what we have now in the CLI world, though. You have to trust the CLI programs to do the right thing. For third party websites, you would never want to use this model as you can never trust the client there to do the right thing. We could allow both methods if we want to cater to people who trust the CLI to do this conveniently vs those who are paranoid and want their web browser to be the only thing they trust. (Enter your username, password, and otp or the access_token you receive from visiting this [url]) > ...snip... > > > * Verification of the access token can take many forms. > > - The authorization server could notify the resource server > > whenever a new access token is issued/revoked > > Not sure that gets us too much. > Keeps us from having to query the authz server everytime a token is presented. I think it's a nbit of an optimization and probably pre-mature to think about doing it this way as a first pass. > > > * The authorization server may or may not know about the range of > > permissions that it can grant. The resource server needs to > > interpret what the permissions the access token grants mean so if the > > authorization server grants a made-up permission the application > > should just ignore it. > > > > .. question:: Is it possible for the user to grant some of the > > requested permissions and deny others? Or is it all or nothing? > > It might be better to reject a request entirely if you can't grant all > the permissions? Otherwise is there a clear way to note only the > permissions you actually granted? ie, "Can I build new coprs and > packages in this copr" and it rejects new coprs but grants build, the > caller could be confused when it goes to try and use the token for > something that wasn't granted. > I believe the client gets failure or an access token and doesn't know what permissions are embodied by that token. It probably does make sense to fail in most circumstances. But I think there might be cases where it makes sense not to fail. Perhaps being able to customize the list of permissions a token would have in another UI would take care of those use cases though... > > > === Using tokens to implement sessions === > > Is this something we want to do? > Maybe.... If we used tokens to implement sessions, we'd be able to cut down on the number of different mechanisms that one could use to gain permission to access a protected resource. That is good in several different ways: less places where bugs can crop up, less things to test, less things to code and maintain.... It also would mean that resource server methods that took oauth tokens would also take sessions with very few changes. OTOH, I don't want to shoehorn something that is a bad fit. On yet another hand, I don't know if we'd be able to entirely get rid of the cookie implementation of sessions. Web browsing might still rely on cookie-based sessions. API might purely use access token sessions. (This might still have a side benefit though -- if access tokens aren't something handled automatically by the web browser and cookies don't work on the api, then csrf protection isn't needed on the api.) > > .. question:: Can we also have a maximum number of refreshes or > > maximum time before the user has to reenter their credentials > > (username + password (+otp?)) > > Only by expiring the token and making them get a new one I guess? > I think this would be an implementation detail for the oauth-server. The server would record either the first time the chain of tokens was issued with a or it would record the number of refreshes. After a limit is exceeded, it would invalidate (or not send) the next refresh token along with the access token. When that access token expired, the user would have to reauthenticate. > > > == Some proposed best practices == > > > > * Also following from that -- we should write things to allow for a > > session to be sufficient for allowing users to perform actions. > > access tokens describe a subset of the functions that the user > > themselves is allowed to perform. > > I guess that's assuming we replace sessions with tokens... > This is actually generic to me. It would be made easier if we replace sessions with tokens. I see two use cases: * Case one: I have a script that run /usr/bin/copr build toshio/pkgdb on every commit to the pkgdb repo. * Case two: I want to run /usr/bin/copr new-repo toshio/messing-about myself. Then I want to run /usr/bin/copr build toshio/messing-about on a specific srpm. I would prefer not to have to retype my credentials twice if I'm running those one right after the other. Both of these tasks will use /usr/bin/copr However, the first requires that the permissions reside on disk unencrypted and remain valid for a long period. The second requires that the permissions be stored for a short period (perhaps on disk but also potentially in a password manager if you're running one in your desktop session). The second task is what we conceptually think of as a session. The user is present and doing somewhat arbitrary things that the user wants to do at that time. It could be implemented with a cookie or with an authorization token. What this best practice is trying to accomplish is to make a single api function serve both use cases. It could be done by making the api function accept both cookie auth and token authz but then you have to code the server for both cases. > > * Client side -- we want to have different permissions if the user is > > running the cli from the command line vs running the cli from a cron > > job. A user running from the cli could be said to have a session. > > Sure. But if we kept sessions and tokens seperate we could do that > too, no? > Yep. client side, we can separate sessions vs restricted-permissions-tokens no matter what. What this best practice is saying is that if we combine the mechanism by which we're serving tokens and sessions, we still want to handle them differently on the client end. > So, what are our initial use cases for this? I guess coprs is a big > one. Any other obvious ones on the map right now? > datagrepper wants to implement auth tokens as well. pingou and I (mostly pingou :-) is working on revamping the pkgdb api. It would be the right time to add a consistent authn/z piece to the api. > I'd like to be carefull about this, and not just convert everything, > but have a few apps that could use it written up with use cases, etc. > yeah -- I'd like to but... I'm not sure we have as much time as we'd like here. -Toshio
Attachment:
pgp3Oa2Ho7jgA.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
