directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SHAWN E SMITH <se...@psu.edu>
Subject Re: [Bulk] [Bulk] RBAC Constraints
Date Thu, 27 Aug 2015 18:35:04 GMT
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
View raw message