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 03:19:13 GMT
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 <clp207@psu.edu> 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 <smckinney@apache.org>
> To: fortress@directory.apache.org
> 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 <clp207@psu.edu> 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" <smckinney@apache.org>
>> To: fortress@directory.apache.org
>> 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 <clp207@psu.edu> 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" <smckinney@apache.org>
>>> To: fortress@directory.apache.org
>>> 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 <clp207@psu.edu> 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
> 
> 


Mime
View raw message