C. Georgiadis, I. Mavridis, G. Pangalos, R. Thomas. 2001. "Flexible Team-Based Access Control Using Contexts"

In this paper, we extend the original TMAC proposal in two key directions.

1. First, we give a framework to integrate TMAC concepts with RBAC.
2. Second, we extend TMAC to use general contextual information. Such contextual information can among others include the time of access, the location from which access is requested, the location where the object to be accessed resides, transaction-specific values that dictate special access policies etc.

This generalized model is referred to in the rest of the paper as C-TMAC (for context-based TMAC).



C-TMAC model

• A user (U) is simply a person.
• A role (R) is a job function within the organization.
• Permissions (P) are approvals of a particular mode of access to one or more data objects.
• User assignment (URS) and permission assignment (PRS) are both many-to-many relations.
• An important property of a session (S) is that the user associated with a session cannot change. The association remains constant for the life of a session. The permissions available to the user are the union of permissions from all roles activated in that session. In addition, active roles in a session can be changed at the user’s discretion.
• In context (C) is included information regarding the required data objects for a specific activity, as well as contextual information such as locations and time intervals etc.
• The team (T) entity is used to represent a group of users having specific roles with the objective of completing a specific activity in a particular context.
• The team concept is used also as a mechanism that associates users with contexts. The use of a team as an intermediary to enable a user to obtain a context is similar to the use of roles as an intermediary between users and permissions.
• Even when a user is acting alone, we may consider the user as the only member of a private team.
• During a session, a user can participate in a number of teams. So, each session is also a mapping of one user to a subset of teams that he is a member of.
• The contexts available to the user are the union of contexts from all teams that he participates in.
• Active teams in a session can be changed at the user’s discretion, just like his active roles.
• A team can also be seen as a mapping to multiple users. The roles activated by these users identify the permission set available to the team as the combination of permissions from all roles participating in that team.
• Context assignment (CTS) and team assignment (UTS) are both many-to-many relations.
  • However, there are constraints when assigning user to teams, e.g. a user that has been assigned the roles Physician and Director cannot participate in a care-team as a Director.

C-TMAC formal description

• U, R, P, S, T, C, stand for users, roles, permissions, sessions, teams and contexts, respectively
• PRS ⊆ P x R, is a many-to-many permission to role assignment relation
• URS ⊆ U x R, is a many-to-many user to role assignment relation
• CTS ⊆ C x T, is a many-to-many context to team assignment relation
• UTS ⊆ U x T, is a many-to-many user to team assignment relation
• session-user : S → U, is a function mapping each session s_i to the single user user(s_i) that is constant for the session’s lifetime
• session-roles : S → 2^R, is a function mapping each session s_i to a set of roles roles(s_i) ⊆ {r | (user(s_i), r) ∈ URS}, which can change with time, and session s_i has the permissions ∪nion_of r ∈roles(s_i) {p | (p, r) ∈ PRS} referred to as Session-Roles Permissions
• session-teams : S → 2^T, is a function mapping each session s_i to a set of teams teams(s_i) ⊆ {t | (user(s_i), t) ∈ UTS}, which can change with time, and session s_i has the contexts ∪nion_of t ∈ teams(s_i) {c | (c, t) ∈ CTS} referred to as Team-Context
• team-users : T → 2^U, is a function mapping each team t_i to a set of users users(t_i) ⊆ {u | (u, t_i) ∈ UTS} ∧ ∃ s_j : user(s_j) = u}, which can change with time
• team-roles : T → 2^R, is a function mapping each team t_i to a set of roles roles(t_i) ⊆ {r | (users(t_i), r) ∈ URS}, which can change with time, and team t_i has the permissions ⊕ r ∈ roles(t_i) {p | (p, r) ∈ PRS}, referred to as Team-Roles Permissions, and where ⊕ means “combination”

Different meanings of ⊕ (choose one):

• Aggregation: The set of access permissions of the team is the sum-up (union) of the individual assigned role-based access permissions of all team members.
• Maximum/Minimum: The set of access permissions is considered to be equal to the maximum or minimum permissions sets of the individual members of the team.
• Current team structure: The structure (formation) of the team is used to determine the credentials held by the team members. According to a team template, a certain number of members of the team is required. Individual users are not permitted to perform actions on their own but only in the presence of the remainder participants of the team.

