Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of david.medinets@gmail.com
 designates 209.85.215.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPMpPc7ZPLkO0TFa7TbAqJOm7UrbEfZJ2MJi5FA3N+5JJrm1gg@mail.gmail.com>
References: 
 <CAGj+YsefUZBwA-NtiW7_QgkkTWkNgEPCc8zN0pDkcV+NHL4TQw@mail.gmail.com>
	<CAPMpPc7ZPLkO0TFa7TbAqJOm7UrbEfZJ2MJi5FA3N+5JJrm1gg@mail.gmail.com>
Date: Mon, 13 Aug 2012 19:34:39 -0400
Message-ID: 
 <CAOiJXP40jspPu6Q8oz-5eyC8gDvJjhYVghnEhv4RS5qYyNTrTQ@mail.gmail.com>
Subject: Re: Role label grammar
From: David Medinets <david.medinets@gmail.com>
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=14dae9d71976350c1e04c72e2320

--14dae9d71976350c1e04c72e2320
Content-Type: text/plain; charset=ISO-8859-1

+1 for a pluggable solution. Put the complex stuff in contrib.
On Aug 13, 2012 4:31 PM, "Adam Fuchs" <afuchs@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 <ebegoli@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
> >
>

--14dae9d71976350c1e04c72e2320--