Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Date: Wed, 21 Sep 2016 14:31:20 +0000 (UTC)
From: "Chris Pike (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Message-ID: <JIRA.12859689.1440700010000.627502.1474468280540@Atlassian.JIRA>
In-Reply-To: <JIRA.12859689.1440700010000@Atlassian.JIRA>
References: <JIRA.12859689.1440700010000@Atlassian.JIRA> <JIRA.12859689.1440700010060@arcas>
Subject: [jira] [Updated] (FC-116) Need the ability to get user specific
 attributes for fine grained access determinations
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Wed, 21 Sep 2016 14:31:23 -0000


     [ https://issues.apache.org/jira/browse/FC-116?page=3Dcom.atlassian.ji=
ra.plugin.system.issuetabpanels:all-tabpanel ]

Chris Pike updated FC-116:
--------------------------
    Attachment: RoleConstraints.png

Permission Attribute Additions to RBAC Model

> Need the ability to get user specific attributes for fine grained access =
determinations
> -------------------------------------------------------------------------=
--------------
>
>                 Key: FC-116
>                 URL: https://issues.apache.org/jira/browse/FC-116
>             Project: FORTRESS
>          Issue Type: Improvement
>            Reporter: Shawn Eion Smith
>         Attachments: RoleConstraints.png
>
>
> Below is the email chain that discusses the problem and suggested solutio=
n
> ----------------------- Final Suggestion --------------------------------=
-------------------
> > Can I recommend we do something like
> >
> > ftCondition
> >
> > with the keys being non-unique values that represent groupings, such as=
 application names
> >
> > ftCondition applicationA:conditionparameters
> >
> > The API could present it back as a Map>
> Let=E2=80=99s change the name to =E2=80=98ftAttributes=E2=80=99 because e=
ssential what we=E2=80=99re doing here is a poor man=E2=80=99s ABAC.  Agree=
 that a map is the way to go.  That way it is up to the client to interpret=
.  Eventually we can add a callback interface to checkAccess that triggers =
on a flag in the permission itself.  The permission points to the class nam=
e, and fortress uses reflexion to call it (passing the map and session) dur=
ing the course of the authorization check. =20
> Let=E2=80=99s start with opening a ticket, and we can go from there.
> Thanks,
> Shawn
> ---------------------------  Full Discussion ----------------------------=
-------------------
> Can I recommend we do something like
> ftCondition
> with the keys being non-unique values that represent groupings, such as a=
pplication names
> ftCondition applicationA:conditionparameters
> The API could present it back as a Map>
> (The other) Shawn
> "The programmer =E2=80=A6 works only slightly removed from pure thought-s=
tuff.
> He builds his castles in the air, from air, creating by exertion of the i=
magination."
> =E2=80=94 Fred Brooks
> Shawn Smith
> Director of Software Engineering
> Administrative Information Services
> 814-321-5227
> ses44@psu.edu
> ----- Original Message -----
> From: "SHAWN E SMITH" psu.edu>
> To: fortress@directory.apache.org, "Shawn McKinney" <smckinney@apache.org=
>
> Sent: Thursday, August 27, 2015 9:07:42 AM
> Subject: Re: [Bulk] [Bulk] RBAC Constraints
> As a simple (or maybe overly simple) use case imagine a application that =
can lock accounts.  You only want folks to be able to lock accounts within =
their own department so you get
> Role           Permission         Context
> Security         Lock            department =3D x (or department =3D x ||=
 y)
