On Mon, Mar 11, 2013 at 07:42:50PM +0100, Pierre-Yves Chibon wrote: > On Mon, 2013-03-11 at 11:28 -0700, Toshio Kuratomi wrote: > > On Mon, Mar 11, 2013 at 07:05:57PM +0100, Pierre-Yves Chibon wrote: > > > * Possibility to restrict a token's action > > > - Well this can already be discussed. It has been made clear that it > > > is a all or nothing mechanism (a bit like when installing an app on an > > > Android phone, you have the choice between giving this app access to > > > your contact, the gps... or not using the app). Meaning, since most if > > > not all our tools will be able to perform most of the action possible on > > > the website, it's pretty much coming back on having one big token to use > > > the APi of the website. > > > > > You'd need a big token if you intend to use all of the api. You wouldn't if > > you only intend to use a portion of it. > > > > The thing that we seem to be getting hung up on is that a CLI application > > can potentially access all of the API of a single resource server and > > potentially other resource servers as well. > > hm, atm we have one CLI per application, tbh, I'd rather keep it this > way. > That's not quite true... Things like fedora-active-user hit multiple resource servers. Thankfully, only one of those requires authn/z to get the information it needs. There's plenty of on off scripts in infrastructure that need to access the API of multiple resources (pkgdb, koji, fas, bodhi are all intertwined). > > What I would propose here is > > that we utilize puiterwijk and my thoughts on emulating sessions to have one > > big token per resource server. > > So we're back pretty much on 1 token / application (pkgdb, copr...) > which would be the approach we would take if we implement token w/o > oauth. > No. We're 1 token per application *if and only if* the user is actively using the application at the moment. We've got to separate out the session use case which is really only going to work with single token from the scripted use case. We can make both of those more secure if we treat them separately. > > But that token has a very limited lifetime. > > That makes it inappropriate for scripting and cron jobs. When you want to > > make a shell script that runs on its own, you need to get a different token > > that has more limited permissions. That sort of token would have a longer > > or perhaps indefinite lifetime (indefinite when you consider the presence of > > refresh tokens). > > Meaning, we need to have a way to generate a token for the user (where > he can choose which permission he associates with the token), no? > That really depends on implementation. We need to be able to generate targeted tokens. But how we generate them is up in the air. here are some ways: * Browse to a fas-oauth web page that as lists of permissions that you can pick through to assemble a single token with a long expiry. * Run a command ( /usr/bin/copr --generate-token build ) that makes the request for only the needs that the command has. * Run a command that prints out a url that you use to retrieve the token > > > Actually, how are the CLI supposed to work if we don't integrate oauth > > > with goa? > > > > There are several methods depending on how much we want the user to trust > > the commandline app. puiterwijk and I agreed that we could use the > > "Resource owner password credentials" method -- this would require giving > > the username and password to the CLI app which would then perform the > > necessary calls to the resource server to get the access token. It could > > also be done using one of the other methods if you don't want to require the > > user to trust the CLI app we write :-) > > But then that's pretty much what we are already doing with for example > pkgdb-cli and to me that defeats a bit the point of tokens, where would > we use them then? > I my idea, tokens are there to replace the use of the password which if > intercept gives you access to more than the token itself (ie: with your > password I can change your password, with your api token I can change > the ACLs on your package) > I don't see how this defeats it. In order to retrieve a token, you need to authenticate yourself, correct. So whenever you retrieve a token you have to use your username and password (or other acceptable credential). There's always going to be the risk of interception there. The security benefit is we get to avoid ever storing the username and password on disk with any of the token methods we're discussing. Not that the username and password don't have to flow from you over the network to the server at some point in time. -Toshio
Attachment:
pgpHr04rQ2gmZ.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
