- Many enterprises have users whose numbers can be in the hundreds of thousands or millions For such enterprises, manually assigning users to roles may not be feasible, especially in case of external users, i.e. the enterprise customers and business partners.
- Manual user-to-role assignment becomes a formidable task because maintaining user-role assignment up-to-date is both costly and error-prone.
- Automated assignment gives the enterprise an edge by extending its user-consumer business partnership.
Rule-Based RBAC (RB-RBAC)
Family of models that was suggested to provide a sound conceptual basis for the automation process and sets a benchmark for software implementations of the process.
Two well known decision policies
- Closed policy - This policy allows access if there exists a corresponding positive authorization and denies it otherwise.
- major problem: the lack of a given authorization for a given user does not prevent this user from receiving this authorization later on
- explicit negative authorization as blocking authorizations is proposed as a solution
- Open policy - This policy denies access if there exists a corresponding negative authorization and allows it otherwise.
RB-RBAC Family Model
Model A is the most basic among the family. This model allows the specification of a set of authorization rules that can be used to assign users to roles based on users’ attributes.
Model B extends Model A to allow the specification of negative authorization (Model B1) and mutual exclusion (Model B2) by extending the ASL_A language. The extended language is called ASL_B1 and ASL_B2, respectively.
Model C extends Model A to allow constraints specification.
Model A Basic Concepts
U = users
R = roles
P = permissions
A (supposed to be AE) = attribute expressions
Security policy of the enterprise is expressed in the form of a set of authorization rules.
- Each rule takes as an input the attributes expression (a member of AE set) that is satisfied by a user (a member of U set) and produces one or more roles (a member of R set).
- The left hand side (LHS) of a rule is an attribute expression.
- One or more role(s) in the right hand side (RHS).
- If u satisfies the attribute expression, u is authorized to the role(s) specified in RHS of the rule.
- ae_i -> r_g
To maintain user-role authorization the set URAuth is defined as follows:
URAuth = {(u,r)| (∃rule i)[u satisfies ae_i ∧ r ∈RHS(aei)}
If (u,r) ∈ URAuth then this means that u is authorized to role r.
There is an implicit “OR” among the rules. If u satisfies one or more rules that produce different roles, then he is authorized to activate any combination of these roles.
User States
- Potential (P): user u is authorized to role r but has not activated it yet.
- Revoked (R): user u has activated role r at least once but is not currently authorized to activate it.
- Not-candidate (N): user u has not activated role r and is not currently authorized to activate it because he does not have the required attributes for assuming r, i.e. u is not authorized to r.
- Deleted (Del): user u has been deleted from the system by an authorized individual such as the System Security Officer (SSO).
- Active (Act): refers to the state where the user is currently active in the role.
- Dormant (D): After deactivating a role, the user becomes dormant with respect to that specific role, i.e. in “D” state.
Seniority among authorization rules
Seniority can be determined among the rules based on attributes expressions on their left hand sides. The “≥” symbol, read “is senior to”, represents seniority relation among rules:
rule_i ≥ rule_j↔ (ae_i -> ae_j)
This implies that users who satisfy rule_i also satisfy rule_j and, hence, are authorized to the roles produced by rule_j.
The seniority relation on authorization rules, i.e. among attributes expressions forming the LHS
of the rules, induces a hierarchy among the roles forming the RHS of these rules. This induced role hierarchy (IRH) captures inheritance of user-role assignment.
- If r_i is senior to r_j then the users who satisfy the LHS of the rule that yields r_i will also satisfy the rules that yield r_j.
Alternative ways to gain authorization
- Implicit Assignment: Based on certain criteria, users are automatically assigned to roles. This is what Model A does thus far.
- Hybrid Assignment: Besides the automatic assignment, the SSO can manually assign users to roles.
- Explicit Assignment: In this approach a person with proper authority such as the SSO manually assigns users to roles. This is what traditional RBAC follows.
The SSO may use can_assume relation to explicitly authorize users who are authorized to a role, say r_g, to another role, r_h, for a certain duration d starting at a specific time t. The SSO specifies the duration and the starting time. As a result, the user(s) in role r_g is authorized to activate role r_h at time t for duration of d.
RB-RBAC-ve Model
RB-RBAC-ve extends Model A to allow the specification of negative authorization.
ae_k -> ¬ r_i
The rule above states that once a user satisfies ae_k the system that implements RB-RBAC prohibits that user from assuming r_i.
Motivations
- A small number of individuals (e.g. SSOs) are entrusted with applying the enterprise security policy regarding user-role assignment. However, since RB-RBAC automates this process, negative authorization provides an extra safeguard, since it is not always easy to foresee all possible combinations of roles a user can assume based on his attributes, which change over time.
- It can be used to block receiving authorization of certain roles via can_assume and can_delegate relations.
- can_delegate - permit regular users to delegate their memberships in specific roles to
other users.
- can_delegate - permit regular users to delegate their memberships in specific roles to
Conflict due to negative authorization
- Case 1: Conflict among unrelated rules like the one between rule2 and rule3. If u satisfies rule2 and rule3 simultaneously then u should be authorized to activate r1 (i.e. u is in P state wrt r1) and denied r1 at the same time (i.e. u is in N state wrt r1).
- Case 2: Conflict among related rules: rule3 and rule5 are conflicting because if u satisfies rule3 then he is denied r1 (i.e. u is in N state wrt r1), but at the same time, authorized to assume r1 (i.e. u is in P state wrt r1) because rule3 ≥ rule5.
- Case 3: Conflict between implicit assignment i.e. via an authorization rule and explicit assignment i.e. via can_assume or can_delegate. Suppose that the SSO issued the following: can_assume(r4, r3, t, d) This allows users who are authorized to r4 to activate r3. If u satisfies ae1, i.e. u is in N state wrt r3, and at the same time is authorized to r4. Nonetheless, the can_assume relation above authorizes u to r3, which leads to a conflict.
Conflict resolution policies
- Denial Takes Precedence (DTP): Negative authorizations are always adopted when conflict exists.
- Permission Takes Precedence (PTP): Positive authorizations are always adopted when conflict exists.
- Localized DTP (LDTP): Modifying the DTP policy such that the conflict among unrelated rules is resolved in favor of permission. In other words, the denial is localized to conflict among comparable rules.
- Flexible DTP (FDTP): This policy enforces DTP in cases where conflict occurs among authorization rules but it enforces PTP if conflict occurs between the implicit assignment and explicit assignment. In other words, FDTP policy authorizes u to role r if there is no conflict wrt role r, or if there is a can_assume relation which authorizes u to role r even if u receives a negative authorization wrt to r.
- Weighted rules
- The seniority of the rule, so rule3 has higher weight than rule5 in Figure 4 and, thus, the negative authorization is enforced.
- The seniority of the rule issuer. Based on this, an SSO-issued rule has higher weight than a rule issued by a junior security officer and, thus, the authorization obtained via the higher rule prevails.
- Labeled roles: This policy requires assigning label to each role. This label could be either one of the following values: DTP or PTP.
Impact on role hierarchies
GRH = given role hierarchy
Possible semantics with negative authorizations (example rule_i = ae_i -> ¬ r_g):
- Propagation prohibited: Users who satisfy ae_i should be prohibited from assuming r_g. This is the interpretation given previously.
- Propagation allowed: Negative authorization propagates upward in GRH such that users who satisfy ae_i should be prohibited not only from assuming r_g, but also from assuming any role r_k such that r_k ≥ r_g.
- This ensures that the user cannot circumvent the system by assuming r_k, whose permissions are a superset of r_g’s.
- From a functional perspective, this may not be desirable since it is usually the case that the prohibition is targeting users who merely satisfy rule_i, but not those who can assume roles higher in the hierarchy by virtue of satisfying rules senior to rule_i, which usually means that they meet higher security requirement.
Enforcement requirements
Enforcing the negative authorization requires that the system which implements RB-RBAC has access to all relevant attributes. This requirement affects the architectural options that can be used to enforce RB-RBAC-ve since the system must either have these attributes under its control or be granted access to them when needed. If this is not the case, then users may evade the model.
No comments:
Post a Comment