You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Shawn McKinney (JIRA)" <ji...@apache.org> on 2018/07/06 23:40:00 UTC
[jira] [Created] (FC-235) Add support for runtime constraints to be
placed on activated roles
Shawn McKinney created FC-235:
---------------------------------
Summary: 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
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: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() );}}
{{ }}}
{{ }}}
{{}}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)