directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <smckin...@apache.org>
Subject Re: Auth Anon Roles
Date Fri, 07 Apr 2017 14:31:27 GMT
Couldn't you create two roles, one called ‘anonymous’ the other ‘authenticated’ and
then add the permissions as needed?  Why do you need separate roles for each permission?

But I agree, if you have dozens of roles, all having to be distinguished by authentication
status, the role validator approach wouldn’t work very well.

What I don’t get is using an RBAC system to activate roles that haven’t been assigned
to the user.  It’s a fundamental aspect of the standard.  

Another thought is you’re needing an attribute-based approach.  Perhaps our ‘poor man’s
abac’ facility to control permissions based on authN status could work.

Again, I don’t understand your req’s so I am really just shooting in the dark. 

Shawn

> On Apr 7, 2017, at 9:13 AM, Chris Pike <clp207@psu.edu> wrote:
> 
> We have 1000's of users that are constantly changing.
> 
> As an example, if I wanted to allow anyone to read a persons first and last name. I could
create a role with person.read.firstName and person.read.lastName and mark the role as give
anonymous. Any user who then logs into that app can read person first and last name.
> 
> If I want only authenticated users to read a users phone number, I could create a second
role that had person.read.phoneNumber and mark role as give authenticated. So if a an authenticated
user used the app, then they would see phone numbers. 
> 
> 
> 
> 
> ----- Original Message -----
> From: "Shawn McKinney" <smckinney@apache.org>
> To: fortress@directory.apache.org
> Sent: Friday, April 7, 2017 9:45:19 AM
> Subject: Re: Auth Anon Roles
> 
> Not knowing more about your app’s reqs I don’t understand why this role validator
approach won’t work.
> 
> Put more bluntly — why can’t you just assign the two roles to every user?
> 
> What I do know is this validator was created per your req’s — initially.  The ticket
explained the approach, and it was implemented per that description.
> 
> Shawn
> 
>> On Apr 7, 2017, at 5:59 AM, Chris Pike <clp207@psu.edu> wrote:
>> 
>> I can handle this in our service pretty easily.
>> 
>> 1. Add properties to roles (giveAnonymous, giveAuthenticated)
>> 2. In our endpoint that returns roles for a user, add those extra roles as appropriate
>> 
>> I will probably end up doing this for the time being. I think the same sort of thing
could be done in the fotress API, but not sure how that affects the RBAC standard.
>> 
>> 
>> 
>> ----- Original Message -----
>> From: "Shawn McKinney" <smckinney@apache.org>
>> To: fortress@directory.apache.org
>> Sent: Thursday, April 6, 2017 11:48:16 PM
>> Subject: Re: Auth Anon Roles
>> 
>> The javadoc describes usage of the authN validator:
>> 
>> http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/util/AuthNValidator.html
>> 
>> Again, the role still must be assigned.  But there is no need to set a property on
the role.  You would need to extend this class for each role that has constraint based on
their authentication status -- authenticated or not.
>> 
>>> On Apr 6, 2017, at 10:31 PM, Shawn McKinney <smckinney@apache.org> wrote:
>>> 
>>> 
>>>> On Apr 6, 2017, at 9:25 AM, Chris Pike <clp207@psu.edu> wrote:
>>>> 
>>>> Was looking back at this issue (https://issues.apache.org/jira/browse/FC-127)
and this conversation (http://mail-archives.apache.org/mod_mbox/directory-fortress/201512.mbox/browser).
>>> 
>>> As it turns out, FC-127 was implemented.  The validator is here:
>>> 
>>> https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/util/AuthNValidator.java
>>> 
>>> By reading the ticket it’s clear that we coded what I mentioned a few hours
ago.  So the good news is I’m consistent, the bad news (for me) is that I completely forgot
that this code had actually been implemented.  
>>> 
>>> :-)
>>> 
>>> Shawn


Mime
View raw message