Flock/Volunteers/OAuthHackfest

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

What do we need/want?

Use cases (that we can't already do now)

• 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

Open Questions

• 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?

Advantages of tokens

(To merge above)

Potential Solutions

• 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