Correct, the user must be assigned the role for this to work. Can’t think of another way to do it right now, but open to ideas, assuming it doesn’t break rbac compliance.
> On Apr 6, 2017, at 10:04 PM, Chris Pike <[email protected]> wrote: > > So then how does this approach work? If I add a property to a role that > designates all authenticated users should have the role, the user won't be > directly assigned the role, so the validator won't be called, or am I missing > something? > > > > ----- Original Message ----- > From: Shawn McKinney <[email protected]> > To: [email protected] > Sent: Thu, 06 Apr 2017 21:08:35 -0400 (EDT) > Subject: Re: Auth Anon Roles > > Yes, the validator only works with assigned roles. This is standard RBAC — > only assigned roles may be activated into session. > >> On Apr 6, 2017, at 1:17 PM, Chris Pike <[email protected]> wrote: >> >> Thinking about this a little more... How does the validator work? Does it >> only fire for roles a user is currently assigned? >> >> >> ----- Original Message ----- >> From: "Shawn McKinney" <[email protected]> >> To: [email protected] >> Sent: Thursday, April 6, 2017 11:51:41 AM >> Subject: Re: Auth Anon Roles >> >> It’s generic functionality, thus broadly applicable, so I would be OK with >> it being added to the project, but disabled by default in the config. >> >> Shawn >> >>> On Apr 6, 2017, at 10:45 AM, Chris Pike <[email protected]> wrote: >>> >>> Yes, I think that makes sense. Would the new validator class be part of >>> fortress or just part of our project? >>> >>> >>> >>> ----- Original Message ----- >>> From: "Shawn McKinney" <[email protected]> >>> To: [email protected] >>> Sent: Thursday, April 6, 2017 11:11:52 AM >>> Subject: Re: Auth Anon Roles >>> >>> Hey Chris, >>> >>> Digging into this again, trying to figure out where we left off, here’s >>> where I ended up: >>> >>> 1. Add properties to roles that discriminate, e.g. anonymous = true / false >>> >>> 2. Add new validator class, per earlier description, that fires during the >>> role activation phase. This validator will either allow or deny roles to >>> be activated based on value of property on user-role assignment, and the >>> isTrusted flag contained within the session. >>> >>> 3. Enable the validation class >>> >>> Are we tracking right here? If so, we take advantage of already existent >>> property attribute on roles and create a new validator class. We’ll also >>> need to verify that the properties propagate to the user-role assignment. >>> If they don’t that will need to be changed as well. >>> >>> Shawn >>> >>>> On Apr 6, 2017, at 9:25 AM, Chris Pike <[email protected]> wrote: >>>> >>>> Shawn, >>>> >>>> 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). >>>> >>>> My goal was to be able to add check boxes to a role that allowed either >>>> all authenticated users and/or all anonymous users to have that role. Does >>>> the AuthN Valditor support this and if so how? >>>> >>>> Thanks! >>>> >>>> ~Chris > >
