directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <smckin...@apache.org>
Subject Re: [Bulk] [Bulk] RBAC Constraints
Date Fri, 28 Aug 2015 17:05:37 GMT
Yes, this will get the ball rolling.
 


     On Thursday, August 27, 2015 11:35 AM, SHAWN E SMITH <ses44@psu.edu> wrote:
   

 Ticket submitted.  I just captured the email discussion, hopefully that's sufficient.

"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: Thursday, August 27, 2015 1:47:07 PM
Subject: Re: [Bulk] [Bulk] RBAC Constraints

> On Aug 27, 2015, at 6:47 AM, SHAWN E SMITH <ses44@psu.edu> wrote:
> 
> 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

  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message