Activation of final user permissions

1. Considering a user who has activated a subset of roles and participates in a subset of teams, initially the role-based permissions of this user are derived with the following definition, where the symbol ⊕ stands for “combined with”:
   • Role-based Permissions = Session-Roles Permissions ⊕ Team-Roles Permissions
2. Step 2: The final permissions activated are the context-based permissions, which are derived from role-based permissions (step 1) with the following definition, where x means “filtered by”:
   • Context-based Permissions = Role-based Permissions x Team-Context

C-TMAC example
Tasks in healthcare environments could be defined at runtime (dynamically) on the basis of the following contextual variables:

• patient: a user (doctor, nurse) gains additional permissions for a specific patient he is in care of.
• location: the collaborative activity depends on the specific area wherein the users (members) of a particular team are working
• time: all permissions are valid during a certain time (periodic) interval

A backend relational database management system is used.

• objects of protection are relations, tuples, attributes and views using modes of access operations such as SELECT, INSERT, DELETE and UPDATE
• permissions of users can be defined as data views (e.g. by using the SELECT statement of the Structured Query Language - SQL)

Assume the presence of the following table in the medical database: PATIENTS (PatientID, field1, field2, field3, field4, field5).

For roles Doctor, Head Nurse and Nurse, the sets of role permissions for this table, with view-based protection expressed in SQL form, are as follows:

• Permissions (Doctor): SELECT field1, field2, field3 FROM PATIENTS
• Permissions (Head Nurse): SELECT field1, field3, field4 FROM PATIENTS
• Permissions (Nurse): SELECT field1, field4 FROM PATIENTS

Assume an Emergency Room care-team.

Assume that context parameters for clinical tasks are:

• patientids
• current time
• current location of the users

Possible locations of users could be:

• ER-1 - emergency room 1
• ER-3 - emergency room 3
• GW-2 - general ward

The context assigned to the ER-Team could be as follows:

• Context (ER-Team):
• SetOfPatients: (200, 351, 402, 667)
• TimeZone: [10:00;12:00]
• SetOfLocations: (ER-1, ER-3, GW-2)

Assume that users Mary and Helen have already started their sessions s1 and s2 and activated their roles HeadNurse and Nurse respectively, and they are participating in the ER-Team.

• Session 1:
• session-user(s1) = ‘Mary’
• session-roles(s1) = [HeadNurse]
• session-teams(s1) = [ER-Team]
• Session 2:
• session-user(s2) = ‘Helen’
• session-roles(s2) = [Nurse]
• session-teams(s2) = [ER-Team]
• Team-users (ER-Team) = [Mary, Helen]
• Team-roles (ER-Team) = [Head Nurse, Nurse]

Then, Team-Roles Permissions (ER-Team) = SELECT field1, field3, field4 FROM PATIENTS

Assume that user Chris is starting his session s3 and is activating the role Doctor and is participating in the ER-Team.

• Session 3:
• session-user(s3) = ‘Chris’
• session-roles(s3) = [Doctor]
• session-teams(s3) = [ER-Team]
• Team-users (ER-Team) = [Chris, Mary, Helen]
• Team-roles (ER-Team) = [Doctor, Head Nurse, Nurse]

Assume aggregation (union) as the combination method for role-based permissions:

• Role-based Permissions(Chris) =
• = Session-Roles Permissions (Doctor) ⊕ Team-Roles Permissions (ER-Team)
• = {SELECT field1, field2, field3 FROM PATIENTS} ∪ {SELECT field1, field3, field4 FROM PATIENTS}
• = SELECT field1, field2, field3, field4 FROM PATIENTS
• Context-based Permissions (Chris) =
• = Role-based Permissions (Chris) x Team-Context (ER-Team)
• = SELECT field1, field2, field3, field4 FROM PATIENTS WHERE CurrentPatientID IN (200, 351, 402, 667) AND CurrentTime IN [10:00;12:00] AND CurrentLocation IN (ER-1,ER-3,GW-2) [view 1]
  

