directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn McKinney (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FC-235) Add support for runtime constraints to be placed on activated roles
Date Fri, 06 Jul 2018 23:49:00 GMT

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

Shawn McKinney updated FC-235:
------------------------------
    Description: 
h3. Rationale for change

One of the advantages of RBAC is the concept of an activated role.  It allows us to limit
when a particular role can be used within a session. 

For example, temporal constraints, place limits on when a role can be activated based on time
and date of the runtime environment.

This enhancement expands that capability to other types of instance data like location or
project.  This will help reduce the number of roles that have to be created.  Now, we won't
have to have a teller role for every branch.  Rather one teller role will be created, and
every user will store properties that control which branch that role can be used in.

The idea here is to not limit to just a branch constraint rather allow flexibility of the
types of instance data that can be used.

Fortunately, most of what is needed to add these types of controls is already present in the
fortress core. The combination of configuration properties and user properties can be used
to store the policies.
h3. example scenario
h3. Role (properties)

Globally we'll store as config elements the name of each role to be constraint along with
the name of the type of constraint.  It will be a trigger for the role activation process
to perform special validation.

admin:location

manager:location

servicerep:location
h3. Users:

Each user, in addition to their typically role assignments, will store properties that define
the constraint value for when that role may be applied.  Here we're using location constraints,
so each role assignment on the user (constrained in this way) must also have a corresponding
property that specifies where that role may be used.

 

*curly*

roles assigned : admin, manager, servicerep

props: admin:123, manager:456, servicerep:789

*larry*

roles assigned : manager

props: manager:789

*moe*

roles assigned : servicerep

servicerep:123

 

Intuitively we can look at these properties and see what's going on.  Globally, the implementation
defines which roles to be constrained, and what the constraint type is.  In this case a locale
type constraint.  Next, we can see what location each user may activate their assigned roles. 
Curly is the most powerful of the three, and can activate all three roles, albeit contrained
within one locale each.  Larry can only activate his manager role in location 789 while Moe
can activate as a servicerep only in location 123.

 

These constraints are evaluated during the createSession role activation phase.  The caller
specifies which location the user is in by pushing into the runtime as a property on the inbound
user object. 

So if our runtime is at location 123, they will push this in:

User inUser = new User("curly");

inUser.setProperty("location", "123");

Before calling createSession.  Now the validation routine simply has to make sure that every
target role being activated is checked against the constraint value.  

 

Here is a prototype of that validation code.  Keep in mind this all has to work with 'normal'
roles, which are not constrained in this special way.

