Hi Ron, Thanks. We can wait for Rajini's reply to finalize this, but for now I guess that will unblock the PR at least. If we do decide we want the restriction we can do a follow-on PR.
It's good to see this API moving forward! best, Colin On Tue, Sep 1, 2020, at 12:55, Ron Dagostino wrote: > Hi Colin. I've removed that requirement from the KIP and updated the PR > accordingly. > > Ron > > On Fri, Aug 28, 2020 at 2:27 PM Colin McCabe <cmcc...@apache.org> wrote: > > > Hi Ron, > > > > Thanks for the update. I agree with all of these changes, except I think > > we should discuss this one further: > > > > On Wed, Aug 26, 2020, at 14:59, Ron Dagostino wrote: > > > > > > 2. We added a restriction to not allow users who authenticated using > > > delegation tokens to create or update user SCRAM credentials. We don't > > > allow such authenticated users to create new tokens, and it would be odd > > if > > > they could create a new user or change the password of the user for the > > > token. > > > > > > > I don't think these two restrictions are comparable. It seems to me that > > we forbid creating a new token based on an existing token in order to force > > users of delegation tokens to re-authenticate periodically through the > > regular auth system. If they could just create a new token based on their > > old token, there would be an obvious "wishing for more wishes" problem and > > they could just sidestep the regular authentication system entirely once > > they had a token. > > > > This issue doesn't exist here, since creating a new SCRAM user doesn't do > > anything to extend the life of the existing delegation token. If the user > > has the permission to change SCRAM users, I don't see any reason why we > > should forbid them from doing just that. Users of delegation tokens > > shouldn't be second-class citizens. A user with ALTER on CLUSTER should > > have all the permissions associated with ALTER on CLUSTER, regardless of if > > they logged in with Kerberos, delegation tokens, SCRAM, etc. etc. I don't > > think the proposed restriction you mention here is consistent with that. > > > > best, > > Colin > > >
