[jira] [Commented] (FC-75) Add Role grouping mechanism

[Shawn McKinney (JIRA)]

[ 
https://issues.apache.org/jira/browse/FC-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283690#comment-15283690
 ] 

Shawn McKinney commented on FC-75:
--

Use existing GroupMgr and group entity functionality.  Extend with a type 
attribute.  This will allow user and role groups to exist simultaneously under 
the same tree.

> Add Role grouping mechanism
> ---
>
> Key: FC-75
> URL: https://issues.apache.org/jira/browse/FC-75
> Project: FORTRESS
>  Issue Type: Improvement
>Affects Versions: 1.0.0-RC39
>Reporter: Shawn McKinney
>Assignee: Shawn McKinney
> Fix For: 1.0.1
>
>
> Ansi rbac allows groups of roles.  An rbac group map to a collection of roles:
> Rbac group one to many relationship with role.
> This will help with administration to simplify the task of assigning multiple 
> roles to a single user.  
> It is worth noting that role hierarchies are a similar concept in that they 
> too are a collection of roles - with one key difference.  If one wanted to 
> assign a collection of roles to a user where two or more have dynamic 
> separation of duty constraints, having those roles related via a hierarchy 
> prevents selective activation into session.
> With a group of roles assigned, it is possible for the user or system itself 
> to choose which of the assigned roles to activate into a given session.  
> from the ansi incits 369 2004:
> "CreateSession(user, session)
> This function creates a new session with a given user as owner, and a given 
> set of active roles. The function is valid if and only if:
> - the user is a member of the USERS data set, and
> - the active role set is a subset of the roles authorized for that user. Note 
> that if a role is
> active for a session, its descendants or ascendants are not necessarily 
> active for that session. In a RBAC implementation, the session’s active roles 
> might actually be the groups that represent those roles."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (FC-75) Add Role grouping mechanism

[Shawn McKinney (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FC-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shawn McKinney reassigned FC-75:


Assignee: Shawn McKinney

> Add Role grouping mechanism
> ---
>
> Key: FC-75
> URL: https://issues.apache.org/jira/browse/FC-75
> Project: FORTRESS
>  Issue Type: Improvement
>Affects Versions: 1.0.0-RC39
>Reporter: Shawn McKinney
>Assignee: Shawn McKinney
> Fix For: 1.0.1
>
>
> Ansi rbac allows groups of roles.  An rbac group map to a collection of roles:
> Rbac group one to many relationship with role.
> This will help with administration to simplify the task of assigning multiple 
> roles to a single user.  
> It is worth noting that role hierarchies are a similar concept in that they 
> too are a collection of roles - with one key difference.  If one wanted to 
> assign a collection of roles to a user where two or more have dynamic 
> separation of duty constraints, having those roles related via a hierarchy 
> prevents selective activation into session.
> With a group of roles assigned, it is possible for the user or system itself 
> to choose which of the assigned roles to activate into a given session.  
> from the ansi incits 369 2004:
> "CreateSession(user, session)
> This function creates a new session with a given user as owner, and a given 
> set of active roles. The function is valid if and only if:
> - the user is a member of the USERS data set, and
> - the active role set is a subset of the roles authorized for that user. Note 
> that if a role is
> active for a session, its descendants or ascendants are not necessarily 
> active for that session. In a RBAC implementation, the session’s active roles 
> might actually be the groups that represent those roles."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: Scim library contribution

[Zheng, Kai]

Yeah, before it becomes a TLP, there should be something to be done and happen. 
One thing is, have a separate web site. I discussed about this with an Apache 
officer and was told it was doable. There can be found quite a few examples, 
sub project can have standalone web site.

To evolve, we shouldn't keep all things together, to make the parent web site 
crowded and crowded.

Glad to have a new component from PSU!

Regards,
Kai

-Original Message-
From: Shawn McKinney [mailto:smckin...@apache.org] 
Sent: Saturday, May 14, 2016 7:16 AM
To: Apache Directory Developers List 
Subject: Re: Scim library contribution


> On May 13, 2016, at 3:40 PM, Emmanuel Lécharny  wrote:
> 
> The rational here is to make sure that we have some common interest in 
> having those projects and the associated people working hand in hand, 
> to create a strong community.

It has been immensely valuable to have the guidance of this project committee.  
It brings extra eyes to our code and processes.

> 
> On May 13, 2016, at 3:40 PM, Emmanuel Lécharny  wrote:
> 
> Fortress was also benefiting from ApacheDS, as all the unit tests are 
> based on it. Now that a 1.0 is out, we can also think about making it 
> a TLP. That would be up to Shawn and Chris to see when it would make 
> sense, but the community around it is small atm.

Agreed.  The community must grow before TLP status makes sense.  Otherwise I 
guess you’re stuck with us cause we’re not giving up anytime soon.   ;-)

Shawn

Re: Scim library contribution

[Shawn McKinney]

> On May 13, 2016, at 3:40 PM, Emmanuel Lécharny  wrote:
> 
> The rational here is to make sure that we have some common interest in
> having those projects and the associated people working hand in hand, to
> create a strong community.

It has been immensely valuable to have the guidance of this project committee.  
It brings extra eyes to our code and processes.

> 
> On May 13, 2016, at 3:40 PM, Emmanuel Lécharny  wrote:
> 
> Fortress was also benefiting from ApacheDS, as all the unit tests are
> based on it. Now that a 1.0 is out, we can also think about making it a
> TLP. That would be up to Shawn and Chris to see when it would make
> sense, but the community around it is small atm.

Agreed.  The community must grow before TLP status makes sense.  Otherwise I 
guess you’re stuck with us cause we’re not giving up anytime soon.   ;-)

Shawn