Christopher 2013-01-28, 20:14
I'm holding off, waiting for John's initial refactoring, before I provide a
lot of additional feedback, but I think Eric summed up much of the
conversation John and I had on IRC pretty well. I think the only place we
need to be concerned about AuthInfo is where it shows up in the public API.
But actually, internally, this should probably not be deprecated at all. It
should just be changed to be the holder of the binary serialization of
authentication tokens. I think there should only be one... we can add a
type parameter to AuthInfo to distinguish between different types if
necessary, as that is the most extensible. The token type does have to be
checked on the server side, though, to ensure that the server is configured
to accept that type of token.
Additionally, there's also the fact that making authentication pluggable,
means that some of our securityOperations no longer make sense. For
instance, the concept of a managed user within our API no longer makes
sense, because 1) not all authentication systems have a "create user" and
"drop user" concept, 2) not all those that do have "create user" and "drop
user" can do so with an authentication token, as an authentication token is
*not* the same thing as a user's credentials and should not be represented
as such in the API. So, I think these operations should be moved from the
current location (with deprecation), to authentication provider
implementations (login services?) that use them.
Below is how I would kind of like to see it work from an API perspective:
AuthToken rootUser passwordAuthenticationService.getToken(rootUserPrincipal, rootUserPassword);
passwordAuthenticationService.createUser(rootUser, "myUser", "myPassword");
AuthToken token = passwordAuthenticationService.getToken(myUserPrincipal,
password); // aka "log in"
AuthToken token = kerberosAuthenticationService.getToken(userPrincipal,
AuthToken token = mockAuthenticationService.getToken(); // returns a token
for a mock user principal
... internal serialization magic to convert AuthToken to thrift form
... rpc call, then deserialize back to AuthToken on server side ...
throws exception if token's type doesn't match the authentication service
or if user's token is expired or invalid
String userName = token.getPrincipal().getName();
Christopher L Tubbs II
On Mon, Jan 28, 2013 at 2:17 PM, Eric Newton <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 28, 2013 at 12:13 PM, John Vines <[EMAIL PROTECTED]> wrote:
> > I forgot, but agree that we should try to keep
> > thrift out of the client api. I'm refactoring it now to keep cruft of the
> > client end.
> > I can rename it to SecurityToken as part of the refactoring.
> > We need to keep the AuthInfo floating around for API compatibility. As
> > as I would love to kill them with fire, this kills api compatibility
> > between versions.
> Feel free to sprinkle warning suppression annotations
> > The security class is not specified by the remote caller, it's
> > from the configuration xml files. All the client does is provide a token
> > and it's up to the implementation to accept/reject it. I simply provided
> > mechanism for the client to get a hint as to what type of token is
> > expected.
> I beg to differ. Please see TokenHelper.fromBytes appears to be using
> deserialized information directly to load a class.
> > However, with the last
> > minute of the proxy, I'm afraid I do not have the time or knowledge of
> > proxy to get that support in for 1.5.
> Keith had an idea. I'll add a authenticate method that will return a
> token. The proxy methods will all take tokens.