[
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.
h2. Validation Code
/**
* This class performs dynamic constraint validation on role per FC-235
*
* @author <a href="mailto:[email protected]";>Apache Directory
Project</a>
*/
public class Discriminant
implements Validator
{
/**
* This method is called during entity activation, \{@link
org.apache.directory.fortress.core.util.VUtil#validateConstraints} and ensures
role has a
* matching constraint value.
*
* @param session Contains the discriminant name and value, passed by
the caller, along with their corresponding values, as user properties.
* @param role only the name is used on this.
* @param time contains the current time stamp which is not needed
here.
* @param type here it is used as this validator should not be
applied to a user.
* @return '0' if validation succeeds else \{@link
org.apache.directory.fortress.core.GlobalErrIds#ACTV_FAILED_DISCRIMINANT} if
failed.
*/
@Override
public int validate(Session session, Constraint role, Time time,
VUtil.ConstraintType type )
{
int rc = 0;
// Doesn't make sense to apply this constraint on a user:
if ( type != VUtil.ConstraintType.USER )
{
// This constraint type requires a global config parameter keyed by
the role name:
String constraintType = Config.getInstance().getProperty(
role.getName() );
// Is there a runtime constraint placed on this role activation?
if ( StringUtils.isNotEmpty( constraintType ))
{
// Get the constraint value for this user set as property on
the user entity keyed with the role's name:
String userProp = session.getUser().getProperty( role.getName()
);
// Does the user have one set?
if ( StringUtils.isNotEmpty( userProp ) )
{
// This value must be placed here by the caller:
String constraintValue = session.getUser().getProperty(
constraintType );
// Verify the role's corresponding property value matches
the value passed in by the caller of this function.
if ( !userProp.equalsIgnoreCase( constraintValue ) )
{
rc = GlobalErrIds.ACTV_FAILED_DISCRIMINANT;
}
}
else
{
// This user does not have a corresponding property applied
to a role that has a runtime constraint set.
rc = GlobalErrIds.ACTV_FAILED_DISCRIMINANT;
}
}
}
return rc;
}
}
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: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.
h2. Validation Code
public int validate(Session session, Constraint role, Time time,
VUtil.ConstraintType type )
{
int rc = 0;
// Doesn't make sense to apply this constraint on a user:
if ( type != VUtil.ConstraintType.USER )
{
// This constraint type requires a global config parameter keyed by
the role name:
String constraintType = Config.getInstance().getProperty(
role.getName() );
// Is there a runtime constraint placed on this role activation?
if ( StringUtils.isNotEmpty( constraintType ))
{
// Get the constraint value for this user set as property on
the user entity keyed with the role's name:
String userProp = session.getUser().getProperty( role.getName()
);
// Does the user have one set?
if ( StringUtils.isNotEmpty( userProp ) )
{
// This value must be placed here by the caller:
String constraintValue = session.getUser().getProperty(
constraintType );
// Verify the role's corresponding prooperty value matches
the value passed in by the caller of this function.
if ( !userProp.equalsIgnoreCase( constraintValue ) )
{
rc = GlobalErrIds.ACTV_FAILED_DISCIMINATOR;
}
}
else
{
// This user does not have a corresponding property applied
to a role that has a runtime constraint set.
rc = GlobalErrIds.ACTV_FAILED_DISCIMINATOR;
}
}
}
return rc;
}
> 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.
> h2. Validation Code
> /**
> * This class performs dynamic constraint validation on role per FC-235
> *
> * @author <a href="mailto:[email protected]";>Apache Directory
> Project</a>
> */
> public class Discriminant
> implements Validator
> {
> /**
> * This method is called during entity activation, \{@link
> org.apache.directory.fortress.core.util.VUtil#validateConstraints} and
> ensures role has a
> * matching constraint value.
> *
> * @param session Contains the discriminant name and value, passed by
> the caller, along with their corresponding values, as user properties.
> * @param role only the name is used on this.
> * @param time contains the current time stamp which is not needed
> here.
> * @param type here it is used as this validator should not be
> applied to a user.
> * @return '0' if validation succeeds else \{@link
> org.apache.directory.fortress.core.GlobalErrIds#ACTV_FAILED_DISCRIMINANT} if
> failed.
> */
> @Override
> public int validate(Session session, Constraint role, Time time,
> VUtil.ConstraintType type )
> {
> int rc = 0;
> // Doesn't make sense to apply this constraint on a user:
> if ( type != VUtil.ConstraintType.USER )
> {
> // This constraint type requires a global config parameter keyed
> by the role name:
> String constraintType = Config.getInstance().getProperty(
> role.getName() );
> // Is there a runtime constraint placed on this role activation?
> if ( StringUtils.isNotEmpty( constraintType ))
> {
> // Get the constraint value for this user set as property on
> the user entity keyed with the role's name:
> String userProp = session.getUser().getProperty(
> role.getName() );
> // Does the user have one set?
> if ( StringUtils.isNotEmpty( userProp ) )
> {
> // This value must be placed here by the caller:
> String constraintValue = session.getUser().getProperty(
> constraintType );
> // Verify the role's corresponding property value matches
> the value passed in by the caller of this function.
> if ( !userProp.equalsIgnoreCase( constraintValue ) )
> {
> rc = GlobalErrIds.ACTV_FAILED_DISCRIMINANT;
> }
> }
> else
> {
> // This user does not have a corresponding property
> applied to a role that has a runtime constraint set.
> rc = GlobalErrIds.ACTV_FAILED_DISCRIMINANT;
> }
> }
> }
> return rc;
> }
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