{{ // Verify location constraints, for every active role do.}}
 {{for ( UserRole role : session.getRoles())}}
 {
 {{   String constraintType = Config.getInstance().getProperty( role.getName() );}}
 {{   // Is there a runtime constraint placed on this role activation?}}
 {{   if ( StringUtils.isNotEmpty( constraintType ))}}
 {{   {}}
 {{      String userProp = session.getUser().getProperty( role.getName() );}}
 {{    // user have prop associated with the runtime constraint on this particular role?}}
 {{    if( StringUtils.isNotEmpty( userProp ))}}
 {{    {}}
 {{     // passed by caller in a prop with keyName in the constraintType for the role.}}
 {{     String constraintValue = user.getProperty( constraintType );}}
 {{     // Is the activated role's valid per the value passed in by the caller?}}
 {{     if ( !userProp.equalsIgnoreCase( constraintValue ) )}}
 {{     {}}
 {{           //session.getRoles().remove( role );}}
 {{           LOG.info( "deactivate role {}", role.getName() );}}

           {
 {{     else}}
 {{     {}}
 {{         //session.getRoles().remove( role );}}
 {{        LOG.info( "deactivate caller not set constraint for role {}", role.getName()
);}}

 

  was:
h3. Rationale for change

One of the advantages of RBAC is the concept of an activated role.  It allows us to limit
when a particular role can be used within a session. 

For example, temporal constraints, place limits on when a role can be activated based on time
and date of the runtime environment.

This enhancement expands that capability to other types of instance data like location or
project.  This will help reduce the number of roles that have to be created.  Now, we won't
have to have a teller role for every branch.  Rather one teller role will be created, and
every user will store properties that control which branch that role can be used in.

The idea here is to not limit to just a branch constraint rather allow flexibility of the
types of instance data that can be used.

Fortunately, most of what is needed to add these types of controls is already present in the
fortress core. The combination of configuration properties and user properties can be used
to store the policies.
h3. example scenario
h3. Role (properties):(

Globally we'll store as config elements the name of each role to be constraint along with
the name of the type of constraint.  It will be a trigger for the role activation process
to perform special validation.

admin:location

manager:location

servicerep:location
h3. Users:

Each user, in addition to their typically role assignments, will store properties that define
the constraint value for when that role may be applied.  Here we're using location constraints,
so each role assignment on the user (constrained in this way) must also have a corresponding
property that specifies where that role may be used.

 

*curly*

roles assigned : admin, manager, servicerep

props: admin:123, manager:456, servicerep:789

*larry*

roles assigned : manager

props: manager:123

*moe*

roles assigned : servicerep

servicerep:123

 

This gets kicked off by the caller, who will push into the runtime the target value of the
constraint.  So if our runtime is within location 123, they will push this in:

User inUser = new User("curly");

inUser.setProperty("location", "123");

Before calling createSession.  Now the validation routine simply has to make sure that every
target role, that is constrained (has a global property defined), has a matching property
value on the user's entry corresponding with that role.

 

Here is a prototype of that validation code

{{ // Verify location constraints, for every active role do.}}
 {{for ( UserRole role : session.getRoles())}}
 {
 {{   String constraintType = Config.getInstance().getProperty( role.getName() );}}
 {{   // Is there a runtime constraint placed on this role activation?}}
 {{   if ( StringUtils.isNotEmpty( constraintType ))}}
 {{   {}}
 {{      String userProp = session.getUser().getProperty( role.getName() );}}
 {{    // user have prop associated with the runtime constraint on this particular role?}}
 {{    if( StringUtils.isNotEmpty( userProp ))}}
 {{    {}}
 {{     // passed by caller in a prop with keyName in the constraintType for the role.}}
 {{     String constraintValue = user.getProperty( constraintType );}}
 {{     // Is the activated role's valid per the value passed in by the caller?}}
 {{     if ( !userProp.equalsIgnoreCase( constraintValue ) )}}
 {{     {}}
 {{           //session.getRoles().remove( role );}}
 {{           LOG.info( "deactivate role {}", role.getName() );}}

           {
 {{     else}}
 {{     {}}
 {{         //session.getRoles().remove( role );}}
 {{        LOG.info( "deactivate caller not set constraint for role {}", role.getName()
);}}

 


> Add support for runtime constraints to be placed on activated roles
> -------------------------------------------------------------------
>
>                 Key: FC-235
>                 URL: https://issues.apache.org/jira/browse/FC-235
>             Project: FORTRESS
>          Issue Type: Improvement
>    Affects Versions: 2.0.0
>            Reporter: Shawn McKinney
>            Assignee: Shawn McKinney
>            Priority: Major
>             Fix For: 2.0.1
>
>
> h3. Rationale for change
> One of the advantages of RBAC is the concept of an activated role.  It allows us to
limit when a particular role can be used within a session. 
> For example, temporal constraints, place limits on when a role can be activated based
on time and date of the runtime environment.
> This enhancement expands that capability to other types of instance data like location
or project.  This will help reduce the number of roles that have to be created.  Now, we
won't have to have a teller role for every branch.  Rather one teller role will be created,
and every user will store properties that control which branch that role can be used in.
> The idea here is to not limit to just a branch constraint rather allow flexibility of
the types of instance data that can be used.
> Fortunately, most of what is needed to add these types of controls is already present
in the fortress core. The combination of configuration properties and user properties can
be used to store the policies.
> h3. example scenario
> h3. Role (properties)
> Globally we'll store as config elements the name of each role to be constraint along
with the name of the type of constraint.  It will be a trigger for the role activation process
to perform special validation.
> admin:location
> manager:location
> servicerep:location
> h3. Users:
> Each user, in addition to their typically role assignments, will store properties that
define the constraint value for when that role may be applied.  Here we're using location
constraints, so each role assignment on the user (constrained in this way) must also have
a corresponding property that specifies where that role may be used.
>  
> *curly*
> roles assigned : admin, manager, servicerep
> props: admin:123, manager:456, servicerep:789
> *larry*
> roles assigned : manager
> props: manager:789
> *moe*
> roles assigned : servicerep
> servicerep:123
>  
> Intuitively we can look at these properties and see what's going on.  Globally, the
implementation defines which roles to be constrained, and what the constraint type is.  In
this case a locale type constraint.  Next, we can see what location each user may activate
their assigned roles.  Curly is the most powerful of the three, and can activate all three
roles, albeit contrained within one locale each.  Larry can only activate his manager role
in location 789 while Moe can activate as a servicerep only in location 123.
>  
> These constraints are evaluated during the createSession role activation phase.  The
caller specifies which location the user is in by pushing into the runtime as a property on
the inbound user object. 
> So if our runtime is at location 123, they will push this in:
> User inUser = new User("curly");
> inUser.setProperty("location", "123");
> Before calling createSession.  Now the validation routine simply has to make sure that
every target role being activated is checked against the constraint value.  
>  
> Here is a prototype of that validation code.  Keep in mind this all has to work with
'normal' roles, which are not constrained in this special way.
> {{ // Verify location constraints, for every active role do.}}
>  {{for ( UserRole role : session.getRoles())}}
>  {
>  {{   String constraintType = Config.getInstance().getProperty( role.getName() );}}
>  {{   // Is there a runtime constraint placed on this role activation?}}
>  {{   if ( StringUtils.isNotEmpty( constraintType ))}}
>  {{   {}}
>  {{      String userProp = session.getUser().getProperty( role.getName() );}}
>  {{    // user have prop associated with the runtime constraint on this particular
role?}}
>  {{    if( StringUtils.isNotEmpty( userProp ))}}
>  {{    {}}
>  {{     // passed by caller in a prop with keyName in the constraintType for the
role.}}
>  {{     String constraintValue = user.getProperty( constraintType );}}
>  {{     // Is the activated role's valid per the value passed in by the caller?}}
>  {{     if ( !userProp.equalsIgnoreCase( constraintValue ) )}}
>  {{     {}}
>  {{           //session.getRoles().remove( role );}}
>  {{           LOG.info( "deactivate role {}", role.getName() );}}
>            {
>  {{     else}}
>  {{     {}}
>  {{         //session.getRoles().remove( role );}}
>  {{        LOG.info( "deactivate caller not set constraint for role {}", role.getName()
);}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message