directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Pike (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FC-116) Need the ability to get user specific attributes for fine grained access determinations
Date Wed, 21 Sep 2016 14:31:20 GMT

     [ https://issues.apache.org/jira/browse/FC-116?page=com.atlassian.jira.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 solution
> ----------------------- 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’s change the name to ‘ftAttributes’ because essential what we’re doing here
is a poor man’s 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 name, and fortress uses
reflexion to call it (passing the map and session) during the course of the authorization
check.  
> Let’s 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 application names
> ftCondition applicationA:conditionparameters
> The API could present it back as a Map>
> (The other) Shawn
> "The programmer … works only slightly removed from pure thought-stuff.
> He builds his castles in the air, from air, creating by exertion of the imagination."
> — 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 = x (or department = 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 to 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 … works only slightly removed from pure thought-stuff.
> He builds his castles in the air, from air, creating by exertion of the imagination."
> — 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 decision 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 maybe we can find an appropriate way to facilitate
into this api set / data model.
> 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
>  
>      On Wednesday, August 26, 2015 12:37 PM, SHAWN E SMITH psu.edu> wrote:
>   
>  Hey Arkanshawn,
> Hope all's well.  What we're looking at is the granularity of the permissions in the
context of standard EE security.  What we've come up with is:
> Role---------------Permission----------------Context
>   |                    |                        |
> Grouping            Specific                Specific
>   of              Permission              Context    
> Permissions        (i.e. -                  for a
>                     system-read)          given user
> And how that translates is that in the case of @RolesAllowed(X), X is actually 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 determine 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 individual and using
business logic in the app to interpret.  I think there might be 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:string: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 phone con about
the security one in the relatively near future?
> Take care,
> Shawn
> "The programmer … works only slightly removed from pure thought-stuff.
> He builds his castles in the air, from air, creating by exertion of the imagination."
> — 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 is for role activation
only - not permission checks.  It is worth discussing adding something like this.  It would
no be difficult.  It would require you 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 validator interface
but the validator compares a provided time against the constraint. 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, but 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> wrote:
> >>
> >>
> >> 1. Implement the org.apache.directory.fortress.core.util.timeValidator interface.
 The existing temporal evaluators all reside inside the same package. You may use one of those
as an example.
> >
> > correction:
> >
> > Implement the org.apache.directory.fortress.core.util.time.Validator interface.
> >
> > Shawn



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

Mime
View raw message