Auth plugins

This supercedes #1358. 

Since some folks want a very simple default implementation for auth, and others want to be able to plug in a more full-featured implementation, I've focused on the problem of defining how Authorization plugs in.

In the process, I found I was unable to talk about that without also defining how Authentication and Group Membership should plug in.  

I've also removed the text from access.md about "userAccounts", since I no longer feel that is resource type has to be part of kubernetes.
Decoupling this in the past has been beneficial - on demand group refresh is a nightmare to make perform, and still usually ends up being "you have to log out and log in to see changes".  Group revocation is usually more important in corporate setups but that can be a top down change (invalidate tokens for user X) if needed 


> On Sep 30, 2014, at 1:13 PM, roberthbailey <notifications@github.com> wrote:
> 
> In docs/proposals/auth_plugins.md:
> 
> > +## Design Summary
> > +Here are the key points of the design:
> > +  - APIserver Architecture
> > +    - Authentication, Group Membership, and Authorization are handled by separate interfaces in separate steps by the APIserver.
> > +    - Cluster owners can chose from among contributed pacakges, or write their own go code to handle each of those steps.
> > +    - A single go package might implement one, two or all three interfaces with a single type.
> > +    - An implementation of one those interfaces might use external storage or it might add new k8s REST resources (that is, also be an API Plugin).
> > +  - Authentication
> > +    - An `/auth` endpoint on the apiserver generates short term random unscoped Bearer tokens which identify a user in subsequent API calls.
> > +    - API calls must include a valid Bearer token in an `Authorization` header.
> > +    - An IdentityProvider is go code that implements the `IdentityProvider` interface.
> > +    - The `/auth` handler uses an IdentityProvider to redirect the user to an actual identity provider.
> > +    - The IdentityProvider may use Oauth to communicate with the identity provider (google, facebook, github) or not (e.g. SAML).
> > +  - Group membership
> > +    - A GroupProvider is go code that implements the `GroupProvider` interface.
> > +    - The `auth` endpoint checks group membership right after checking identity.  The Bearer token it generates
> So group membership is cached for the lifetime of the bearer token rather than being checked on-demand (and potentially cached with a different lifetime) during requests? Is this so that we have a cleaner separation between identity and authorization? I suppose that if we did on-demand checks then the authorization module would need to depend upon the identity model to resolve which groups a user belongs to.
> 
> —
> Reply to this email directly or view it on GitHub.