Thursday, May 12, 2016

WSO2GREG Dynamically changing role permissions of artifacts

Some times there can be requirements, based on the lifecycle state of an asset, the set of permissions given for roles needs to be changed.

This post explains when assets move from one state to another in their lifecycle , how permission transition will take place. Lets define the permission transitions together with the registry resource permissions available at each state in the lifecycle is as follows:



          
Action
Current State
Next State
publisher
reviewer
everyone
promote
Initial
Created
+add
+delete
+authorize
+get


promote
Created
In-Review
-add
-delete
-authorize
+get 
+add
+authorize

promote
In-Review
Published
+add
+delete
+authorize
+get
 -add
-authorize
+get
demote
Published
Unpublished
+add
+authorize
...- get
promote
Unpublished
In-Review
+add
+authorize
...
+get

Once you define the permission transmissions then you can incorporate with transitionExecutions of the associated lifecycle along with "org.wso2.jaggery.scxml.generic.GenericExecutor" with STATE_RULES. This SampleLifeCycle is an example.


.........
<data name="transitionExecution">
    <execution forEvent="Promote" class="org.wso2.jaggery.scxml.generic.GenericExecutor">
        <parameter name="PERMISSION:get"
                   value="http://www.wso2.org/projects/registry/actions/get"/>
        <parameter name="PERMISSION:add"
                   value="http://www.wso2.org/projects/registry/actions/add"/>
        <parameter name="PERMISSION:delete"
                   value="http://www.wso2.org/projects/registry/actions/delete"/>
        <parameter name="PERMISSION:authorize" value="authorize"/>


        <parameter name="STATE_RULE1:In-Review"
                   value="Internal/publisher:+get,-add,-delete,-authorize"/>
        <parameter name="STATE_RULE2:In-Review"
                   value="Internal/reviewer:+get,+add,-delete,+authorize"/>
        <parameter name="STATE_RULE3:In-Review"
                   value="Internal/everyone:-get,-add,-delete,-authorize"/>
    </execution>
</data>
........
After performing Lifecycle state transitions, in the management console you can see the actual permissions for roles get changed at each state.


The correspondence between above permissions to actual permissions that we see associated to a asset is as below.

                       Permission Table                           Lifecycle         
Readget
Writeadd
Deletedelete
Authorizeauthorize
+Allow
-Deny

                ex:       +get == Read Allow 
                             -get == Read Deny


2 comments:

  1. However, Rules such as


    where "Internal/private_{asset_author}" role is mentioned cannot be used in mounted setups since in an mounted environment those {asset_author} is evaluated to be 'wso2.system.user'.

    ReplyDelete
    Replies
    1. However, Rules such as
      "parameter name="STATE_RULE1:In-Review"
      value="Internal/private_{asset_author}:+get,-add,-delete,-authorize"/"

      where "Internal/private_{asset_author}" role is mentioned cannot be used in mounted setups since in an mounted environment those {asset_author} is evaluated to be 'wso2.system.user'.

      Delete

Designed ByBlogger Templates