[
https://issues.apache.org/jira/browse/FC-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn McKinney resolved FC-235.
-------------------------------
Resolution: Fixed
> 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)
