Yes, this will get the ball rolling.
On Thursday, August 27, 2015 11:35 AM, SHAWN E SMITH <[email protected]> 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
[email protected]
----- Original Message -----
From: "Shawn McKinney" <[email protected]>
To: [email protected]
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 <[email protected]> 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
