You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Edmon Begoli <eb...@gmail.com> on 2012/08/13 21:26:13 UTC

Role label grammar

Folks,

These are just some thoughts inspired by our discussion on user list
and the multi-level representation for labels.

What do you think if role labels could have embedded, interpretable,
simple micro-grammar structure
that if present could be used to augment the role label semantics with
additional meaning - e.g. place, time, relationship.

For example:

if regular label is followed by :

:read:4294967295 or  read:4294967295-4294967312

this would mean that this role label is effective between these timestamps.

We could further expand the grammar to include some of the simple and
easily verifiable conventions.

for instance label:

administrator@tn

could mean that this is a role of an administrator but effective only
for the state of Tennessee.

= could mean "is"

read=administrator@tn

Would indicate read privileges at the admin level at Tennessee.

--
Edmon

Re: Role label grammar

Posted by David Medinets <da...@gmail.com>.
+1 for a pluggable solution. Put the complex stuff in contrib.
On Aug 13, 2012 4:31 PM, "Adam Fuchs" <af...@apache.org> wrote:

> There are a couple of ways to interpret this suggestion. One is that the
> syntax and semantics of the cell-level label attached to each key syntax be
> augmented, and the other is that the user authorization sets be augmented
> to include these concepts, both in the storage and in the scanning API.
>
> With respect  to the former, I think that it complicates the grammar too
> much to add in range checking, and I'm not sure this is really what we want
> anyway. In the case of the time-windowed restriction for accessing an
> object, I would hypothesize that the bounds of the window are not
> necessarily calculable from only the object itself, but also require
> attributes of the user and policy. User attributes and policy can change
> independently of the object, so it makes sense to move that logic
> elsewhere.
>
> The other alternative interpretation that might fit the use case better is
> to give the user access to a particular authorization only for a particular
> time period. ACCUMULO-238 and ACCUMULO-259 would open up the ability to
> handle this type of thing at an external authorization-provider, rather
> than using the built-in, relatively static set of maximal authorizations
> that Accumulo supports out of the box. Also, it's not really necessary to
> extend the current authorization syntax, since we could just explicitly
> represent the time bounds in an extended API.
>
> Adam
>
>
>
> On Mon, Aug 13, 2012 at 3:26 PM, Edmon Begoli <eb...@gmail.com> wrote:
>
> > Folks,
> >
> > These are just some thoughts inspired by our discussion on user list
> > and the multi-level representation for labels.
> >
> > What do you think if role labels could have embedded, interpretable,
> > simple micro-grammar structure
> > that if present could be used to augment the role label semantics with
> > additional meaning - e.g. place, time, relationship.
> >
> > For example:
> >
> > if regular label is followed by :
> >
> > :read:4294967295 or  read:4294967295-4294967312
> >
> > this would mean that this role label is effective between these
> timestamps.
> >
> > We could further expand the grammar to include some of the simple and
> > easily verifiable conventions.
> >
> > for instance label:
> >
> > administrator@tn
> >
> > could mean that this is a role of an administrator but effective only
> > for the state of Tennessee.
> >
> > = could mean "is"
> >
> > read=administrator@tn
> >
> > Would indicate read privileges at the admin level at Tennessee.
> >
> > --
> > Edmon
> >
>

Re: Role label grammar

Posted by Adam Fuchs <af...@apache.org>.
There are a couple of ways to interpret this suggestion. One is that the
syntax and semantics of the cell-level label attached to each key syntax be
augmented, and the other is that the user authorization sets be augmented
to include these concepts, both in the storage and in the scanning API.

With respect  to the former, I think that it complicates the grammar too
much to add in range checking, and I'm not sure this is really what we want
anyway. In the case of the time-windowed restriction for accessing an
object, I would hypothesize that the bounds of the window are not
necessarily calculable from only the object itself, but also require
attributes of the user and policy. User attributes and policy can change
independently of the object, so it makes sense to move that logic elsewhere.

The other alternative interpretation that might fit the use case better is
to give the user access to a particular authorization only for a particular
time period. ACCUMULO-238 and ACCUMULO-259 would open up the ability to
handle this type of thing at an external authorization-provider, rather
than using the built-in, relatively static set of maximal authorizations
that Accumulo supports out of the box. Also, it's not really necessary to
extend the current authorization syntax, since we could just explicitly
represent the time bounds in an extended API.

Adam



On Mon, Aug 13, 2012 at 3:26 PM, Edmon Begoli <eb...@gmail.com> wrote:

> Folks,
>
> These are just some thoughts inspired by our discussion on user list
> and the multi-level representation for labels.
>
> What do you think if role labels could have embedded, interpretable,
> simple micro-grammar structure
> that if present could be used to augment the role label semantics with
> additional meaning - e.g. place, time, relationship.
>
> For example:
>
> if regular label is followed by :
>
> :read:4294967295 or  read:4294967295-4294967312
>
> this would mean that this role label is effective between these timestamps.
>
> We could further expand the grammar to include some of the simple and
> easily verifiable conventions.
>
> for instance label:
>
> administrator@tn
>
> could mean that this is a role of an administrator but effective only
> for the state of Tennessee.
>
> = could mean "is"
>
> read=administrator@tn
>
> Would indicate read privileges at the admin level at Tennessee.
>
> --
> Edmon
>