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.

Author: MikeSpreitzer

docs/admin/accessing-the-api.md

@@ -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