Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.1
    • Fix Version/s: 2.0.0-RC1
    • Labels:
      None

      Description

      We are currently working on performing an integration between Openstack Keystone and Fortress Core. We will use Fortress as the authorization backend for the rest of Openstack. We have managed to map most of the current functionality in Openstack within the Fortress schema except for the ability to assign roles to a group.

      I've spoken with Shawn McKinney, and he determined this improvement is a feasible addition to Fortress's feature set. After a number of back and forths, we have come up with the following requirements as API additions:

      • Session createSession (Group group, boolean isTrusted);
      • void assignGroup ( Group group, Role role );
      • List<Group> roleGroups ( Role role );
      • List<Role> groupRoles ( Group group );
      • the ability to use the above session with checkAccess(Session session, Permission perm)

      We also discussed temporal constrains for group to role assignment. Temporal constrains will not be utilized as this functionality has not been defined in Openstack.

        Issue Links

        There are no Sub-Tasks for this issue.

          Activity

          Hide
          smckinney Shawn McKinney added a comment -

          The use case here is federated and multi-tenant login into openstack via keystone.

          1. User authenticated in keystone
          2. User performs op for a specific tenant.
          3. OpenStack Keystone activates a Group for the User, for that particular op.
          4. That Group is mapped to a Role(s) inside the tenant's domain.
          5. The Role(s) are activated into RBAC Session.
          6. Session is 'trusted' because the authN happened earlier.
          7. Session is anonymous (the userId is unknown to the tenant).
          8. Session used in checkAccess method for authZ inside tenant domain.

          wrt the physical data structures:

          • Add a multi-occurring Role membership attribute to the Group object class. This allows each Group to have many roles. It would also support a single Role being associated with many Groups. The cardinality is many-to-many.
          • This physical data format makes the Group->Role interrogation efficient, requiring just a single 'read' of an object.
          Show
          smckinney Shawn McKinney added a comment - The use case here is federated and multi-tenant login into openstack via keystone. 1. User authenticated in keystone 2. User performs op for a specific tenant. 3. OpenStack Keystone activates a Group for the User, for that particular op. 4. That Group is mapped to a Role(s) inside the tenant's domain. 5. The Role(s) are activated into RBAC Session. 6. Session is 'trusted' because the authN happened earlier. 7. Session is anonymous (the userId is unknown to the tenant). 8. Session used in checkAccess method for authZ inside tenant domain. wrt the physical data structures: Add a multi-occurring Role membership attribute to the Group object class. This allows each Group to have many roles. It would also support a single Role being associated with many Groups. The cardinality is many-to-many. This physical data format makes the Group->Role interrogation efficient, requiring just a single 'read' of an object.
          Hide
          ktychkova Kseniya Tychkova added a comment -

          We have time and desire to implement this feature
          Shawn, could you please confirm that described steps are still valid?
          Apache Fortress has an "OrganizationalUnit" entity now. Maybe it makes more sense to extend OrganizationalUnit class?

          Show
          ktychkova Kseniya Tychkova added a comment - We have time and desire to implement this feature Shawn, could you please confirm that described steps are still valid? Apache Fortress has an "OrganizationalUnit" entity now. Maybe it makes more sense to extend OrganizationalUnit class?
          Hide
          smckinney Shawn McKinney added a comment -

          Kseniya,

          Would it be possible that this API works as well?

          Session createSession (Role role);

          The assumption being made here is that it is actually a role being passed down and not a group. This role could then be part of a role hierachy which inherits from other roles.

          Show
          smckinney Shawn McKinney added a comment - Kseniya, Would it be possible that this API works as well? Session createSession (Role role); The assumption being made here is that it is actually a role being passed down and not a group. This role could then be part of a role hierachy which inherits from other roles.
          Hide
          ktychkova Kseniya Tychkova added a comment -

          Shawn, unfortunately there is no way to map Keystone groups to Fortress roles right now.
          Possible solution is to create in Keystone roles backend for Fortress REST. It can be done.
          But what about roles for group or orgUnit?
          Is it break an architecture or requires a lot of code?

          Show
          ktychkova Kseniya Tychkova added a comment - Shawn, unfortunately there is no way to map Keystone groups to Fortress roles right now. Possible solution is to create in Keystone roles backend for Fortress REST. It can be done. But what about roles for group or orgUnit? Is it break an architecture or requires a lot of code?
          Hide
          smckinney Shawn McKinney added a comment -

          OK, for some reason I thought there might be a mapping there. Of the other two options, group to role makes the most sense. Not breaking or violating anything, but it is another relationship to manage. Nothing difficult, just work. Seems like I estimated this some time back to be 1 - 4 weeks of work to get all of the components updated, new test cases written, released, etc...

          The wildcard here is the openldap accelerator which isn't part of the apache directory project and would have to be handled separately.

          Show
          smckinney Shawn McKinney added a comment - OK, for some reason I thought there might be a mapping there. Of the other two options, group to role makes the most sense. Not breaking or violating anything, but it is another relationship to manage. Nothing difficult, just work. Seems like I estimated this some time back to be 1 - 4 weeks of work to get all of the components updated, new test cases written, released, etc... The wildcard here is the openldap accelerator which isn't part of the apache directory project and would have to be handled separately.
          Hide
          ktychkova Kseniya Tychkova added a comment -

          Thank you, Shawn.
          We are going to work on it then.
          But also we will take a look what we can do on OpenStack side.

          Show
          ktychkova Kseniya Tychkova added a comment - Thank you, Shawn. We are going to work on it then. But also we will take a look what we can do on OpenStack side.
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user vvakhlyuev-work opened a pull request:

          https://github.com/apache/directory-fortress-core/pull/6

          FC-144/assign roles for groups

          There're certain situations where userId is not known to the tenant.
          Possible use case here is federated and multi-tenant login into
          openstack via keystone. This commit allows to create a Session with
          Group, map the Group to a Role(s) inside the tenant's domain and
          check Session' Permissions.

          Resolves FC-144(https://issues.apache.org/jira/browse/FC-144)

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/vvakhlyuev-work/directory-fortress-core FC-144/assign-roles-for-groups

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/directory-fortress-core/pull/6.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #6


          commit 098f0a37b69be2cf76fa8d6e23ef3d250ccf58fc
          Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com>
          Date: 2016-08-28T18:45:13Z

          FC-144 Use Groups of Roles to create Sessions

          There're certain situations where userId is not known to the tenant.
          Possible use case here is federated and multi-tenant login into
          openstack via keystone. This commit allows to create a Session with
          Group, map the Group to a Role(s) inside the tenant's domain and
          check Session' Permissions.

          There's still more work to do:

          • REST Implementation of managers
          • Add new unit-tests
          • Update Console managers with new functionality

          commit 252e6116933c7d37d53159c304fdb1e309a97aa1
          Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com>
          Date: 2016-09-23T14:17:38Z

          FC-144 Use Groups of Roles to create Sessions

          • Modified GroupMgr to support SSD and DSD constraints for roles assignment
          • Added tests for new GroupMgr methods
          • Updated info needed by EnMasse project (HttpIds etc.)

          Show
          githubbot ASF GitHub Bot added a comment - GitHub user vvakhlyuev-work opened a pull request: https://github.com/apache/directory-fortress-core/pull/6 FC-144 /assign roles for groups There're certain situations where userId is not known to the tenant. Possible use case here is federated and multi-tenant login into openstack via keystone. This commit allows to create a Session with Group, map the Group to a Role(s) inside the tenant's domain and check Session' Permissions. Resolves FC-144 ( https://issues.apache.org/jira/browse/FC-144 ) You can merge this pull request into a Git repository by running: $ git pull https://github.com/vvakhlyuev-work/directory-fortress-core FC-144 /assign-roles-for-groups Alternatively you can review and apply these changes as the patch at: https://github.com/apache/directory-fortress-core/pull/6.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #6 commit 098f0a37b69be2cf76fa8d6e23ef3d250ccf58fc Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> Date: 2016-08-28T18:45:13Z FC-144 Use Groups of Roles to create Sessions There're certain situations where userId is not known to the tenant. Possible use case here is federated and multi-tenant login into openstack via keystone. This commit allows to create a Session with Group, map the Group to a Role(s) inside the tenant's domain and check Session' Permissions. There's still more work to do: REST Implementation of managers Add new unit-tests Update Console managers with new functionality commit 252e6116933c7d37d53159c304fdb1e309a97aa1 Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> Date: 2016-09-23T14:17:38Z FC-144 Use Groups of Roles to create Sessions Modified GroupMgr to support SSD and DSD constraints for roles assignment Added tests for new GroupMgr methods Updated info needed by EnMasse project (HttpIds etc.)
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user vvakhlyuev-work opened a pull request:

          https://github.com/apache/directory-fortress-enmasse/pull/1

          Fc 144/assign roles for groups

          There're certain situations where userId is not known to the tenant.
          Possible use case here is federated and multi-tenant login into
          openstack via keystone. This commit propagates changes from
          Fortress Core project to achieve this and adds new API methods.

          Resolves FC-144(https://issues.apache.org/jira/browse/FC-144)

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/vvakhlyuev-work/directory-fortress-enmasse FC-144/assign-roles-for-groups

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/directory-fortress-enmasse/pull/1.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #1


          commit a85704b7f5d8e88fb24529e81866416ab2ab9061
          Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com>
          Date: 2016-09-08T17:18:27Z

          FC-144 Use Groups of Roles to create Sessions

          There're certain situations where userId is not known to the tenant.
          Possible use case here is federated and multi-tenant login into
          openstack via keystone. This commit propagates changes from
          Fortress Core project to achieve this and adds new API methods.

          commit 817842a6c27a82781d5472890d19d3d93057cc06
          Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com>
          Date: 2016-09-08T17:23:16Z

          FC-144 Use Groups of Roles to create Sessions

          Updated tests

          commit cdcc4e4d751ffd229dace34a8180b442261f6d35
          Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com>
          Date: 2016-09-14T17:32:38Z

          FC-144 Use Groups of Roles to create Sessions

          Added GroupMgrImpl assign/deassign role methods, modified existing
          methods to map to core manager's one

          commit 3eb9754290ced641b9a303b356cd6031165a02cc
          Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com>
          Date: 2016-09-23T14:19:30Z

          FC-144 Use Groups of Roles to create Sessions

          • Updated core AccessMgr method signature (renamed)

          Show
          githubbot ASF GitHub Bot added a comment - GitHub user vvakhlyuev-work opened a pull request: https://github.com/apache/directory-fortress-enmasse/pull/1 Fc 144/assign roles for groups There're certain situations where userId is not known to the tenant. Possible use case here is federated and multi-tenant login into openstack via keystone. This commit propagates changes from Fortress Core project to achieve this and adds new API methods. Resolves FC-144 ( https://issues.apache.org/jira/browse/FC-144 ) You can merge this pull request into a Git repository by running: $ git pull https://github.com/vvakhlyuev-work/directory-fortress-enmasse FC-144 /assign-roles-for-groups Alternatively you can review and apply these changes as the patch at: https://github.com/apache/directory-fortress-enmasse/pull/1.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1 commit a85704b7f5d8e88fb24529e81866416ab2ab9061 Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> Date: 2016-09-08T17:18:27Z FC-144 Use Groups of Roles to create Sessions There're certain situations where userId is not known to the tenant. Possible use case here is federated and multi-tenant login into openstack via keystone. This commit propagates changes from Fortress Core project to achieve this and adds new API methods. commit 817842a6c27a82781d5472890d19d3d93057cc06 Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> Date: 2016-09-08T17:23:16Z FC-144 Use Groups of Roles to create Sessions Updated tests commit cdcc4e4d751ffd229dace34a8180b442261f6d35 Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> Date: 2016-09-14T17:32:38Z FC-144 Use Groups of Roles to create Sessions Added GroupMgrImpl assign/deassign role methods, modified existing methods to map to core manager's one commit 3eb9754290ced641b9a303b356cd6031165a02cc Author: Vyacheslav Vakhlyuev <vvakhlyuev@mirantis.com> Date: 2016-09-23T14:19:30Z FC-144 Use Groups of Roles to create Sessions Updated core AccessMgr method signature (renamed)
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user asfgit closed the pull request at:

          https://github.com/apache/directory-fortress-core/pull/6

          Show
          githubbot ASF GitHub Bot added a comment - Github user asfgit closed the pull request at: https://github.com/apache/directory-fortress-core/pull/6
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user asfgit closed the pull request at:

          https://github.com/apache/directory-fortress-enmasse/pull/1

          Show
          githubbot ASF GitHub Bot added a comment - Github user asfgit closed the pull request at: https://github.com/apache/directory-fortress-enmasse/pull/1

            People

            • Assignee:
              vvakhlyuev Vyacheslav Vakhlyuev
              Reporter:
              fstingaciu@mirantis.com Florin Stingaciu
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development