> The permission refers to the method, the context refers to the individual=
.
> It can start to get a little challenging when you allow more complexity t=
o the context like
> (context1 && context2) || context3
> I'll try to find a better word than context, that one's just stuck in my =
vernacular for now.
> Shawn
> "The programmer =E2=80=A6 works only slightly removed from pure thought-s=
tuff.
> He builds his castles in the air, from air, creating by exertion of the i=
magination."
> =E2=80=94 Fred Brooks
> Shawn Smith
> Director of Software Engineering
> Administrative Information Services
> 814-321-5227
> ses44@psu.edu
> ----- Original Message -----
> From: "Shawn McKinney" <smckinney@apache.org>
> To: fortress@directory.apache.org
> Sent: Wednesday, August 26, 2015 9:47:50 PM
> Subject: Re: [Bulk] [Bulk] RBAC Constraints
> (The other) Shawn,
> I think your idea to add additional attributes into the authorization dec=
ision has merit.  ftcontextid is reserved for multitenancy (i.e. tenant id)=
, but ftproperties is fine.  I'd like to see some use cases for this and ma=
ybe we can find an appropriate way to facilitate into this api set / data m=
odel.
> I saw your talks were accepted - congrats on that btw.  I am out of town =
this week but could hop on conf call next week to discuss.
> Arkanshawn
> =20
>      On Wednesday, August 26, 2015 12:37 PM, SHAWN E SMITH psu.edu> wrote=
:
>  =20
>  Hey Arkanshawn,
> Hope all's well.  What we're looking at is the granularity of the permiss=
ions in the context of standard EE security.  What we've come up with is:
> Role---------------Permission----------------Context
>   |                    |                        |
> Grouping            Specific                Specific
>   of              Permission              Context   =20
> Permissions        (i.e. -                  for a
>                     system-read)          given user
> And how that translates is that in the case of @RolesAllowed(X), X is act=
ually a permission, and the context is used inside the method to determine =
how to slice the data if necessary.
> Context we've broken into 3 pieces, Meta (this is the flag used to determ=
ine what to slice on), Type (this is the type of the meta field), Value(s)/=
Range (This is the valid matching attributes)
> We're looking at putting the context into an ftProp value on the individu=
al and using business logic in the app to interpret.  I think there might b=
e value in using something like ftContext, but wanted to see if we can get =
the communities take on it.
> So, what we'd end up with is something similar to systemX-read:userid:str=
ing:self in the property.
> Would very much appreciate any thoughts on this approach.
> BTW - we got selected for both talks at JavaONE, maybe we can have a phon=
e con about the security one in the relatively near future?
> Take care,
> Shawn
> "The programmer =E2=80=A6 works only slightly removed from pure thought-s=
tuff.
> He builds his castles in the air, from air, creating by exertion of the i=
magination."
> =E2=80=94 Fred Brooks
> Shawn Smith
> Director of Software Engineering
> Administrative Information Services
> 814-321-5227
> ses44@psu.edu
> ----- Original Message -----
> From: "Shawn McKinney" <smckinney@apache.org>
> To: fortress@directory.apache.org
> Sent: Monday, August 24, 2015 11:41:37 PM
> Subject: Re: [Bulk] [Bulk] RBAC Constraints
> Today there is no way to do it.  The existing constraint mechanism here i=
s for role activation only - not permission checks.  It is worth discussing=
 adding something like this.  It would no be difficult.  It would require y=
ou to implement a callback interface.  Would something like that work?
> Shawn
> > On Aug 24, 2015, at 9:59 AM, Chris Pike psu.edu> wrote:
> >
> > Shawn,
> >
> > Thanks for the quick response. I was able to implement the time validat=
or interface but the validator compares a provided time against the constra=
int. I need to compare my arbitrary input against the constraint. I should =
be able to store the constraint info and look it up inside the validator, b=
ut how can I pass my arbitrary input to check access?
> >
> > ~Chris Pike
> >
> > ----- Original Message -----
> > From: "Shawn McKinney" <smckinney@apache.org>
> > To: fortress@directory.apache.org
> > Sent: Monday, August 24, 2015 11:17:18 AM
> > Subject: Re: [Bulk] RBAC Constraints
> >
> >> On Aug 24, 2015, at 8:14 AM, Shawn McKinney <smckinney@apache.org> wro=
te:
> >>
> >>
> >> 1. Implement the org.apache.directory.fortress.core.util.timeValidator=
 interface.  The existing temporal evaluators all reside inside the same pa=
ckage. You may use one of those as an example.
> >
> > correction:
> >
> > Implement the org.apache.directory.fortress.core.util.time.Validator in=
terface.
> >
> > Shawn


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)