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" //OR AuthToken token = kerberosAuthenticationService.getToken(userPrincipal, ???); //OR AuthToken token = mockAuthenticationService.getToken(); // returns a token for a mock user principal ... internal serialization magic to convert AuthToken to thrift form AuthInfo ... ... rpc call, then deserialize back to AuthToken on server side ... serverConfiguration.getAuthenticationService().authenticate(token); // 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 http://gravatar.com/ctubbsii On Mon, Jan 28, 2013 at 2:17 PM, Eric Newton <[email protected]> wrote: > Inline > > > 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. > > > > Thanks. > > > > I can rename it to SecurityToken as part of the refactoring. > > > > Great. > > > > We need to keep the AuthInfo floating around for API compatibility. As > much > > 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 > instantiated > > 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 > a > > 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 > the > > 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. > > -Eric >
