accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1028) Distinguish the user principal from the authentication token
Date Sun, 03 Feb 2013 21:12:12 GMT


Christopher Tubbs commented on ACCUMULO-1028:

I see. Certainly, (String, byte[]) would be least intrusive to the public API, and (Principal,
byte[]) minimally more so.

However, why should it take the already serialized token? That could complicate user code,
because then they have to serialize the token (or rely on the system that provides the token
to do it)... for *our* RPC calls. That doesn't make sense to me. We don't necessary need a
serialized token... we just need to know how to serialize it, and the implementing class can
define that so we don't have to.

You said above that there's no need for them to follow a strict serialization/deserialization
interface, but you're imposing one anyway (it's unavoidable), essentially "convertToBytes()
and convertFromBytes()". Don't get me wrong... I've no problem with byte[] as the result of
that imposition (in fact, I think it's necessary for ACCUMULO-1027)... I just don't like seeing
arbitrary byte arrays in the public API... I'd rather do it behind the scenes... because a
byte array could be anything, and you lose all compile time checks, and I don't think this
is user-friendly for an API. We're developing in a high level language, and we can do better
than expressing objects as non-expressive byte arrays in our API.

You're right about the generics. It doesn't need to be a generic method. The reason why a
generic method is because (I think) it's easier to express to the user what the method is
expecting, but it could just as easily have been:
public Connector getConnector(Principal userPrincipal, AuthToken authToken);
They both achieve the same thing. (Unless we wanted to return a Connector<T> to support
things like Connectors that automatically renew tokens that expire, or provide other token
manipulation methods, like those in SecurityOperations, in which case, it would be better
to have the generics. I'm not suggesting we do that, but the current implementation of ACCUMULO-259,
without addressing ACCUMULO-1024 would benefit from it if the generic parameter is passed
down to the Connector's SecurityOperations, so users can get compile-time checks against using
inconsistent token types in the API).

(Note also that I'm using "AuthToken" rather than "SecurityToken", because I think it better
expresses its role, because "security" could mean anything.)
> Distinguish the user principal from the authentication token
> ------------------------------------------------------------
>                 Key: ACCUMULO-1028
>                 URL:
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: master, tserver
>            Reporter: Christopher Tubbs
>            Assignee: John Vines
>             Fix For: 1.5.0
> The user principal is something that uniquely identifies a user. An authentication token
is the item that authenticates the user principal, may be temporal, and may vary. It is not
clear from the implementation of ACCUMULO-259 that these are separate things, and I think
it would benefit the API to distinguish them.
> It could also simplify the API, for users transitioning from the old authentication stuff
to the new authentication stuff, because there would be a one-to-one mapping with the username/password
with which they are familiar:
> {code:java}
> public Connector getConnector(String username, byte[] password);
> {code}
> becomes
> {code:java}
> public <T extends AuthToken> Connector getConnector(Principal userPrincipal, T
> {code}

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message