(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 <[email protected]>
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
[email protected]
----- Original Message -----
From: "Shawn McKinney" <[email protected]>
To: [email protected]
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 <[email protected]> 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" <[email protected]>
> To: [email protected]
> Sent: Monday, August 24, 2015 11:17:18 AM
> Subject: Re: [Bulk] RBAC Constraints
>
>> On Aug 24, 2015, at 8:14 AM, Shawn McKinney <[email protected]> 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
