Flock/Volunteers/OAuthHackfest

Authorization Hackfest (Flock 2013 - 2013-08-10)

What do we need/want?

Cron job runs some limited permission job every night (rebuild the packages in my copr)
User runs a CLI script that can do anything the user can perform via the API
Outside-of-infrastructure web applications can use limited authorizations for users without touching FAS passwords

Do we want to scrap tokens and just use OpenID on the command line?
Do we want to use the same authorization system for web application users and command line APIs?
- Tokens give us the ability to store an authz source on the filesystem that is limited in scope (unlike fas username+password)
- Web applications are typically assume a user is sitting there interacting with the interface. API does not make that assumption. So we want authn for the web application and authz for the command line API.
  - We actually want to make sure in the web-app that the user is who he pretends to be as it's the only way a user will be able to get a token
- Short answer would seem to be no.

Tokens (with time limit) per application?
- Each application/permission should have a specified maximum time. Tokens should expire no later than that time.
  - We can improve this by adding a sig param which is a hash of an shared_secret with a timestamp for each request.(additional proposition: request should have been sent in the 5min (or less) time to be valid)
    - Yeah but the server will have to check the expiration of the token anyway
- Users should be able to revoke their own keys
Tokens for each authorization permission?
Should applications be registered?
- How do we register applications running on user machines?

Define profile permissions
- List permissions in categories, allow a command line application the ability to request all permissions in a category (instead of having to change the permission list in the application)
Do we want people to be able to grant tickets via an existing ticket?
- No. We want an actual person to get a ticket. Tickets represent authz. We want authn verified in order to grant a new ticket.
- Note: The "No" Does not include automatic renewal due to rekeying
How do we enforce that applications only using the permissions they have been granted?
Should the application be able to tell what permissions a token grants it?
Should an application server be able to request modification of a token?
Should applications have to manage a stack of tokens?
Do we want a web application that can manage assembling permissions into a token?

(To merge above)

Use an Oauth Server and adapt web apps to use it (Oauthlib?)
ad hoc per application
- Means we have different code/implementation for each application
ad hoc for all of Fedora
- Customized version of 0auth(ish). Gives us a single implementation, but makes the selection of permissions harder because there's a lot of them
  - How is this different from the 0auth situation? There will also be a lot of different permission in this case
    - Yeah, I was going to add that there as well
- Also, the list of tokens for a user will grow very large maybe (especially for us infra who knows what they are doing and using the granularity)
  - That is assuming we do 1 token for multiple authorizations
    - Agreed, but just noting it down
  - Another option being to use 1 token per authorization
Just use openid
- equals to the current situation w/ the exception that we remove the login mechanisms from the different application onto the openid server