Removed confusing remark about authorizers determining groups

The old text said that the authorizer is expected to determine group memberships when the authenticator does not. This not true. It is allowed, but not expected --- and none of the standard authorizers do it. I tried composing a brief correct statement about this, but the reviews were mainly aghast that internal details of some non-standard authorizers were being injected into the discussion of authentictors. I decided that the better part of valor is simply to delete the whole topic from here. Besides, it is a conclusion that any reader would normally draw --- since there is no statement forbidding it (nor indeed any indication that there might be a reason to forbid it), any reader would naturally conclude that an authorizer is free to derive additional intermediate information of any sort and in any way it likes.
2016-09-25 15:24:59 -07:00
parent 2c14d7fcb0
commit 12f5e30309
1 changed files with 2 additions and 2 deletions
@@ -52,8 +52,8 @@ On GCE, Client Certificates, Password, Plain Tokens, and JWT Tokens are all enab
 If the request cannot be authenticated, it is rejected with HTTP status code 401.
 Otherwise, the user is authenticated as a specific `username`, and the user name
 is available to subsequent steps to use in their decisions.  Some authenticators
-may also provide the group memberships of the user, while other authenticators
-do not (and expect the authorizer to determine these).
+also provide the group memberships of the user, while other authenticators
+do not.

 While Kubernetes uses "usernames" for access control decisions and in request logging,
 it does not have a `user` object nor does it store usernames or other information about