Authorization and Policies

Here are some thoughts on how to make authorization pluggable, and how to express authorization policy.
We have to have a way for policy to reference groups as well as users.  Otherwise, the policy lines explodes.

I was envisioning group member checking as a step that is right after authentication and before authorization.  To facilitate this, the Authorizer interface would have a "GetRelevantGroups" method which gets all the groups that are mentioned by policy (perhaps filtered to a single namespace or user.)  

Example where a k8s cluster is configured to use accounts.google.com for user id checking and groups.google.com for group membership checking:
- k8s client sends API request to K8s for first time
- k8s apiserver redirects to `https://accounts.google.com` asking for "email" scope.
- user allows
- google redirects back to k8s with access token.
- k8s reads the users email and uses that as the user id.
- k8s apiserver redirects to google, requesting scope `https://apps-apis.google.com/a/feeds/groups/`
- user allows
- google redirects back to k8s with a second access token.
- k8s reads the users group membership from `https://apps-apis.google.com/a/feeds/group/2.0/{domain}/{group name}/member` once for each possible group returned by GetRelevantGroups.
- k8s does auth using the user and group membership just determined.

This probably works particularly well when the user is using 
Obviously this data gets cached for subsequent interactions, and there are some tricky cases when group membership changes, or policies referencing new groups are added.