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
