Standardize authentication and authorization terms

[Chris Kellogg <cc...@gmail.com>]

The Pulsar code base uses different terms (principal, role, client-id,
app-id, etc..) when referring to authentication and authorization.
Different places use different terms that may or may not mean the same
thing. All these different terms get overloaded and make it confusing to
reason about the code. Additionally, it makes it challenging to
talk/discuss code related to authentication/authorization.

I propose we standardize on a few terms and then clean up the code and docs
to reflect this. I suggest the following terms:

principal => this identifies a client and is a unique value.
role => a role or roles are associated with a principal and the role(s) are
used to determine whether or not the principal can perform a certain action.

Based on these definitions I think the job of the two auth interfaces are.

AuthenticationProvider => identify the client and return the principal
AuthorizationProvider => determine whether or not the principal can perform
a certain action.

Thoughts?

Re: Standardize authentication and authorization terms

[Jerry Peng <je...@gmail.com>]

Hi Chris,

This is a good idea! We are intermixing a lot of terms in the code which
might cause confusion and bugs in the future.  Please formalize what you
are proposing in a PIP.  Thank you!

Best,

Jerry

On Tue, Jun 1, 2021 at 11:45 PM rxl@apache.org <ra...@gmail.com>
wrote:

> Hello Chris:
>
> This is a good idea. If possible, you can submit a PIP to list the
> confusion of the current terminology and if we want to unify, do we need to
> make some changes to the current structure?
>
> In this case, it is convenient for us to further evaluate whether the
> current idea can be better implemented.
>
> --
> Thanks
> Xiaolong Ran
>
>
> Chris Kellogg <cc...@gmail.com> 于2021年6月2日周三 上午6:04写道：
>
> > The Pulsar code base uses different terms (principal, role, client-id,
> > app-id, etc..) when referring to authentication and authorization.
> > Different places use different terms that may or may not mean the same
> > thing. All these different terms get overloaded and make it confusing to
> > reason about the code. Additionally, it makes it challenging to
> > talk/discuss code related to authentication/authorization.
> >
> > I propose we standardize on a few terms and then clean up the code and
> docs
> > to reflect this. I suggest the following terms:
> >
> > principal => this identifies a client and is a unique value.
> > role => a role or roles are associated with a principal and the role(s)
> are
> > used to determine whether or not the principal can perform a certain
> > action.
> >
> > Based on these definitions I think the job of the two auth interfaces
> are.
> >
> > AuthenticationProvider => identify the client and return the principal
> > AuthorizationProvider => determine whether or not the principal can
> perform
> > a certain action.
> >
> > Thoughts?
> >
>

Re: Standardize authentication and authorization terms

["rxl@apache.org" <ra...@gmail.com>]

Hello Chris:

This is a good idea. If possible, you can submit a PIP to list the
confusion of the current terminology and if we want to unify, do we need to
make some changes to the current structure?

In this case, it is convenient for us to further evaluate whether the
current idea can be better implemented.

--
Thanks
Xiaolong Ran


Chris Kellogg <cc...@gmail.com> 于2021年6月2日周三 上午6:04写道：

> The Pulsar code base uses different terms (principal, role, client-id,
> app-id, etc..) when referring to authentication and authorization.
> Different places use different terms that may or may not mean the same
> thing. All these different terms get overloaded and make it confusing to
> reason about the code. Additionally, it makes it challenging to
> talk/discuss code related to authentication/authorization.
>
> I propose we standardize on a few terms and then clean up the code and docs
> to reflect this. I suggest the following terms:
>
> principal => this identifies a client and is a unique value.
> role => a role or roles are associated with a principal and the role(s) are
> used to determine whether or not the principal can perform a certain
> action.
>
> Based on these definitions I think the job of the two auth interfaces are.
>
> AuthenticationProvider => identify the client and return the principal
> AuthorizationProvider => determine whether or not the principal can perform
> a certain action.
>
> Thoughts?
>