Flock/Volunteers/OAuthHackfest

From FedoraProject

Jump to: navigation, search

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

Contents

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