Assume Chris places the following access request at 11.30 (CurrentTime = [11:30], from Emergency Room Nr.1 (CurrentLocation = ER-1) and for patient with ID = 351 (CurrentPatientID = ‘351’):

• SELECT field1, field4 FROM PATIENTS WHERE PatientID = CurrrentPatientID [view 2]
  

This action has two effects. Firstly, view-1 expression is evaluated, since all variables contain specific values. Secondly, based on the user access request, the system evaluates and compares view-1 and view-2. The access control system examines whether the set of results from access request (view-2) is included (IN clause of SQL) in the set of results of context-based permissions (view-1).

R. Thomas. 1997. "Team-based Access Control (TMAC): A Primitive for Applying Role-based Access Controls in Collaborative Environments"

Three objectives:

• to provide a security environment that was non-intrusive to clinical staff.
• to provide very tight, just-in-time permissions so that only the appropriate clinical staff could get access to a patient’s records and only when they were providing care for the patient.
• to design a security framework that did not add any significant administrative overhead and was therefore self-administering to a great extent.

RBAC shortcomings:

• The need for a hybrid access control model that incorporated the advantages of having broad, role-based permissions across object types, yet required fine-grained control on individual users in certain roles and on individual object instances.
• A second requirement was the need to recognize the context associated with collaborative tasks and the ability to apply this context to decisions regarding permission activation.

Passive vs active security model:

• passive security model - primarily serves the function of maintaining permission assignments, such as in RBAC where permissions are assigned to roles
• active security model - distinguishes task- and context-based permission activations from permission assignment
• in particular, after a permission is assigned, it may be turned on (activated) and off (deactivated) several times in accordance with the evolving context associated with progressing tasks. Only when a permission is activated will the corresponding operation succeed
• notion of sessions in RBAC96 does not go far enough in encompassing the overall context associated with any collaborative activity
  

Example:

• Begins with a visit to the emergency room (ER) by a patient who is suffering from pneumonia
• Upon arrival, the patient is quickly screened by a triage nurse who determines that the patient needs to be admitted to the general medicine ward. The primary team that admitted the patient subsequently requests a gastroenterology consultation because the patient is beginning to develop gastrointestinal bleeding.
• The gastroenterologist who is consulted decides to investigate further and proceeds to do an upper GI endoscopy procedure.
• While undergoing this procedure the patient has a heart attack and is immediately transferred to the coronary care unit where a cardiology team takes over the care of the patient, becoming the primary team.
• Eventually the patient’s heart condition is stabilized and the patient is transferred back to the general medicine ward. After spending a few more days in the hospital, the patient recovers, is discharged, and is told to see his/her primary care doctor for follow-up care.

Observations:

• A number of clinical staff (users) was involved in various roles in providing care at various points in the workflow. These included general physicians, specialists such as cardiologists, residents and interns, nurses, etc.
• The staff was organized into care teams and each team was associated with a single department or unit in the organization.
• Care teams were often dynamically formed. For example, when the gastroenterologist joined the care team as the result of a request for a gastroenterology consultation. This dynamic formation can be distinguished from the case in which a staff member is preassigned by the scheduling department to be on a particular team.

Access control requirements:

1. The permissions a clinical staff member has to clinical records (documents) should reflect his/her role in providing care. For example, only the cardiologist may prescribe a certain drug for cardiac-related illness and only physicians, not nurses, may order lab tests.
2. Only members of a patient’s team should be able to get access to the patient’s records. Thus, although a physician, P, may have the right to order a lab test by virtue of the qualifications and responsibilities that determine his role, P should have the right to do so for Patient A’s record only when P is part of A’s care team.
3. Depending on the workflow, various clinical staff needs access to patient records at different points in the overall workflow. Therefore the primary care team in general wards should be given access to a patient’s records only after the ER unit has requested transfer of the patient to one of those wards.
4. Requirements 1 and 2 above should hold for any staff member who dynamically joins a team.
5. When a patient is transferred from one unit to another, the members of the primary care team of the second unit should be given access to the records of the patient (according to their roles) and no one else.
6. Certain team members may delegate duties and associated permissions to other team members. Thus a physician may authorize a resident or nurse to order a specific lab test or referral for a specific patient. The resident would, in this situation, would need limited (probably one-time) permissions to complete this order, even though under normal circumstances, he/she would not be able to give the order directly since their role is not endowed with such privileges.
7. Once the patient is discharged, all permissions to the patient’s medical records should be deactivated.

TMAC basic ideas:
A team consists of the following:

• A team name, t.
• A set of team members/users, TU.
• A set of team roles, TR, that restricts the roles which members of the team can belong to. TR is-subset-of R, where R is the total set of roles in the information system.
• A special role called team head (h), where h is-subset-of TR. Only one user can be the team head at any given time.
• A set of object types, OT.
• A set of object instances, 0.
• A set of team permissions TP, defined across TR and OT, i.e., TP is-subset-of TR x OT
• A collaboration context that consists of the following two components.
• A user context (UC), where UC : TR x TU
• An object context (OC), where OC : OT x O

• Use RBAC to define a set of permissions P across the domains of R and OT. Individual teams of the same structure (type/class) will encompass the same subset of roles, TR of R, and will thus inherit the same subset TP of P.
• However, TMAC calls for the run time binding of the TP for each team to the sets TU and 0 of the team. This allows run-time activation of permissions at the level of individual user and objects.

TMAC should support the following primitives to enable access control on the team as a whole:

• User-assign (user, team): assigns a user to a team.
• User-deassign (user, team): removes a user from a team.
• Team-activate(team): This binds the team permissions to the team members and the objects they need (TU and 0).
• Team-deactivate (team): This deactivates the permissions for the entire team.
• User-activate and User-deactivate

TMAC can be made self-administering by trapping basic calls issued by the host information system to assign and deassign team members, as well as by trapping at run-time when workflow instances are invoked. These can then be synchronized with the user assignment and activation primitives to automate security administration.
To preserve access control to individual objects across teams, the object context can be passed from one team to another.

A. Schaad, J. Moffett, J. Jacob. 2001. "The Role-Based Access Control System of a European Bank: A Case Study and Discussion"

RBAC research problems

• Often research tools work with minimal testing datasets as no real figures for the number of users, roles and permissions in commercial systems have been published.
• Companies that have successfully deployed access control systems are often unwilling to provide descriptions and figures for their role-based systems for security reasons.
• As a consequence researchers use toy examples that fail to reflect the complexity of large industrial organizations.
• This leads to a lack of credibility from the user side.

Dresdner Bank

• 50,659 employees
  
• 1,459 branches world-wide
• main business: about 6.5 million private customers and 1,000 branches

FUB system

• Applications cannot make access control decisions on their own. They grant access to data on the basis of a centrally provided security profile.
• An application is launched by a user who first identifies and authenticates himself to it. Initially the application has no knowledge of any relevant access permissions the user might possess. It queries the FUB about the security profile of the current user in order to obtain this information.
• Created in 1990. and thus much earlier than most of the published role-based access control discussion.
• On average 42,000 security profiles per day are distributed by the FUB.
• The time needed by the system to determine one individual security profile is approximately 85 ms.
• The system’s availability rate is 99% per year.

FUB basic system architecture

• The FUB is a role-based access control system. Roles are defined as a combination of the official position and job function.
• A batch job runs between the human resources system and the FUB every night. Thus, the access control system has a very accurate image of the current organizational status and existing roles.
• Within the FUB the data delivered by the human resources database are linked to applications. Access rights are assigned to applications.
• When a user starts an application (through a role) the FUB delivers the security profile that tells the application which individual access rights the user possesses.
• Employees belong to an organizational unit. Ideally each employee is only assigned to one role. However, in special circumstances an employee can be given up to four roles (e.g. in
  the case of illness of a colleague).
  

Application example
An existing bank client wishes to discuss his personal savings situation with the branch’s financial advisor.

• The advisor identifies and authenticates himself to the machine using a smartcard and his password.
• He launches an application that allows him to enter the records of his client which are stored on a central server.
• When the application is launched it issues a request to the host, querying which rights the advisor has within the application domain.
• The application request contains the personnel number, which was obtained during the identification and authentication process. Also the application identifier is submitted to obtain the relevant authorisation profile for the application.
• Once the FUB has used these data to deliver the security profile, the application knows which access rights are assigned to the role of the user and allows him to execute his access rights accordingly.

The number of roles

• 65 official positions
• 368 different job functions
• 65 * 368 = 23,920 possible roles
• actual number of roles: 1300
• These figures match an oral estimate that was given at the RBAC2000 Workshop, suggesting that the number of roles in a role-based system is approximately 3-4% of the user population.

Role administration and control principles

• Human Resources Department - Role Definition and User/Role Assignment
• A user is given a unique number that serves as his user identification number.
• Also the roles are defined there, maintaining and combining functions and official positions.
• A user is then assigned to a role.
  
• Application Administration - Access Right Definition and Application/Access Right Assignment
• The assignment of access rights to an application is done for each individual application through the application administrator.
• This takes the form of assigning a set of numbers, representing specific access rights, to an application identifier (e.g. PKI = Private Customer Instruments).
• The semantics of these numbers are only known to the application administrator (e.g. 203 = Create new account in the Private Customer Instruments Application).
• The benefit of this is that it remains unknown to the FUB administrator responsible for the role/application assignment what access right a specific number represents within the application domain. (how is this an advantage)
  
• Dual Control: One person can alter data, whereas a second person has to confirm these data.
  
• FUB Administration - Role/Application Assignment
  

Administration problem

• It has also to provide access control services to users which can not be considered as permanent staff. (third party consultants, temporary staff, freelancers)
• Ideally, this group of users should always get a new account when starting work and their accounts should be deleted when leaving the project. However, this creates overheads.
• Thus, information about this group is not held in the Human Resources database, but is locally administered by the FUB staff. User accounts are created once and are usually kept (de-activated) when a consultant leaves.

Revocation of role and permission assignments

• By coupling the information delivered by the human resources department any user/role assignment ceases to exist when the user leaves the company.
• Also any user/role, role/application assignment becomes invalid when the organizational structure changes.
• This tight coupling bears certain dangers, because deleting a user from the human resources database will subsequently delete all his work when he ceases to exist in the system.
• Additional controls and organizational measures are needed to prevent valuable work from being lost.

System development goals
Access right allocation

• In the current system access rights can only be allocated to the combination of function/hierarchical position and organizational unit.
• However, in the case of certain access rights (e.g. set of access rights representing the power of attorney for an employee) it is desirable to assign these directly to the user.

Grouping employees

• A grouping mechanism will provide ease of administration as only the group needs to be assigned with a role and not each individual.

Grouping access rights

• Example: grouping of access right 101 for create account, and 102 for delete account into a single group G1 for account manipulation.
• These grouped rights will provide an easier assignment of access rights to applications.

Covering/Standing-in regulations

• Regulations for the covering of one employee by another (e.g. holidays or illness) do not exist.
• There are a variety of unresolved issues.
• The ability to only partially delegate application-specific access rights is one of these.
  
• Another problem considers the ability of one person to stand in for two others at the same time. This might violate any Separation of Duties requirements.

Competencies and Constraints

• The current system does not allow the specification of competencies and constraints in the security profile (e.g. authorization to sign contracts up to DM 100,000 only).

Mapping of access control system to organizational structure

• The current access control system does not provide the flexibility to meet these changes (constant change process in their structural and functional organization, unforeseen acquisitions or mergers) without a major administrative effort.
• Certain strategies in the private customer business require that an employee can be related to a certain organizational structure. This could be in the form of branches or cost centers but also more abstract structures such as enterprise-wide working groups, task forces or projects. The access control system must be able to reflect these structures.

The FUB System and the RBAC Model
Access rights inheritance through a role hierarchy

• Can be through:
  
  • hierarchy of official positions - financial analyst/Group manager > financial analyst/Clerk
  • hierarchy of functions - inspector/[Any position] > finance accountant/[Any position]
• We do not have sufficient knowledge of the organization to know which would be the best choice. It would be necessary to study the organization's access control structure in detail, paying particular attention to the gained simplification in each case, and to the other issues.

Grouping

• The Bank is considering introducing a mechanism for the grouping of employees. A grouping mechanism will provide ease of administration as only the group needs to be assigned to a role and not each individual.
• The RBAC96 model does not allow for the assignment of groups to roles.
• However, other approaches to RBAC have recognized the value of using the group as a basis for the definition of roles.
• The concept of domains can also be used to provide a mechanism for grouping users.

M. Al-Kahtani, R. Sandhu. 2004. "Rule-Based RBAC with Negative Authorization"

Conventional RBAC was designed with a closed-enterprise environment in mind where a team of security officers manually assign users to roles. However, the landscape of business and information technologies has changed dramatically in recent years.

• 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.

There are situations where pure implicit assignment is not flexible enough. Thus, to provide flexibility, the concept of can_assume was introduced.

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.

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.

Duen-Ren Liu, Mei-Yu Wu, Shu-Teng Lee. 2002. "Role-based authorizations for workflow systems in support of task-based separation of duty"

Most literature ha addressed SoD constraints in role-based authorizations of workflows.

• However, they do not consider SoD constraints in relation to various duty-conflict relationships and execution dependencies among tasks.
• Moreover, they do not consider authorization planning for assigning users/roles to workflow tasks.

Workflow

• a set of tasks, and their order of execution, according to control flow dependencies
• various tasks in a workflow are typically performed by multiple collaborating users/roles in an organization
• for two roles Ri and Rj, Ri > Rj, if the position of Ri is higher than the position of Rj in the organization

WfMS generally include process definition tools and workflow engines

• process definition tools - define a workflow (process definition) during the period of design
• workflow engine - governs the run-time enactment of workflow according to the process definition
• workflow/process instance - single execution of a workflow
• each instance represents a separate execution of the process, and has its own associated process instance data
• task instance - execution of a task (activity) within a workflow instance

Execution dependency

• Two tasks Ti and Tj are execution-dependent tasks, denoted as Ti ~ Tj, if they are correlated, such that the execution (processing) of one task (Ti) depends on the execution (processing) of the other task (Tj).
• Ti x Tj indicates that tasks Ti and Tj are not execution-dependent.
• Execution dependency among tasks can generally be derived from the accessed data objects. If task Ti accesses data objects that are created/modified by task Tj, then the execution of Ti depends on the execution of Tj.

Duty-conflict relationships

• Duty-conflict tasks - Two tasks Ti and Tj are duty-conflict tasks, denoted as Ti + Tj, if they have duty-conflict relationships; that is, their implicit task-duties conflict.
  
  • Duty-conflict relationships can be further distinguished
    into duty-balancing and duty-supervising relationships.
• Duty-balancing tasks - Two tasks Ti and Tj are duty-balancing tasks, denoted as Ti = Tj, if the implicit task-duty of Ti (Tj) is to review task Tj (Ti). Ti and Tj have an equal level of task duty.
• Duty-supervising tasks - Task Ti supervises task Tj, denoted as Ti > Tj, if the implicit task-duty of Ti is to supervise task Tj. Ti has a higher task-duty than Tj.
• If Ti has a higher task-duty than Tj, Ti must be performed by a role with a higher position than the role that performs Tj.

Authorization rules for SoD
Static SoD [role and task]

• If task Ti and task Tj have a duty-conflict relationship, and role R was authorized to perform task Ti, then role R cannot also be authorized to perform task Tj.

Static SoD [user, role, and task]

• If tasks Ti and Tj have a duty-conflict relationship; roles Rx and Ry are authorized to perform tasks Ti and Tj, respectively; also, if role Rx was assigned to user S, then role Ry can not also be assigned to user S.

Dynamic SoD - enforces SoD within the user’s current active sessions

• Tasks Ti and Tj have a duty-conflict relationship. If role Ry was authorized to perform task Tj; role Rx was authorized to perform task Ti, and user S has activated role Rx, then user S can activate role Ry but can not execute task Tj in role Ry.

Execution-dependent SoD - enforces SoD across current active sessions and previous (historical) sessions

• Tasks Ti and Tj are duty-conflict and execution-dependent tasks (Ti + Tj and Ti ~ Tj). User S executed task Ti in role Rx, and role Ry is authorized to perform task Tj. User S can activate Ry , but user S cannot execute task Tj in role Ry .

Dynamic SoD for duty-supervising tasks

• Users SA and SB activate roles Rx and Ry to execute task Ti and Tj, respectively. If Tasks Ti and Tj have a duty-supervising relationship, Ti > Tj, role Rx must have a higher position than role Ry.

Execution-dependent SoD for duty-supervising tasks

• If user SB has executed task Tj in role Ry ; SA activates Rx to execute task Ti; tasks Ti and Tj are duty-supervising and execution-dependent tasks, then role Rx must have a higher position than Ry .

Authorization model for workflows
Role-task planning algorithm

• The algorithm first invokes the GenExecDependency( ) function to generate the execution dependency among tasks of the workflow W.
• The algorithm then invokes the recursive function RoleAssignment( ) to generate the
  set of all valid role-task assignments in the input workflow.
• Initially, valid_roles(Ti) is the set of roles that are capable to execute the current task Ti.
• According to the roles previously assigned to tasks and the SoD constraints, roles that are not valid to activate Ti are excluded from valid_roles(Ti).
• Considering each previously assigned task Tj, where Tj and Ti have execution
  dependency (Tj ~ Ti), valid roles for task Ti must exclude the roles assigned to Tj that has a duty-conflict relationship with task Ti (Tj + Ti).
• Moreover, if Ti and Tj have a duty-supervising relationship, Ti > Tj, then valid
  roles of task Ti must have a higher position than the role assigned to Tj.
• After the SoD verification has been conducted, valid_roles(Ti) is the set of roles that can validly activate the current task Ti.
• The while-loop considers each role in valid_roles(Ti) as a seed to explore possible role-task activation plans by recursively finding role assignments for the subsequent task Tk in Tlist.
• If the current task is the last task in Tlist, then a valid role-task assignment of
  the workflow has been found.
• A new RTplan, an list, is created to record the role
  assignments according to the assigned-role(Tj), for each task Tj in Tlist. The RTplan is added to the AllRTplans.
  
• If no valid role-task assignment is found, then the algorithm returns a failure; otherwise, it returns success.

AND/XOR split structure (a little unclear what this is)
AND-SPLIT structure splits the workflow execution into multiple parallel paths (tasks) that are all executed.
XOR-SPLIT structure splits the workflow execution into multiple mutually exclusive alternative paths (XOR-paths), only one of which is executed.

• Tasks in different XOR-paths are not executed in the same workflow instance. Thus, no execution dependency exists among tasks in different XOR-paths.

User-role task planning algorithm

• The algorithm primarily invokes the recursive function UserAssignment( ) to find a valid user-role-task assignment of the input workflow based on the valid RTplan generated by the role-task planning algorithm.
  • The UserAssignment( ) function determines valid user assignments for current pair by recursively finding user assignments for subsequent in
    RTplan.
  • The assignments must satisfy the SoD constraint that no duty-conflict (duty-supervising) tasks are assigned to the same user.
    
• If no valid user-role-task assignment is found, the algorithm returns failure; otherwise, it returns success.

Plan-adjust algorithm

• The workflow engine may store some RTplans in advance, without storing a URTplan. The user assignments are then determined in run-time to enact each task, using the
  user-role-task planning algorithm.
• An alternative approach is to store some RTplans and some URTplans in advance. The enactment of a workflow is based on the chosen activation plan.
  

The plan-adjust algorithm is invoked when the planned user, assigned to activate the current task, is not available, or when the run-time activation of the current task by the planned user violates the constraints of dynamic SoD variations.

• The URTplan-adjust( ) algorithm finds another valid URTplan, called NUplan, from URTplanSet, where NUplan follows the actual activation of task Ti, , for i = 1 to k - 1, such that the activation of current task Tk , , satisfies the constraints of dynamic SoD variations.
• The RTplanadjust() algorithm finds another valid RTplan, called NRplan, from RTplanSet, where NRplan follows the actual activation of task Ti, , for i = 1 to k - 1.
• The algorithm then finds a valid URTplan, called NUplan, based on NRplan and the actual activation of task Ti, , for i = 1 to k - 1, by invoking the UserAssignment(NRplan; Rk ; Tk) algorithm.
• The activation of Tk , , in NUplan, must satisfy theconstraints of dynamic SoD variations.

Conclusions

• First, the proposed system requires that enterprises plan the capabilities of roles and users in advance. However, enterprises may not have clearly identified the capabilities of roles and users. The policy of SoD may not be specified in organizations. To implement the proposed system in enterprises, a re-engineering process is required to adjust organizations’ operational procedures for specifying roles, users and security policy. Accordingly, the proposed system is more complex and increases the workload required for security validation.
• Second, the proposed system enforces a strict security control. In practice, an enterprise may require flexibility to adapt to dynamically changing business environments. Strict authorization enforcement can achieve SoD and thus prevent fraud, by sacrificing flexibility and convenience.