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
