[ 
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
> se...@psu.edu
> ----- Original Message -----
> From: "SHAWN E SMITH" psu.edu>
> To: fortr...@directory.apache.org, "Shawn McKinney" <smckin...@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
> se...@psu.edu
> ----- Original Message -----
> From: "Shawn McKinney" <smckin...@apache.org>
> To: fortr...@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
> se...@psu.edu
> ----- Original Message -----
> From: "Shawn McKinney" <smckin...@apache.org>
> To: fortr...@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" <smckin...@apache.org>
> > To: fortr...@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 <smckin...@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)

Reply via email to