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 <[email protected]> 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" <[email protected]> > To: [email protected] > 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 <[email protected]> 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" <[email protected]> >> To: [email protected] >> 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 <[email protected]> wrote: >>> >>> >>>> On Apr 6, 2017, at 9:25 AM, Chris Pike <[email protected]> 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
