directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <smckin...@apache.org>
Subject Re: [Apache Fortress] [FC-144] Questions on implementation of Role-to-Group relationship
Date Wed, 17 Aug 2016 17:26:11 GMT

> 
> On Aug 17, 2016, at 11:15 AM, Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> wrote:
> 
> Hi all,
> I have recently started working on performing an integration between
> Openstack Keystone and Fortress Core. Specifically, this improvement:
> https://issues.apache.org/jira/browse/FC-144
> 

Hello Vyacheslav, welcome!

> 
> On Aug 17, 2016, at 11:15 AM, Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> wrote:
> 
> I am trying to figure out what would be the best way to create and manage
> Group-to-Role relationship without major modifications of existing source
> code.
> The source code inspection gave me the list of following questions.
> 
> 1. There's a UserRole class, which is used to represent a relationship
> between userId and name of the role assigned to this user. The list of such
> UserRole entities is used inside User entity and as method argument for
> many other entities like SDUtil, UserDAO etc.
>        Q1. Should I create a similar GroupRole class and override existing
> methods in auxiliary/utility classes like SDUtil? Or would it be a better
> solution to introduce a boolean switch inside UserRole class and rename
> userId field to memberId?

I was thinking about a much easier way.  There is already a group object in fortress:
https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/model/Group.java

along with corresponding classes like GroupMgr, GroupDao, etc…

Currently this group maps to users, we extend it to map to roles as well.  That is saying
the memberof would be the dn of the role object, not of the user.

> 
> On Aug 17, 2016, at 11:15 AM, Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> wrote:
> 
> 2. Currently Session entity only assumes User and UserRoles. The same set
> of classes is used to test permissions inside checkAccess(Session,
> Permission). Also, during the Session creation, a User should exist in
> USERS pool, even when Session is trusted.
>        Q2. Should I create a boolean switch distinguishing between Group
> and User in Session object and modify methods like Session.getRoles()
> return list of UserRoles or GroupRoles based on the switch value?

Again I am thinking of a simpler path.  We discussed adding the following method:

Session createSession (Group group, boolean isTrusted);

So instead of passing in a userid, we pass a group name.  The session maybe needs a new element,
groupName, or maybe we just add a boolean field, isGroup, and use the userId to contain the
groupName instead.  Either way the method will determine which roles to activate, populating
userroles, and return just as before.  Subsequent calls to checkAccess or sessionRoles (for
example) shouldn’t have to change.

> 
> On Aug 17, 2016, at 11:15 AM, Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> wrote:
> 
>        Q3. In case of groups, Session is trusted and there's no password. What
> would be the correct behavior for Session creation in this case? Just to
> check the group with required name exists in GROUPS pool?

yes check the group exists, determine which roles it maps to, and activate the userroles as
before.  Now that I think more, the userroles may need boolean isGroup field, in addition
to session, so that it is clear the value in userid field maps to group name.

> 
> On Aug 17, 2016, at 11:15 AM, Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> wrote:
> 
> 3. LDAP schema modifications. I assume that I will need to add attributes
> similar to "ftRA" and "ftRC" to Group object class. I will also need an
> attribute like "roleOccupant" in Role object class.
>        Q4. Should I reuse existing attributes with or create a set of new
> attrs intented to be used specifically for Groups? Like "ftGRA", "gtGRC"?

I don’t think we have to modify the ldap schema at all.  The current group object class
should work.  Again it will contains role dn’s instead of user dn’s.  The only question
in my mind is should we add a new container, i.e. ou=rolegroups.  I am leaning towards ‘yes’.

> 
> On Aug 17, 2016, at 11:15 AM, Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> wrote:
> 
>        Q5. Should I create "groupRoleOccupant" attribute in Role object
> class? It seems that I can't reuse the existing one to store Groups having
> this Role assigned.

No, the role will not change.  The group will point to role, not vice versa.

> 
> On Aug 17, 2016, at 11:15 AM, Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> wrote:
> 
> 4. Utility classes modifications. It seems that almost all utility classes
> that work with User and Role objects (SDUtil, RoleUtil etc.) accept
> UserRole as argument.
>        Q6. I assume that I'll need to overload methods in these classes to
> accept GroupRole. Is it correct or is there another way?

I don’t think we need to change any of the util classes very much.  That is we’ll need
to pass the group object around during session creation and that may require overloading a
couple of methods.

> 
> On Aug 17, 2016, at 11:15 AM, Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> wrote:
> 
> 5. Delegated Admin functionality.
>        Q7. Do we need to modify this in case we introduce Role for Groups?
> 

It depends, do we need a canAssign ( group , role ) or canDeassign?  If so it would require
changes to group entity to allow for organization ownership.

> 
> As you see, I have a lot of questions and I would appreciate getting some
> development guidelines and best practices. Actually, any advises are
> greatly appreciated.
> Thank you in advance!
> 
> -- 
> Kind Regards,
> Vyacheslav Vakhlyuev

You will want to get comfortable running the junit tests.  Any new methods will need tests
to verify their functionality.  Will mirantis be contributing this code?



Mime
View raw message