Identity and Access Management

2010

RBAC model in SAP and Identity Management Advanced Design for IBM Tivoli Identity Manager

Gennadiy Krivdyuk- Consultant

Draft 1.1

Steps to Review and Implement RBAC

1.Overview Role Based Access Control……………………………………………… 3

2.Consideration of Role Based Access Control……………....................................................................................................5

3. The Role modeling challenge………………………………………………………....8

4. Role Based Access Models Overview……………………………………………….11

5. Statement of the Problem……………………………………………………………..14

6. Roles in Service Organization………………………………………………………..15

7. Access Control Principles……………………………………………………………..15

8. The Implementation and Conversion Program……………………………………..15

9. Migration Plan…………………………………………………………………………..18

10. Implementing the Pilot Program……………………………………………………..19

11. Security AIX management overview………………………………………………..20

12. RBAC in Oracle (RDMS)…………………………………………….......................29

13.Role Based Access Model for SAP………………………………………………….35

14.Policy-Based Authorization…………………………………………………………..43

15. Business Processes………………………………………………………………….47

16. Business Policies……………………………………………………………………..47

17. The RBAC pattern as an extension of the Authorization pattern………………..48

18. Role-Based Access Control (RBAC) pattern………………………………………51.

19. Implementing and Modelling Roles in ITIM…………………………………………52

20. Separation of Duty in Role Based Access Control System………………………67

21. References……………………………………………………………………………..71

1. Role Based Access Control Overview

A role based access control policy is the control decision of a user to allow the action within organization. It is the form of mandatory access control, seeing the security supervisor is answerable to enforcing policies and users cannot pass access permissions on to other users. A role answer-ability act as best by acknowledge of operations (privileges) that a user or agree of users answerability bring about within an organization. An ambition director allocates authorized operations to objects the roles. Besides, membership of users influence a role is again amen and revoked by a security executive on the basis of user’s specific task responsibilities and qualifications.

Why RBAC is Useful?

RBAC is a model that creates an organization-centric abstraction of access control.The role is fundamental semantics that bases of access control policy. Using RBAC thesystem administrator will give the job to user that performs in enterprise level with access permission and authorization. Assigning roles to the user based on user responsibilities and their qualification. The benefit for administrator in enterprise level specifies the security policies that cannot be getting other access control and to dramatically make more efficient the typically onerous process of access management

The role security in the enterprise level lies in its perseverance with in enterprise computing example. The permission linked with role will change as the function with in the enterprise changes over time. Membership within the role may be clearly defined and created with user roles and assigning position. But the idea of the role is relatively constant .For example the bank may have constant turnover between checker and duties of checker that is changed over time. But the idea of the checker is remains same. Roles can be used to specify capability, dependability, and power task within the enterprise level [19].

As we know the RBAC supports the application level. Traditionally the application levels have used RBAC at the internal level within existing operating system and environment offers little application level with RBAC support. The RBAC has ability to relation between role, between roles and permission, and also between roles and user. For example two roles can be established in the same time but two users cannot do both roles at the same time. Roles required inheritance relation where one role inheritance assigned permission in the different role.

The access control policy is the quality and idea component of user-role, role-role and role-permission. These components show that which particular user has assigned the role for the particular systems. The role-role relation defines the security like separation of duty and group of authority [20].The role permission is predefined which means that assigning the role to different user with some permission. It is less technical to assigning the user roles as compare to assigning the permission role. Without RBAC it is very difficult to assign what permissionis to access on which users.The RBAC has directly assigned the role whether they are directly or indirectly by the system administrator.

The policy obeys the given system result from the particular configuration of RBAC component that directly by the system administrator, because the access control system

policy is change over the system life cycle [20].

The RBAC supports three-security level.

• Least privileges:

Only those permissions are required to the user that is to be performed within organization.This means no more privileges to the user that is necessary to perform his and her job function. It is the principal that controls the individual user having the ability to takeunnecessary actions, which is harmful to the granting ability to perform desired functionsThe question is that how can we assign the set of permission in the combination of function and duties to correspond user or as a role of user subject acting on behalf of user [21]. Least privilege provides the clear thought to separation of boundaries that is provided by access control.

• Separation of Duty:

Mutually exclusive role to complete the task like in the bank the clerk and account manger participate to issuing the account.

• Data Abstraction:

Read, write, execute operations which providing by the operating system. Abstract permission like credit and debit account can be created.

The key elements of RBAC are:

USERS:By definition, users are individuals who perform one or more job functions withinan organization.

ROLES: In a business context, roles represent job functions and related responsibilities.Responsibilities represent users’ implicit or explicit authority to execute their job function.In a technology context, roles represent a collection of entitlements that a person inheritsfrom an application perspective to perform a job function.

PERMISSIONS:In a technology context, a permission is the provision of authority to someone to performan operation against an RBAC-controlled object within an application or system.

In computer systems security, role-based access control (RBAC) is an approach to restricting system access to authorized users.

It is a newer alternative approach to mandatory access control (MAC) and discretionary access control (DAC). [1]

RBAC is sometimes referred to as role-based security. RBAC is a policy neutral and flexible access control technology.

Picture 1

Identity Manager includes a complete infrastructure for managing user entitlements using roles -- i.e., RBAC (role-based access control):

Define Roles:

Administrators define roles in Identity Manager as collections of:

Login accounts on specified target systemsMembership in groups on target systems

Role Hierarchy:

In addition to entitlements on target systems, roles can include other roles. This allows organizations to define:

Technical roles, consisting of entitlements on target systems. Business roles, consisting of other roles

Mandatory and Optional Components:

Roles can contain both mandatory and optional entitlements. Users who are assigned a role will, in general, be assigned all of the mandatory elements in a role. In addition, users who have been assigned a role may request any of its optional components, whichwill be granted without need for additional approvals.

Role Assignment:

Users can be assigned zero or more roles:

Some users can be outside the scope of the RBAC infrastructure. Other users can be assigned exactly one role, representing their singular job function. Still other users can be assigned multiple roles, representing multiple job functions.

Role-based Change Requests:

Requests to create new user profiles can specify a role -- either instead of or in addition to other entitlements that the new user should be provisioned.

Requests relating to preexisting users can include role changes. Role changes may cause entitlements to be added, removed or left in place.

Approved Exceptions:

Some users may have a legitimate reason to retain privileges beyond those called for in their assigned roles or may not need all of the privileges in that role. Identity Manager supports users who remain legitimately out of compliance, through approved exceptions.

Controlled Enforcement:

Users can be flagged for RBAC enforcement. This means that any entitlements they have in violation of their assigned roles -- either too many or too few -- can be detected and automatically remediated.

Cascading Changes:

When user profiles are changed out of compliance, making them non-compliant with their assigned roles, or when role definitions are changed, making all member users non-compliant, an included RBAC enforcement engine can be run periodically (typically every 24 hours) to detect the compliance problems and automatically submit workflow change requests to bring users back into compliance.

One of the use cases this supports is cascading role changes: a privileged user can change a role's definition and commit the change. On the next automated enforcement run, the RBAC automation engine will automatically submit workflow requests to bring users into compliance with the new role definition. These requests may be auto-approved (depending on Example Corp. ID Systems customer's policy), which means that they may be applied to target systems immediately.

Gradual Deployment:

It is impractical to deploy RBAC enforcement to every one of a large population of users,all at once. To avoid this, Identity Manager supports gradual activation of users for RBAC enforcement, allowing time to educate users about the new system and troubleshoot errors in the RBAC model for a few users at a time.

Role-Aware Access Certification:

Identity Manager supports certification of user entitlements at several levels of granularity:

Fine-grained entitlements assigned to users -- many checkboxes, based on data pulled directly from target systems. Roles assigned to users -- fewer checkboxes, representing groups of privileges. Approved exceptions to the privileges predicted for a user by policy, where the policy may be role assignment or a segregation of duties rules.

2. Consideration of Role Based Access Control

When defining an RBAC model, the following conventions are useful:

• S = Subject = A person or automated agent • R = Role = Job function or title which defines an authority level • P = Permissions = An approval of a mode of access to a resource • SE = Session = A mapping involving S, R and/or P • SA = Subject Assignment • PA = Permission Assignment • RH = partially ordered role Hierarchy. RH can also be written: ≥ (The notation: x

≥ y means that x inherits the permissions of y.) • A subject can have multiple roles. • A role can have multiple subjects. • A role can have much permission. • A permission can be assigned to many roles.

A constraint places a restrictive rule on the potential inheritance of permissions from opposing roles, thus it can be used to achieve appropriate separation of duties. For example, the same person should not be allowed to both create a login account and to authorize the account creation.

Thus, using [1] set theory notation:

• and is a many to many permission to role assignment relation.

• and is a many to many subject to role assignment relation.

•

A subject may have multiple simultaneous sessions with different permissions.

RBAC - With RBAC (Role-Based Access Control), security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, and each role is assigned one or more privileges that are permitted to users in thatrole. Security administration with RBAC consists of determining the operations that must be executed by persons in particular jobs, and assigning employees to the proper roles. Complexities introduced by mutually exclusive roles or role hierarchies are handled by the RBAC software, making security administration easier.

Picture 2 [1]

As organizations increase the functionality and information offered on internal and external networks, controlling access to information and other resources becomes more complex and costly. In addition, security failures can disrupt an organization’s operationsand can have financial, legal, human safety, personal privacy, and public confidence impacts.Access control systems within a computer network are used to control the actions, functions, applications, and operations of legitimate users within an organization and protect the integrity of the information stored within the systems.

RBAC is a model that creates an organization-centric abstraction of access control.

Using RBAC concepts, administrators can focus on properly assigning access permissions to roles rather than to each individual user, thereby relieving much of the risk of error. Individual users are in turn assigned to roles, which help to streamline the provisioning processes.RBAC enables business control of access to business assets through the assignment of the appropriate users to the appropriate business roles. This RBAC abstraction allows for easier administration, delegation, and maintenance.

• Improved manageability of access control• System-independent and streamlined management of account authorizations• Possibilities for implementation of ownership and delegation of authority• Enhanced efficiency of support staff• Accelerated auditing and review through business-oriented views on access

control•

One of the principle purposes of RBAC is to provide a cost effective and more accurate approach to the management of access control data. However the deployment of RBAC can potentially result in the creation of a large number of roles, which in turn need to be administered.

The challenge in deploying RBAC is to replace the very complex issue of access control management, with a less difficult but still significant issue of managing roles.

How does RBAC complement Provisioning?

Provisioning is the process of feeding the local access control systems with the information they need to enforce permissions on users. Provisioning is independent of the model that is used to structure this information. As such Provisioning can work with almost any known model, going from the most simple model (e.g. request-based), over abstract models (like RBAC) to the most complex models (e.g. rules based). The main reason behind the existence of all these different models is that there isn’t any “one size fits all” model. Technical, political, organizational, and financial and other factors influence which model is best suited for an organization.

So, how do we find out which Identity Management model our organization shouldchoose?

Request-based Provisioning works, no doubt about that, but efficiency is challenged in an organization with several thousands of employees. Recurring requests can be reduced or even eliminated by abstracting them into a role. However, in the long run an organization will very likely be confronted with the fact that it will end up with too many roles, conflicting roles or too restrictive roles. Roles can be made more flexible and their number reduced by extending them with rules; rules that control e.g. separation of duty and temporary assignment and activation.At the core of our model, there will always be roles. In very simple models rolesmight be hidden to the extend that we don’t even realize that we have them. E.g. a local group on a target system is a role. In most cases it is not an organizational or functional role, but it still is a role. Often we call them technical roles. In other situations the role model can be very visible. E.g. organizations with complex structure will very likely have a deep hierarchical role model.Note that so far I have not yet mentioned meta-directories. The discussion of “provisioning” versus “meta-directories” is not relevant. Basically both are simply other ways of synchronizing data between different repositories and as such only provide the technical foundation of your identity management system.It is the identity management model that sits on top of this foundation that will be responsible for the way an organization manages access control data. Because this document was produced in the context of ITIM, which is a provisioning based identity management system, I will only refer to provisioning in the remainder of this document, though the scope is of course also valid for meta-directories.The following picture illustrates how a layered identity management approach can make sure that the identity management model can be made independent of the underlying target systems and synchronization mechanisms.

Role modelling is an adaptive process and can only be successful if the underlying provisioning technology that visualizes the result of the model is flexible enough so that itcan be tailored according to the identity management needs of an organization.

ITIM is probably the only identity management product on the market today that providesthis flexibility.

The core of ITIM is a framework that provides an Identity Management Foundation on which almost any identity management model can be built. And, as businesses evolve, ITIM also allows your identity management model to evolve accordingly.Secure IT Role Manager is an ITIM plug-in that helps organizations to streamline the modelling and remodelling of their identity management system.

3. The Role modelling challenge

The basic component in the model is core RBAC. Core RBAC defines a minimum collection of RBAC elements, element sets, and relations to completely obtain a RBAC system. In core RBAC, all access policies are formulated around the concept of roles. Users are made member of roles, and permissions are associated to Roles. ‘Permission’ in this sense means an “allowed” operation on an object. The link between a user and a role is referred to as a ‘role assignment’ in this document..The major purpose of core RBAC is to facilitate management and review of access control data. The relationships between the different elements in core RBAC are represented in the following Picture 4:

Users RolesPermissionsOperations Objects

Picture 3

An extension to the basic component of the model is hierarchical RBAC. Hierarchical RBAC adds the concept of a Role hierarchy. A Role hierarchy allows users to inherit permissions from Roles that are junior to their assigned Roles. The link between a senior role and a junior role is referred to as a ‘junior role assignment’ in this document

.Through the creation of Role relations, administrators are better able to formulate accesspolicies in terms of organization-specific functions and business structures. For instance the permissions that are authorized for a Role can be decomposed into lower-level Roles representing the functions, duties, and tasks that comprise the Role. Once these lower-level Roles are created, they may be reused in the creation of higher-level Roles.The benefits of planning and constructing a Role hierarchy include increased administrative productivity in the distribution, review, and revocation of permissions as well as the ability to better specify and analyze access control policies. The relationships between the different elements in hierarchical RBAC are represented in the following Picture 4.

Picture 4

The goal of separation of duty is to prevent that a single user can solely perform all stepsof a business process, from start to end. To enforce this, separation of duty puts restrictions on the assignment and activation of roles to persons.

Static separation of duty is most commonly implemented in RBAC tools using mutual exclusion relationships. These relationships define, on a role level, which roles cannot (and can never) be combined with each other by one person.

Static separation of duty is related to role assignment administration:

at the time of the role assignment, the separation of duty rules are checked and enforced. So, because static separation of duty prevents that users can be assigned to 2mutual excluded roles, the user will never be able to use these roles together.

Dynamic separation of duty takes into account the context in which a role is activated: the dynamic separation of duty rules are queried and enforced dynamically at the time the user needs to activate a certain role, resulting from an authorization request. For 2 roles that are mutually excluded, dynamic separation of duty might allow one of theroles to be activated in one context for a certain user, while allowing the other role to be activated in another context.

So, basically, dynamic separation of duty allows for more flexibility in applying separationof duty constraints. Static separation of duty is typically a challenge that can be tackled in an RBAC-oriented identity management tool because those tools are typically declarative of nature, and deal with constraints on role assignments.

Dynamic separation of duty is an access management issue because it requires that a central 'role server' should be queried at the time an authorization decision needs to be taken.

The following sections will describe real-life examples of situations to make clear that concepts like support for temporal constraints, role owners and approvals of role assignments and changes to role definitions aremandatory functionality for RBAC tools.

As one moves from one department, place or function in the company to another, his permissions should change in relation to where he is and what he does at a given time. One of the main advantages or goals of RBAC implementations is to put as much permission as possible into roles that are linked to organizational entities, functions or tasks in the company.

Consequently, as one moves around, those permissions will be automatically added or removed, in accordance to the roles that one acquires or looses. However, in practice, most companies don’t want to create a ‘big bang’, but prefer to have removed permissions only Role Manager RBAC for Tivoli Identity Manager fades out gradually over time. In this way, a person can still perform the tasks or function(s) he had previously for a per-determined amount of time, until the associated role has faded out.

A similar requirement comes up when dealing with so-called ‘project roles’ : as a project typically has a predetermined start and end date, the associated project roles can only be assigned and activated during the life-time of the project. Equally, when one needs toperform as back-up of someone else, the permissions of the back-up should only be granted during the assignment period.

Taken together, these requirements collectively call for support of temporal constraints by Role Administration and Management tools.Introducing RBAC typically has organizational consequences – as roles are introduced, the question comes up: who needs to approve the assignments of roles, or what if the role definition needs to be changed?

In most companies, this organizational thinking process gives rise to the creation of a new organizational function: “role owner”. Not all companies apply however the same meaning to the role owner concept:

• some want the role owner to approve all role assignments

• some want role owner approval only for roles that are marked as ‘exceptional’ or ‘special’ - some require multiple approvers, including the role owner, to be contacted in case of specific role definition changes or role assignments

• some allow delegation of role ownership to ‘role managers’ – both for role administration and approval

Role Administration/Management tools should therefore include possibilities to define custom approval cycles, to allow role owners to be defined, and to model the responsibilities and duties of a role owner, depending on the actual context

4. Role Based Access Models Overview [4]

.

[4]

[4]

RBAC also provide administrators with the capability to enforce specific policy of dynamic separation of duty (DSD). Static SD provides an organization with the capabilityto address potential conflict of interest issue at the time a user’s membership is authorized for a role. With DSD it is permissible for a user to be authorized as a memberof set of roles which do not constitute a conflict of interest when acted in independently, but produce policy concern when allowed to be acted in simultaneously.For example, a user may be authorized for both roles and Cashier Supervisor, where thesupervisor is allowed to acknowledge corrections to a Cashier’ open cash drawer. If the individual acting in the role Cashier attempted to switch to the role Cashier Supervisor, RBAC would require the user to drop his or her Cashier role, and thereby force the closure of the cash drawer before assuming the role Cashier Supervisor

Figure 4

5. Statement of the Problem

Assuming each user will be unequivocally authenticated and identified; only a single entitlement system will be operated in the future.In order to complete this task your team must:

• Develop a role based access control model.• Complete both the business requirements and the technical requirements.• Construct and implement a migration plan.

6. Roles in Service Organization

Within the company, these “jobs” occupy a defined organizational hierarchy and control structure. Typical roles include sales manager, production supervisor and call center manager. The underlying forces determining these “jobs” have evolved over the history of the firm and the industry it competes within. Institutional structures can be attributed tomarket activity, regulation, privacy, financial control, accounting standards and other influences. Correspondingly, the customers (these customers are assumed to be organizations) have also delegated responsibility and resources to well defined “jobs”. These “jobs” include purchasing managers, account payable clerks and accounts receivable clerk.

The roles and responsibilities for these individuals are often mirrored within systems thatthey use at their firm.

7. Access Control Principles

The access control principles represent the fundamental business philosophy concerning a user’s access to system resources. The concepts are expressed within the following requirements:

• An access control systems must follow the principle of least privilege.• A role, hence the user, must be granted access to each resource in an additive

manner. A role must not be given access to additional resources unnecessarily.• An access control systems must provide for logical separation of duties

.The system must allow for role construction that can represent the firm wide business functionality and operating hierarchy. The entitlement system must be able to provide each user with access to resources that are “job” related. The system must also use propositional rules (constraints) to disallow user’s access to conflicting roles.An access control systems must follow the principle of finite access time.Each resource covered under the entitlement system is available to each user for only a finite period of time. Duration of access for each authenticated user must be described as a resource attribute. Access can be controlled either by absolute time limits or user idle times.

8. The Implementation and Conversion Program

The current legacy systems (with one exception) use a discretionary access control system (DAC or “Sushi Menu System”). The migration team acknowledges that role engineering and conversion procedure will be iterative. The migration from this multi-factor model to a hierarchical model follows the following steps:

• Gather data on all users and resources.• Create cross probability matrix for each user’s resource entitlements.• Create an access coding (binary) system for each resource and action.• Assign access code to each user and create code histogram.• Drop all sparse elements.• Create code subsets of broad base (many resources) codes.• Create an initial role data model.• Assign users to initial roles assuming a small, unallocated remainder.

Examine unassigned users and create exception rules. Following initial process, the population of about “XXXX” (It needs to be define) is reduced to a population of about “XXXX” (It needs to be define) users that don’t fit the initial role model. The exempt

population needs to be worked either into existing or newly created roles. This stage is followed by subsequent iterative procedures:

• Create histogram of the outlying subpopulation• Build model with the selected codes.• Examine excluded values and see if the access required is operationally unique.• Refine model with excluded codes.• Look to condense codes

Histogram example

Other example Histogram

In a more general mathematical sense, a histogram is a mapping mi that counts the number of observations that fall into various disjoint categories (known as bins), whereasthe graph of a histogram is merely one way to represent a histogram. Thus, if we let n bethe total number of observations and k be the total number of bins, the histogram mi meets the following conditions:

Cumulative histogram [2]

A cumulative histogram is a mapping that counts the cumulative number of observations in all of the bins up to the specified bin. That is, the cumulative histogram Mi of a histogram mi is defined as:

Number of bins and width

There is no "best" number of bins, and different bin sizes can reveal different features of the data. Some theoreticians have attempted to determine an optimal number of bins, but these methods generally make strong assumptions about the shape of the distribution. You should always experiment with bin widths before choosing one (or more) that illustrate the salient features in your data.

The number of bins k can be calculated directly, or from a suggested bin width h:

The braces indicate the ceiling function.

Sturges' formula [5]

which implicitly bases the bin sizes on the range of the data, and can perform poorly if n < 30.

Scott's choice [6]

where σ is the sample standard deviation.

Freedman–Diaconis' choice[7]

which is based on the interquartile range. A good discussion of this and other rules for choice of bin widths is in [8]

9. Migration Plan

Once the roles are settled and the exceptions identified, the Example Corp. creates a migration team (conversion team). The migration team now finalizes a conversion workflow. The majority of the users can be migrated automatically. The remaining users need to be handled manually. This task is assigned to customer service under the supervision of the migration (conversion) team. The philosophy during the migration phase posits many small, measured steps as opposed to a large, simultaneous rollout. The operation will begin with converting current users into the system directory. Themigration phase ends with the retirement of a legacy systems and the full production operation of the new, integrated system. Imperfection in the process require an iterative and sometimes, manual process.The migration planning also relies on the architecture and design of the new system. This is a key factor for relocating users to the new system from the legacy systems and minimizing disorientation. The review of the legacy system will help manage expectations of current users on the new system. A concept of operations (Con-Op) describing the new system from a user point of view will be provided to all customers.Prior to initiating the conversion process, the user migration team provides users a (n):

• List of system goals and objectives• Explanation of system functionality• Explanation of non-functional features (performance, security,

interoperability)• Documentation of new relevant regulations, policies, standards and

business rules• User manual and training aids.

10. Implementing the Pilot Program

The pilot is actually a focused migration effort for a small population of user. The pilot program is not a marketing demo. Feedback for possible user interface changes is also examined for possible updates. The pilot program will act as the final confirmation stage for the technical architecture and design.

A) Consistent Client Experience

Authenticated users are able access all entitled resources without challenge. The user isnow assigned a consistent role(s) during the provisioning process. A user’s role will also influence the navigation and screen layout features on all entitled applications. The rolesare engineered to provide each user with the resources they need to perform their duties. The only valid challenge to an entitled resource is related to a resource time-out. For cases of resource time-out, the user must re-validate their credentials to update thesession time-stamp.

B) Access Control Clarity

The entitlement system now encompasses and protects all systems exposed outside thefirm. The system now acts transparently and provides the administrators a clear report on the resources, actions and subjects each user is entitled to. The access control policies that restrict a user’s activity are now referenced for each resource denial. The system now stores all access control policies in a central location. Access to these policies is provided to dependent systems that also enact these policies. Administrators and dependent systems are able to query the system independently.

C) Concentrated and Reduce Costs

Business planning, project management and expense recoverywere also spread across many internal departments Exact accounting of services and infrastructure vary from department to department. Now the firm has a single, consolidated service agreement and expense statement for the entitlement system. Reporting of development, supplier and operating costs are now itemized and detailed within a single invoice. Moreover, provisioning personnel are now 4 to 7 times more

productive.

D) Conclusion

Following the migration plan, were successfully converted to a new access control system that operated above a single, enterprise system. Users could now be added within a much shorter turn around time. Furthermore, access to specific applications not only became logical, but audit and other compliance personnel now had a clear understanding of all access rules. Moreover, the number of access assignment errors was dramatically reduced. Utilizing the role based access control system, operating and oversight cost were lowered.

11. Security AIX management overview [9-14]

• Traditional • RBAC

Traditional

One can use the DAC (Discretionary Access Control) to control access to the data (in a process/file relationship). However, the root user, who has all the privileges, is considered to be the sole user. The root user succeeds any access control and performsany operation that it wants to do. This can pose a major security threat.

Moreover, the root user plays many roles like system administrator, security officer to maintain security policy, and systems operator for day-to-day activities. It is the single user which controls the system and the system as such does not have any control over the activities within the system.

RBAC distributes the root user's roles and authorization to more than one user. This article shows how RBAC provides enhanced security to the system.

RBAC

Traditional AIX systems have a limited set of authorizations that can be used to determine access to certain administrative commands. The following example shows that the passwd command is the setuid program, which has the authorization and privileges to be executed as a non-root user. It is also able to modify the /etc/security/passwd file as a non-root user. DAC does not allow this.

setuid programs like the passwd command

$ ls -l 'which passwd'-r-sr-xr-x 1 root security 40014 May 07 2008 /usr/bin/passwd

# ls -l /etc/security/passwd-rw------- 1 root security 467 Mar 10 23:48 /etc/security/passwd

This opens up a major risk of anyone who gets control of the root shell through malicioussetuid programs can then do anything they want.

Prior to AIX version 6, portions of root-user authority could be assigned to non-root users. Different root user tasks (commands) are assigned different authorizations. Theseauthorizations are grouped into roles and assigned to different users:

• Tasks -> Authorization • Authorization -> Roles • Roles -> Users

But the root user is still the sole boss. Anyone that can get access to root can do anything.

Starting with AIX release version 6, the role-based access mechanism is been enhanced.

• root access can be disabled. • root tasks are assigned to three system-defined users. • Privileges, authorization, and roles are assigned as per the users' responsibility.

In this way, the single path to destruction is avoided.

How do authorization, role and privileges work?

• Authorizations are assigned to commands• Roles are assigned to users. • Privileges are associated with specific processes. • Explicit privileges are assigned to commands required for execution and their

execution is governed by authorization.

The system has a pre-defined authorization to certain commands and roles for system-defined users.

Further, a user who is considered as administrator can provide an (user-defined) authorization to an executable program and assign the authorization to a role. Each useris assigned a role.

Hence, a user with a defined role should be able to execute any authorized command.

shutdown command

Command: ShutdownAuthorization: aix.system.boot.shutdown Role: isso, soPrivileges: Root privileges

Should a user with information system security officer (ISSO) or a similar role be able to execute shutdown?

Should a user with information system security officer (ISSO) or a similar role be able to execute shutdown?

The answer is “Yes”. The user should have the roles authorized to them to execute shutdown. From the previous example, you can understand that only the user who has the roles, authorization, and privileges should be able to execute shutdown.

Is it possible that a malicious user can get the role of ISSO and use his own shutdown program to attack the system?

Is it possible that a malicious user can get the role of ISSO and use his own shutdown program to attack the system?

The answer is No provided if the isso role is not assigned intentionally. Since the malicious user in this case will be malicious administrator who does NOT have complete authorization to do whatever he wants.

Here the point to understand is that only a user with administrator authorization can assign authorizations and roles. Anyone who gets control of the administrative user maliciously cannot do anything, since the administrator alone cannot do anything destructive.

Only certain users are allowed to do certain actions. The onus on a single user root is delegated. In this way, higher security is achieved.

System-defined authorizations are prefixed with aix in the authorization hierarchy (as shown in previous example, which may not be modified or removed).

What happened to the root user?

Who replaces the roles of the root user?

You have the option of disabling the root access to the system and performing all tasks through one or more user accounts.

AIX V6 has three pre-defined roles assigned to three pre-defined users:

• ISSO, the Information System Security Officer • SO, the System Operator

• SA, the Security Administrator

The roles and authorizations of these users are defined in the following table:

Table 1. The pre-defined roles for the pre-defined users

User Roles Responsibility

ISSO ISSO

• Establishing and maintaining security policy • Setting passwords for user • Network configuration

• Device configuration

SO SO

• System shutdown reboot • File system backup, restore, and quotas • System error logging, trace, and statistics

• Workload administration

SA SA

• User administration excluding password • Filesystem administration • Software Installation and Update

• Network Daemon management and device allocation

Commands and examples

The following table shows the command details in the order of how authorization and roles can be used.

Table 2. Command details

Tasks Command

Creating authorizationmkauth (auth_name) OR smitty rbac-> Authorizations-> Add an Authorization ->Authorization Name

Verifying authorization lsauth

How to associate a command with authorization:

setsecattr -c accessauths= (auth_name) (command)

Creating Roles mkrole authorizations= (auth_name) (role name)

How to associate the role to a user?

chuser roles=(role_name) (user name)

Update the kernel tables using setkst

When the roles become active?

rolelist -a [To verify the roles associated with the user with which the session is logged in]

swrole (role_name) [switch to activate the role ]

rolelist -e [To verify which role is active in the session]

Use the following example to understand the command:

How to execute the shutdown command as testuser

Step A: Creating and assigning (user defined) Authorization and Roles:mkauth test_authsetsecattr -c accessauths=test_auth shutdownmkrole authorizations=test_auth test_rolechuser roles=test_role testusersetkst

Step B: Execution

Login as testuserSwitch to the role test_role using the following command:swrole test(prompts for testuser password )verify whether the testuser has the role using the following command:rolelist -eThis displays the role associated as test_role

Execute shutdown command

So far, I have shown how authorization and roles are used. The previous example explains how a non-root user can be given authorization to execute commands such as shutdown. This example is shown to explain the usage of RBAC. Giving authority to a non-root user to execute commands like shutdown is not suggested or recommended. Further, following this example shows how creating the user and setting the password for the user is not a single-user responsibility. You need more than one role (users) to create and set a password for the user.

How to create, modify, and set the password of a user

1.login as isso2.swrole isso3.mkuser (user_name)4.login as so

5.swrole so6. passwd (user_name)

This shows how the roles and authentications are distributed and how it is difficult to tamper the activities without the proper authorization.

How to mount a file system

1login as issoa.swrole isso

2.mount the filesystema. mount: Write permission is required to mount over /mnt. - FAILS

3.login as soa. swrole sob. mount the filesystem

c. verify the mount with df command. - SUCCEEDS

In this way, you delegate the root responsibility to other users and reduce the security risk.

To summarize, authorizations can be assigned to an executable command. Roles are assigned to users and users having the defined role should be able to execute. On top ofRBAC Authorization, it checks for DAC permission. To bypass DAC, privileges are required.

Privileges:

So far, you have seen how authorization and roles play a role in enhancing the security of the system.

Now, you will see how privilege is part of this security system.

• Privileges are for the process to bypass certain (kernel) restrictions while executing an authorized command.

• Privileges are for the commands and process to access the files, even if it has the required authorization.

• Privileges provide device access control.

In short, the operating system uses authorization to determine eligibility before performing a privileged operation like system calls.

Examples of privileges

lsconf example

lsconf - is not a privileged command, it has no authorization to perform a privileged operation. Access permission as per DAC.

It has the following DAC permission:

# ls -l 'which lsconf' -r-xr-xr-x 2 root system 12712 Mar 14 2010 /usr/sbin/lsconf

In this case, whoever has the DAC privilege should be able to execute lsconf. Interestingly, the lsconf command internally executes commands like bootinfo, which is aprivileged command. This means that the user needs an authorization and privileges to execute bootinfo. Hence, a user who does not have the required authorization will fail to execute bootinfo.

bootinfo example

Command: bootinfo -k

Authorization and Privileges:

$ lssecattr -c 'which bootinfo'

/usr/sbin/bootinfo accessauths=aix.system.boot.info innateprivs=PV_DAC_R,

PV_DAC_W,PV_DEV_CONFIG,PV_KER_RAS,PV_MAC_,PV_MIC secflags=FSF_EPS

DAC permission:

$ ls -l 'which bootinfo'-r-xr-x--- 1 bin bin 13984 Mar 14 2010 /usr/sbin/bootinfo

In this case, the user with the authorization aix.system.bootinfo, assigned through a role,should be able to execute the bootinfo command. However, DAC does not allow the file to be executed by any non-root user.

Is it possible to execute a command by a user who has the required authorization but no DAC permission?

Yes, it is possible if the process has the required privilege to execute the command. In this case, as the previous output shows, bootinfo has PV_DAC* privileges.

The following command shows the privileges associated with the shell:

$ lssecattr -p $$

282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=

Editing /etc/hosts file

"/etc/hosts" does not exist in the privileged file database.

This is not a privileged file. Hence, whoever has DAC access should be able to edit the file.

$ ls -l /etc/hosts

-rw-rw-r-- 1 root system 1962 Mar 3 16:35 /etc/hosts

DAC shows except root user and users belong to system group, others do not have writeaccess to the file

$ lssecattr -p $$

282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=

Hence, in this case, DAC access is followed where the non-root user has only READ permission.

Editing /etc/environment file

$ lssecattr -f /etc/environment

/etc/environment writeauths=aix.security.user

This is a privileged file.

$ ls -l /etc/environment

-r--r--r-- 1 root system 1907 Mar 12 22:45 /etc/environmentDAC access permission shows no one has WRITE permission.

$ lssecattr -p $$282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=

The shell process has the root privileges but the vi command which is used to access the file is not privileged command. This means that vi cannot access the file even if a user has the required authorization, aix.security.user, to edit the file.

$ lssecattr -c 'which vi'

/usr/bin/vi does not exist in the privileged command database.

What is the requirement to edit /etc/environment file ?

(i) User to have the required privilege aix.security.user(ii) Executing shell to have the required privilege(iii) Command which access the file to have the required privilege

In such cases, AIX provides a privileged vi editor called pvi which has the privilege to access and write into the file.

$ lssecattr -c 'which pvi'

/usr/bin/pvi accessauths=ALLOW_ALL

innateprivs=PV_PROC_PRIV,PV_DAC_R,PV_DAC_W, PV_DAC_X,PV_DAC_O

• A privileges command has the following attribute:

accessauths,innateprivs,authprivs,inheritprivs

• A privileges file has the following attribute:

readauths and writeauths

• Privileges Device has the following attribute:

readprivs and writeprivs

Summary

This has been a tour of the RBAC features with examples and scenarios. I hope it gives you a better understanding of the advanced features in AIX, RBAC and MLS.

Table 3 Rule of thumb in RBAC

- DACAuthorizationRolePrivileges Comments

File, command,

YES NO NO NO Follows DAC permission

device

File, command, device

YES YES YES NO Follows DAC permission.

File, command, device

YES YES YES YESAuthorized user gets priority to execute privileged operations. Bypasses DAC.

• Single-user responsibility is delegated.

• Single-user does not have any authority to damage the system.

• Root access can be disabled.

12.Role Based Access Control in Oracle

The Oracle DBMS implements the notion of roles since early 1990s, and it includes support for administration of the access control state. The Oracle’s RBAC administrations have been widely used in real world, Oracle thus presents an invaluable reality check for administrative approaches to RBAC.The success of RBAC research is partially due to the fact that the notion of roles has been implemented in commercial systems, so that the research can be guided by real-world experiences. I believe research on administrative models for RBAC must also learn from existing systems such as Oracle.There are two kinds of privileges in Oracle: system privileges and object privileges. There are over 100 system privileges in Oracle. For example, the “create role” system privilege allows one to create a new role, “drop any role” allows dropping any role,“grant any role allows to grant any role to a user or another role”. An object privilege identifies an object, which is either a table or aview, and an access mode, which is one of the following: select, insert, update and delete. Oracle’s permission management is ahybrid of DAC (Discretionary Access Control) and RBAC. Privileges can be granted to users and to roles. And roles can be granted to roles and to users. A system privilege or a role can be granted “with admin option”. If a user is granted a role with admin option,then we say the user has admin power over the role. This enables the user to grant the role to other users and roles as well as to revoke the role from other users or roles. A role r1 can also be granted to another role r2 with admin option, in which case any user that is a member of r2 has admin power over r1.

A user can create a role if he has the create role system privilege and the role to be created does not already exist. When a role is created, the creator will be automatically granted the role with admin option. This enables the creator to further grant the role to any other role or user. In Oracle, if one has control over permission, then one can grant

the permission to any role; no control over the role is needed. The Oracle’s design seems more intuitive. Granting a role to a user implies giving out privileges associated with the role; thus some control over the role is needed. Similarly, granting permission toa role implies giving out the permission; thus some control over the permission (rather than over the role) is needed.

On the other hand, Oracle’s approach leads to a denial of service attack: Any user who has the “create role” system privilege can stop other users from logging in. When a user logs in, a set of roles that the user has are activated, as is any role that has been granted to one of these roles. Oracle has a limit on the number of roles thatcan be activated in a session; if a user has more roles, then the user cannot log in. Oracle has a predefined role called PUBLIC, which is granted to every user and is activated by default. Any user who has the “create role” system privilege can create a large number of roles and grant them to PUBLIC, resulting in other users unable tolog in. Oracle has a predefined role called PUBLIC, which is granted to every user and isactivated by default. Any user who has the “create role” system privilege can create a large number of roles, and then immediately delete the edge; the system should returnto the state before addition.Consider the RBAC state in Figure 2(b)(i), which contains the following relationships:Architect º Engineer. Suppose that when a product is about to be released, one wants engineers to also serve as QAs and adds a temporary relationship Engineer º QA. This change results in the role hierarchy in Figure 2(b)(ii). After the release, one wants to delete the temporary relationship, expecting the hierarchy to return to theoriginal state in Figure 2(b)(i). After all, the only reason that the Architect role dominates the QA role in Figure 2(b)(ii) is because one wants engineers to be able to serve as QAsand architects are (a kind of) engineers, and now one does not want engineers to be QAs anymore. We point out that always removing implied role dominance relationships also violates reversibility, as illustrated by Figure 2(a). Oracle addresses this problem by maintaining all relationships that have been explicitly added. The operation of deleting an edge removes a relationship that has been explicitly added. The actual role hierarchy is inferred from the relationships. This way, one can distinguish an edge that has been explicitly added from one that has been inferred, thereby maintaining reversibility.

Figure 2: Adding and deleting a role from RH

DESIGN PRINCIPLES AND REQUIREMENTS

REQUIREMENT 1

Support decentralized administration and scale well to large RBAC systems.

As RBAC’s benefits are most pronounced when used in settings with large numbers of users and permissions, we require that administrative models for RBAC are flexible enough to scale to systems of such size. This requires decentralization of operations such as creating users and roles and the ability to define meaningful administrative domains. The Oracle supports decentralized administration allows coexistence of multiple administrators having control over portions of the system.. In Oracle administrative domains are defined by explicitly enumerating objects in the domain. This works fine when the number of roles is limited, which is probably true in most scenarios in which Oracle is used. However, the administration approach in Oracle does not scale to systems that have thousands of roles.

REQUIREMENT 2

Be policy neutral in defining administrative domains.

One of RBAC’s advantages is policy neutral, so that it can be configured to enforce multiple kinds of policies. An administrative model for RBAC should remain as policy neutral as possible.

As the role hierarchy is designed for sharing and aggregation permissions, using the rolehierarchy structure to define administrative domains implies a particular kind of policy.. The roles that belong to one domain may not be related at all in the role hierarchy. Therefore, it is best to decouple administrative domains from role hierarchies. An RBAC administration model should provide a mechanism for defining administrative domains based on other concepts, e.g., organization units.

REQUIREMENT 3

Apparently equivalent sequences of operations should have the same effect.

When two sequences of operations are conceptually equivalent, their effects should be the same. A special case is when one operation can be conceptually viewed as a sequence of more primitive operations, then the effect of that one operation should be equivalent to carrying out the sequence of the primitive operations. Consideran operation that creates a role r with a set P of roles as parents and a set C of roles as children. This operation can be viewed as first creating the role r, then adding each role in P as a parent and each role in C as a child in an arbitrary order. In practice, when one creates a role, one may not be able to determine all the parents and all the children. Thus, one may want to create the role first and then gradually add the relationships.

REQUIREMENT 4

Support reversibility.

This implies two requirements. One is that most sequences of operations should be reversible; that is, given a sequence, there should exist a sequence of operations that reverse the effect of the sequence. Having reversibility, if one makes a mistake, one can go back. Certainly, not all operations are reversible; for example, operations such as deleting objects may not be reversible. However, at a minimum, operations that only addthings should be reversible. The second requirement is that if an operation has an obvious reversing operation; then the reversing operation should always reverse the effect as expected. For example, if one adds an edge between two administrations is about managing operations that change these objects.Based on the principle of economy of mechanism, it makes sense to reuse the mechanisms for managing permissions about accessing objects for managing the administrative operations, rather than introducing additional relations.

Figure 3: Role hierarchies from RBAC literature.

A lattice structured hierarchy is shown in (a). An inverted tree in shown in (b) A layered role hierarchy is shown in (c).

REQUIREMENT 5

Predictability

Given a state-change in an administrative model for RBAC, it should be obvious what the effect of that state-change is. That is, there should not be side-effects that are surprising. Otherwise, it is easier for administrators to make mistakes while carrying outadministrative operations. In SARBAC, there are automatic updates to the relation admin authority following a role hierarchy operation in order to maintain administrative scope and to eliminate redundancy. However, some of “indirect updates” have sideeffectsthat may be considered surprising. For example, in the Figure 1(a), suppose an administrative role PSO1 has control over the administrative scope of Project 1, which is {PL1, PE1, QE1, E1}. When PSO1 delete the role PL1, the original administrative scope for Project 1 breaks up into three trivial administrative scopes {PE1}, {QE1} and {E1}The system will remove the relationship (PSO1, {PL1, PE1, QE1, E1}) from admin authority, and make PSO1 have control over the administrative scopes of the intermediate children of the deleted role. It adds two relationships (PSO1, {PE1}) and

(PSO1, {QE1}) into admin authority. Surprisingly, the role E1, which is part of Project 1, becomes outside of the control of PSO1 due to the deletion of PL1, because E1 is not in the administrative scope of either PE1 or QE1.REQUIREMENT 6

Using RBAC to administer RBAC

The basic idea of economy mechanism is to keep the design as simple and small as possible. We observe that RBAC systems are used to manage permissions for accessing objects. RBAC systems themselves in turn introduce additional objects, such as users,roles, constraints, the user-role assignment relation, the permission-role assignment relation, and so on. RBAC administration is about managing operations that change these objects.Based on the principle of economy of mechanism, it makes sense to reuse the mechanisms for managing permissions about accessing objects for managing the administrative operations, rather than introducing additional relations. We call this approach “Using RBAC to administer RBAC”.However, the relationship between administrative powers and administrative roles are encoded in newly introduced relations. On the other hand, Oracle handles this quite well by using the same mechanism for managing system privileges and roles.

Practical ExampleCentral administrators are allowed to administer all Oracle objects in the system. They are especially responsible for creating and maintaining the roles, but may also carry out all other administrative tasks

Table 4: Example Administrative permission for a central administrator [17]

For example, central administrators might be allowed to administer everything except objects in the HR department. They are then authorised for the top scope node, while the HR scope is excluded. Without explicit exclusion, a lot of scopes would have to be assigned.

Table 3: Example of an administrative permission

13.Role Based Access Model for SAP

Configuring user security permissions in standard business applications (such as SAP systems) is difficult and error-prone. There are many examples of wrongly configured systems that are open to misuse by unauthorised parties. See Picture 1

Picture 6

Besides the structural data elements explained above, we need so-called instance data". Here an instance may, for example, be a real user of the system. This information is veryimportant for most of the rules one would like to evaluate. There are, of course, rules that do not need instance data (if one is checking the UML data structure model itself for some [18]

Figure 3 Simple Role Based Access Control

Roles in SAP

Problem 1: Agreement on the concept

• Common confusion between groups and roles• Different interpretations by different vendors• Proposed RBAC standard by NIST, unified ‘User –role –resource’ –view

Problem 2: Role engineering

• How to construct reasonable roles (e.g. SOD)• In practice: ‘direct’ allocations of privileges to individuals –‘quick fix’ but hard to

manage/maintain, as well as overlaps

Problem 3: Role evaluation

• Still leaves the question: what authorisations does a company require –what do they actually have in place?

Core RBAC

Picture 6

The so called Role Based Access Control (RBAC – also called role-based security) is anessential concept in SAP. [24]Role-based security is a form of user-level security where the application doesn’t focus on the individual user’s identity; but rather on a logical role they occupy.The concept of roles is important to SAP because roles offer great possibilitiesto compose structures. It is possible to create single roles as well as composite roles and even inheritance between roles is supported. The tool SAP “Profile Generator”is used to create single, derive and composite roles. The name Profile Generator comes from the fact that an authorization profile will be generated for each role and also after every change of the role. The generation is required because authorizations are only effective for a user if he/she holds them in his/her master record.If a user holds authorizations then he/she in fact holds one or more authorizationprofiles which group the authorizations.If a role inherits properties from another role then the parent role is called template (master role) role. For example, a template role can inherit the contained authorizations

to the child roles. Just like inheritance in programming languages, changes to the template role will be automatically applied to the derived roles. Template roles are often used to define roles having the same functionality (i.e. allowing to execute the same transactions), but for different organizational levels such as companycode, purchasing organization, etc.

Single Roles

The structure of a single role is similar to the authorization profile, i.e. it also contains authorization values

Figure 4 Structure of a Single Role

Whenever a single role is created using the Profile Generator the appropriate authorization profile should be generated, too. A user effectively holds only the authorizations which are present in the (generated) authorization profile which has been assigned to the user. Therefore, the assignment of a role to a user without the existence of the generated authorization profile is useless. This is due to the fact that authorization checks always and only compare the required authorizations with the authorizations present in the authorization profile of the users’ master record.

Therefore, an authorization check will fail if the required authorization is only present in the role which has been assigned to the user and not in the users’ authorization profile.A difference to the (direct) authorization profile is that changes to the authorizations of a user which are grouped in auto-generated authorization profiles must take place throughthe role definition. It isn’t possible to change values directly in (auto-)generated profiles as it is in direct authorization profiles.

Composite Roles

Composite roles are used to reduce the maintenance effort. They can bundle an arbitrary number of single roles. The structure of a composite role is shown inFig. In contrast to a composite profile, composite roles can make use of the feature of inheritance. Therefore, the structure capabilities are better for roles than for direct profiles.

The notion of a composite role is that it should reflect the position of a user with its tasks and responsibilities in a company whereas a single role holds all authorization information needed to perform one concrete task.

Fig. 5. Structure of a Composite Role

Mapping RBAC role in SAP

The process for developing RBAC based controls consists of:

• process definition• role definition• definition of the structural relationships between the roles• formulation of constraints (cardinality, SSOD, DSOD, etc)

Picture 6

Sample informal role description:

Role mining example:

Picture 7

Possible scenario for data source mapping:

Picture 8

Authorization Objects

Authorization objects are used to protect functions or data in the SAP system.

Every authorization check occurring in a transaction checks the associated authorizationobject. The object itself is a logical entity used to group one or more value fields requiring authority checking within the system. There is one up to ten value fields in one object. Each field is a container for a value. The structure just described is illustrated in Fig.

Fig 6 Authorization Object Structure

Authorizations

The combination of the authorization object and a field value constitutes the Authorization that is an instance of the authorization object. This leads to the structure depicted in Fig.

Fig. 7. Authorization (Instance of an Authorization Object)

The use of the term “authorization” leads to confusion because in general an authorization is the permission of a user to execute a function in a system. But in this context, authorizations are not user authorizations. An authorization is here (and in the SAP environment) a special notion for the combination of the authorization object and the values for its fields.A value which is placed in a value field of an authorization object can be a singlevalue or a value range. There are a number of numerical values which denote thetype of an activity. The following Table shows the action codes which occur inthis thesis. The table that contains all activities is TACT

Table Authorization Values Denoting the Type of an Activity

Additionally, values can use the wild-card characters “?” and “*”. The wild-cardcharacter “?” stands for a single and “*” stands for any combination of charactersof any length. A value which contains wild-card characters is called regular pattern.Regular patterns consisting of a combination of wild-cards and an interval providesa lot of possibilities for authorizations. The following Table depicts some formatsand patterns and is taken from SAP as example:

Table . 4 Value Formats in an Authorization

14.Policy-Based Authorization [40]

Policy-based authorization can be viewed as a reformulation of content-based authorization [43] with simplified content-based policies as the central focus.An ideal authorization system would enforce fine-grained security policies that automatically adapt to changing situations – yet require little or no effort to manage the system except to adjust high-level policies when needed.

At the same time, the system would present an appropriate and understandable view of the authorization model to a wide range of users, including technical staff, policy managers, personnel managers, and end users.

One might argue that Mandatory Access Control (MAC) comes close to this ideal. Mandatory authorization policies are understandable to users whose job involves

managing classified information because the policies are tailored to that domain. Users interact with the model by classifying documents and other users, and the system enforces security policy automatically.

However, this approach has not been generalized to apply to other domains or software systems that do not seem to have a single unifying set of requirements.Discretionary Access Control (DAC) allows users or security managers to implement anysecurity policy they want. But there is a cost: they must exercise their discretion to apply the proper security to objects, and maintain them over time.

When applied at the granularity of rows, instances or individual fields the overhead quickly becomes unmanageable. The constructs available to specify authorization,including roles [87], object hierarchies, and templates [41], do not necessarily match wellwith corresponding concepts in the user’s domain [47]. Often the authorization policies exist only in the heads of the users, who manually update the authorization system to reflect the outcome of their policy decisions.

This paper discusses policy-based authorization, an effective intermediate point betweenMAC and DAC that promises to combine the best features of both models. Policy-based authorization can be viewed as a reformulation of content-based authorization [43] in which content-based policies are the central focus.

The primary contributions of this paper are a methodology for designing application-oriented authorization policies, a language for expressing the policies, a new approach to separating the duties of creating policy and assigning policies to users, and a discussion of implementation techniques for fine-grained authorization policies in object-oriented and relational contexts.

This model has been implemented in a large enterprise application deployed to thousands of users over the last five years.

Specifying Authorization Policy

In the example, operations on enrollments are granted to users based on a number of factors, including their relationship to the enrollment, any special rights that they have, and the state of the enrollment. This section introduces a methodology for formalizing and managing the authorization policies in the example.

Context Roles

A context role is a product of two optional components: a relationship expression and a policy name. If present, the relationship expression defines how a particular user is related to the object. The policy name identifies what policy must be granted to the user to enable authorizations based on the context role. Policies that are not named are applied to all users. Figure 3 defines some context roles based on the example policies. The relationship expressions are given in the expression grammar of OQL [47]

Figure 8Consistency rules, which prohibit illegal states or transitions, resemble authorization rules but do not depend upon the user. Uniform treatment of consistency and authorization is useful – if a situation arises in which a consistency may be overridden, the consistency rule can be converted into a very restrictive authorization rule by specifying which context role can override the rule.

User Roles

Not all policies apply to all users. To be configurable, a system should support definition of appropriate roles that invoke appropriate policies. However, different organizations may organize the roles differently; a small organization may have one administrator with many rights, while a large organization may divide the roles more finely. In addition, the skills involved in creating and deploying policies are verydifferent from the skills involved in managing users and assigning them to roles. Since policies are complex enough to require development and testing, they should not be altered on a running application in active use, while roles are easily managed in a live application. As a result, effective management of authorization should separate these tasks.Given the fine granularity of policies defined above, it is important to be able to group multiple policies together to define a user role. These roles are based on the roles in RBAC [65], but specify policies instead of access permissions. Organizing users into groups allow many users to be assigned the same set of roles easily. Users can also be automatically assigned to groups by attaching a condition to the groupdefinition [54]. All users who meet the condition are automatically inserted into the group.Finally, groups are associated with roles. As shown in Figure, all relationships between user, group, user role, and named policy are many-to-many. This allows a user to be in many groups, a group to have many roles, and a role to enable many policies.

Figure 9 . Entities for associating users with named policies

Related Work

A recent survey [48] of approaches to policy specification includes a section on authorization policies.Although they point out that “in many systems there is no real policy specification”, the following systems all support definition of authorization policies that express the essential dependence on content and user attributes. The systems are reviewed in chronological order.

Moffet & Sloman [62] considered policies of the form “All users may perform Pay on those Transaction objects where the value of the user's Authorisation_Level attribute is greater than the value of the Amount attribute in the Transaction object.” They conclude that while content-based access control is clearly desirable, it was not practical because access to attributes may not be trusted and the implementation would be inefficient.

Template-based authorization [51] creates parameterized roles, but these must be instantiated to express content dependencies. Gross [56] proposed modification policies as conditions over functional abstractions of relational data. The functions complicate execution of the rules, but accommodate radical changes to the underlying data model.Bertino and Weigand [43] define content-dependent policies for object-oriented databases, as an adjunct to explicit access control. They only sketch a user-level versionof the language, and do not separate the management of roles and policies. They defineextensive mechanisms for implicit authorization, where authorization of one object or user may depend upon others. These techniques could be investigated further in the context of pure policy-based authorization.

Pandey and Hashii [63] define a policy language for java programs. Authorization can depend on the attributes of the object, but there is no explicit notion of user or role. Sincepolicies are enforced by bytecode editing, different users cannot have different sets of policies.Barkley et. al. [42] allow relationships tests to be plugged in to an RBAC model. Didriksen [50] allows “fragmentation” of database tables based on a form of SQL condition that may refer to table content or user attributes. No formal semantics or implementation details are given.

Steen and Derrick [66] formalize ODP enterprise policies using a policy language based on OCL conditions; the semantics is defined by an informal translation to Object-Z. Goodexample policies are discussed but no implementation is given. They also consider obligation policies, which are outside this scope of this paper.

LasCO [18] is a graph-based language for defining security policies over operation invocation. The mapping of policies to roles is embedded within the policy definition, making management more difficult. It is also not clear that the graphical notation helps readability, since most of the graphs are simply one or two arcs.

Ponder [49] is a policy specification language targeted at distributed systems and network security. The language assumes a hierarchical organization of subjects and objects, and allows constraints defined in a subset of OCL. Ponder also supports reuse of parameterized policy definitions.

Many languages use role activation conditions to allow roles to depend upon object content [41]. Our approach evaluates the conditions at each application of policy without requiring role activation. SPL [64] is an expressive policy language very similar to the model presented here. The model provides notation for reusing and combining policies. The biggest problem with the language is scalability, although this may be due in part to the use an ACL-based implementation.

With respect to a computer file system, an access control list (ACL) is a list of permissions attached to an object. An ACL specifies which users—or system processes—are granted access to objects, as well as what operations are allowed to be performedon given objects. In a typical ACL, each entry in the list specifies a subject and an operation. For example, the entry (Alice, delete) on the ACL for file WXY gives Alice permission to delete file WXY.[1]

In an ACL-based security model, when a subject requests an operation on an object, theoperating system first checks the ACL for an applicable entry to decide whether the requested operation is authorized. A key issue in the definition of any ACL-based security model is determining how access control lists are edited, namely which users and processes are granted ACL-modification access. ACL models may be applied to collections of objects as well as to individual entities within the system hierarchy. [1]

Goodwin, Goh and Wu [54] extend template-based RBAC to allow object groups definedby implicit conditions and support a relationship test between the subject and the object. The use of relationships is limited; for example, rather than use a relationship test for membership in an appropriate organization they use template instantiation. They only allow a single direct relationship rather than a generalized relationship-based condition. Zhao [68] support a specific set of ownership relationships for supply-chain applications.

Conclusion about the policy

Policy-based authorization is a reformulation of content-based authorization with a focus on explicit policies represented as rules. Policies are defined in terms of the properties ofthe subject, the properties of the object(s) and the relationship between the subject and the object. This authorization model combined elements of discretionary and mandatory authorization. The policies are mandatory in the sense that they are defined centrally, but are discretionary in the application of policies to users and control over the elationships on which authorization is based.

By abstracting away from the semantics of the underlying application, in the definition of the abstract sets of subjects, objects, and rights, traditional access control models lose the ability to effectively model the intention of an authorization policy. On the other hand,policy-based authentication does not work unless the underlying application has suitablepolicies to implement: a generic file serve does not have enough behavioral constraints to support useful policies.

15. Business Processes [24]

A business process is a sequence of interrelated steps which solve a particular issue.It can be part of another process and can also contain other processes or initiate one

There are three types of business processes:

1. Management processes govern the operation of a company. Typical managementprocesses include “Corporate Governance” and “Strategic Management”

2. Operational processes are processes that constitute the core business and createthe primary value stream. Typical operational processes are Purchasing, Manufacturing, Marketing, and Sales.

3. Supporting processes support the core processes. Examples include Accounting,Recruitment or IT-support

Management processes are indirectly modeled in SAP because they typically partly initiate or consist of other non-management processes. On the other hand the perationaland supporting processes are mapped in SAP by sequences of different transactions.

In general, all business processes that are mapped by a number of SAP transactions use the same authorization check mechanism. The analysis of all business processes which are mapped in the SAP system would go beyond the scope of this thesis..

16. Business Policies

Business Policies – specified by business people – grant or restrict the access to a set oftransactions in SAP.However, for example, it is admissible that a single user has the authorizations to perform all these steps but for different plants, i.e. he/she can create requisitions for plant X, release requisitions for plant Y and create orders for plant Z. In terms of transactions, this means that the user should not have the authorizations to perform the appropriate transactions to create requisitions, release requisitions and to create orders for one plant, material group, purchasing group and organization.

Table 9. Identified Authorization Objects in Transaction ME21NOFF

Unfortunately, the business policies are not directly represented in SAP.Therefore, the policies cannot extract automatically. Since they restrict business processes which are mapped in SAP by a set of transactions they can be expressed in terms of transactions, too. In general, business policies will be “translated” from the business people language to a language that composes SAP elements like transactions and authorizations. Then the translated policies can be formalized.

17. The RBAC pattern as an extension of the Authorization pattern [67]

There are three models currently used by most systems: the access matrix, the Role-Based Access Control (RBAC) model, and the multilevel model.This pattern provides a structure where we can define patterns at all levels that together implement a secure system. Its main idea is the decomposition of a system into ierarchical layers of abstraction, where the higher levels use the services of the lower levels. Here it provides a way to put things in perspective and to describe themechanisms needed at each layer. Figure shows the specific set of layers.

Figure 9.

This figure shows some of the participants at each layer and their correspondence across layers. Due to the complexity of the problem, we need a series of pattern languages, one per level. We start in this paper with a pattern language for abstract models; this includes thethree basic models mentioned above. These models define security constraints at the highest architectural level for the applications, which are enforced by the lower levels. These models have been extensively studied by the security community [68, 69], and wedo not attempt here to add new models or extend existing models. Our intent is to specify the accepted models as object-oriented patterns that can be used as guidelines in the construction of secure systems. We show also how these patterns can be applied to all the system levels.

Authorization pattern

Context

Any computational environment where there are active entities that request resources whose access must be controlled.

ProblemHow to describe allowable types of accesses (authorizations) by active computational entities (subjects) to passive resources (protection objects).

Forces• The authorization structure must be independent of the type of resources, e.g., it

should describe access by users to conceptual entities, access by programs to operating system resources, etc., in a uniform way.

• Predicates or guards may restrict the use of the authorization according to specific conditions.

• Some of the authorizations may be delegated by their holders to other subjects.

SolutionRepresent the elements of an authorization rule as classes and associations. Class Subject describes the active entities, while class ProtectionObject describes the requested resource. An authorization rule is defined by an association between these two classes. An association class, Right, includes the type of access allowed (read, write,…), a predicate that must be true for the authorization to hold, and a copy flag that can be true or false indicating if the right can be transferred or not. An operationcheck_rights can be used in the subject or object to check the validity of a request. Figure 2 shows the elements involved. The sequence diagram of Figure 10 shows a request validation. ActiveSubject is an actor, e.g., an executing process, that requests some resource.

Figure 10. Authorization pattern

ConsequencesThe advantages of this pattern include:

• The pattern applies to any type of resource. Subjects can be executing processes, users, roles, user groups. Protection objects can be transactions, memory areas, I/O devices, files, or other OS resources. Access types can be read, write, execute, or methods in higher-level objects.

• The predicates in the rules are a general representation of any conditions that may restrict the application of a rule.

• The copy flag in the rule controls transfer of rights. However, some systems do not allow transfer of rights, i.e., their copy flags are always false.

• Some systems separate administrative authorizations from user authorizations for further security (principle of separation of duties) [70].

• The request may not need to specify the exact object in the rule, this object may be implied by an existing protected object [71]. Subjects and acess types may also be implied. This improves flexibility at the cost of some extra processing time (to deduce the specific rule needed).

18. Role-Based Access Control (RBAC) pattern [67]

ContextMost institutions have a variety of job functions that require different skills and esponsibilities. For security reasons users should get rights based on their job functions. This corresponds to the application of the need-to-know principle, a fundamental securitypolicy [69]. Job functions can be interpreted as roles that people play in performing their duties. In particular, web-based systems have a variety of users: company employees, customers,partners, search engines, etc.

ProblemHow to assign rights to users according to their roles in Example Corp..

Forces

• People Example Corp. have different needs for access to information, according to their functions.

• We want to help the Example Corp. to define precise access rights for its members according to a need-to-know policy.

• Granting rights to individual users would require storing many authorization rules and it would also be hard for administrators to keep track of these rules.

• Users may have more than one role and we may want to enforce policies such as separation of duty, where a user cannot be in two specific roles in the same session.

• We may need to have hierarchies of roles, with inheritance of rights.• A role may be assigned to individual users or to groups of users

SolutionExtend the idea of the previous pattern interpreting roles as subjects. A basic model for Role-Based Access Control (RBAC) is shown in Figure 4. Classes User and Role describe the registered users and the predefined roles, respectively. Users are assigned to roles, roles are given rights according to their functions. The association class Right defines the access types that a user within a role is authorized to apply to the protection object. In fact, the combination Role, ProtectionObject, and Right is an instance of the Authorization pattern. Accordingly, the predicate indicates contentdependent restrictions that can be used to select specific objects. The attribute copy_flag indicates a Boolean value (true/false).

Figure 11. Basic RBAC pattern

The model of Figure 5 considers additionally composite roles (an application of the Composite pattern) and separation of administration from other rights (an application of the policy of separation of duties). The model also includes a constraint to enforce a separation of duties. The administrator has the right to assign roles to groups and users, he is a special user who can assign users to roles and rights to a role. Rights for security administration usually include:

Figure 12. A pattern for RBAC

19. Implementing and Modeling Roles in ITIM

ITIM provides a number of concepts and mechanisms to allow organizations to manage access control data.The central concept for an implementation in ITIM is the so called “Provisioning Policy”. The total set of provisioning policies together with the specified roles, define which Identities in ITIM are allowed which accounts as well as the characteristics for these accounts.

A provisioning policy can be conceived as being composed of 2 parts:

• rule definitions• role assignments

Rule definitions:A provisioning policy consists of one or more entitlements. Each entitlement is linked to a specific target system, and contains a configurable number of rules, called entitlement parameters. These rules define acceptable values for account attributes for that target system. More specifically, the rules define the ‘what’ (which are allowed and/or excluded values for an attribute) and the ‘when’ (when should this value be enforced – at account creation or always) for values of the account attributes. E.g. a rule can define the group-membership of an account on a target system.

Role assignments:Roles are linked to a provisioning policy. An identity that has at least one of these roles will automatically become subject to the rules, defined in this provisioning policy.

The relationships between role assignments, rule definitions, accounts and identities are illustrated below Picture 6.

Picture 6

Assigning an identity in ITIM to a role can fire off one or more provisioning policies. These provisioning policies in turn will then determine:

• what are the accounts that are allowed for this identity,• whether these accounts will be created automatically or not,• which are the allowed and enforced attribute values of these accounts, and• what action should be taken by ITIM in case of detected non-compliances

Organizations wishing to implement the ANSI/NIST [3] RBAC model using ITIM rapidly realize that roles in ITIM are tied to provisioning policies. Roles in ITIM are not a means by itself but merely enable the rules defined in the provisioning policies.

1. ITIM implements a provisioning oriented view. Roles are tied to provisioning policies. There is no functionality or a GUI that allows defining roles, role relations and role permissions. Equally, there is no support for defining role owners or role assignment approvers on individual role level.

2. Creating provisioning policies is a manual and complex task in ITIM. This task is performed by ITIM administrators. Every target platform implements group objects and group membership in some way globally. Those group definitions are commonly referredto with a system-independent term, being ‘authorization groups’. Keeping the available authorization groups in sync with the rule definitions of the provisioning policies, requiresmanual verification by ITIM administrators. Moreover, the management of provisioning policies requires that administrators know how to deal with the different authorization group concepts, which are specific per platform.

3. ITIM does not support out of the box ANSI/NIST [3] RBAC concepts such as role hierarchy or separation of duties.

4. In ITIM, approval cycles are focused on accounts and provisioning policies. There is no role-oriented framework for defining approval cycles on role assignments and junior role assignments.

5. Temporal constraints on role assignments cannot be comprehensively defined and managed in ITIM Picture 7

Picture 7

The reconciliation process consists of the following steps:

1. ITIM sends a reconciliation request to the agent.

2. The agent interprets the request, and communicates with the target system to retrievethe current information regarding accounts and authorization groups.

3. The agent sends the result back to ITIM.

4. ITIM stores the reconciled accounts and the supporting data into its data store.

5. The foundation Modeller maintains the list of available technical roles, based on the reconciled supporting data.

6. ITIM runs a check against the reconciled accounts to ensure compliancy with the policies that are defined. Detected non-compliances are handled in ITIM in accordance with these policies.

The following Picture 8 illustrates this process.

Picture 8

Project design

1. Business requirements

Business requirements - Corporate business vision and objectives (Policy for instance)These can be lined out as follows:

1. Introduce an extranet to business partners and customers

2. Reduce help desk overhead and costs3. Reduce license and maintenance fees for deployed applications4. Improve audit and compliance reporting:

a) There is no periodic certification of users’ access rights. a) The reporting available is insufficient to verify security compliance.

5. Reduce provisioning time

2. Functional requirements

1. We need to extract functional requirements by mapping business requirements to their underlying reasons.

2. We need to expand the reasons in increasing detail until we find problems that can besolved using capabilities of Identity Manager.

3. Functional requirements will tie these low-level reasons for a business requirement to the Identity Manager capability that fulfills that business requirement.

Business requirement 1: Introduce an extranet to business partners and customers

Table1. Functional requirements for extranetDescription Requirement Description

A An Identity Manager installation to be highly available.

B Provide self-care application to empower employees, customers, andbusiness partners to administer their own account needs.

C Provide self-registration capabilities for customers and businesspartners.

Business requirement 2: Introduce a recertification process to gain metrics about license usage.In order to capitalize on this potential savings, the software license usage needs to be measured to identify whether any licenses could be trimmed, and therefore, savings realized. To do this, Example Corp. can implement a recertification process for all software currently in use to identify those licenses that could be cut along with the associated maintenance.

Table2. Functional requirements for software license and maintenance cost reductionDescription Requirement Description

D All Example Corp. employees and business partners that utilize Example Corp. applications must have an e-mail account or access to the self-care

application

E Create an Identity Manager recertification process for all Example Corp.applications

F Make re-certification process available company-wide andextranet-wide

Business requirement 3: Enhance audit and reporting capabilities.

Example Corp. will enhance its audit and compliance solution with the formation ofa specialized team to aggregate audit and compliance information in such away that efficiently provides more detailed and focused reporting. To facilitate this, Example Corp. wants to implement an audit and compliance reporting process thatprovides a streamlined solution.

Table3. Functional requirements for enhanced audit and reporting capabilitiesDescription Requirement Description

G Automate audit and compliance report generation.

H Automate audit and compliance report delivery

I Automatically update audit and compliance team with re-certificationinformation

Business requirement 4: Reduce application administration cost.

Table4. Functional requirements for application administration cost reductionDescription Requirement Description

J Decrease the time required to debug application issues.

K Mitigate error-prone administrative functions

L Reduce repetitive administrative duties

M Delegate administration of business partner users to business partneradministrators

Design approach

Identity manager implementations often involve non-functional requirements relating to:

• High availability

• Backup and recovery

• Performance and capacity

• Change management

• Training

• Existing infrastructure

• Budget and staffing

Implementation Plan

The steps involved in producing an implementation plan are:

1. Prioritize the requirements.

2. Map the requirements to TIDM features

3. Define the tasks involved in using those features to satisfy the requirements, and estimate the effort required for each task.

4. Divide the tasks into phases.

Implementation approach

Technical implementation phase [2]

Requirements

The continuous availability of the services has become a main business requirement thatthe company must consider on the design and technical implementation of the Tivoli Identity Manager solution.

Continuous availability can be separated into two categories:

• High availability

This means that a specific resource is available for use at all times, implying that if it becomes unavailable on a particular machine, another one starts to provide access to

this resource. The business impact of these outages specifically refers to the desired improvements in terms of high availability.

• Continuous operation

This signifies the ability to avoid planned and unplanned outages. This includes the ability to upgrade and maintain processors, operating systems, business software, and the applications, where the business does not stop, even in a failure event. This is accomplished by adding duplicate resources to the environment. Analyzing the businessneed to extend service hours produces a specification for the necessary degree of continuous operation. This is defined in the service level agreements (SLAs).An unplanned outage of computer systems results in several business processescoming to a standstill. From a business perspective, the financial impact of a unplanned outage of the identity management system can occur in several ways:

• Lost productivity time of the users

Users who need the systems for their work might be idle for as long as the systems are down. For instance, user accounts will not be created in a timely manner for a newly hired employee.

• Loss of transactions

If the outage occurs during a password synchronization process, the unique password for all the target systems managed by Tivoli Identity Manager could be out-of-sync.

• Loss of compliance with security policies

If the outage occurs when an employee is changing a business role or is leaving the company, accounts could be still available on the target systems that should have been deleted or they could provide wrong levels of access.

• Extra cost and time for support service recovery

The work that was interrupted through an outage needs to be repeated at a later time. Repetition of workload requires extra system resources and extra time and cost for the support services.

Technical implementation phase II

Requirements

A self-care application is developed to provide employees, business partners, and customers the following capabilities:

• Users are able to request the creation, modification, and deletion of the accounts to which they are authorized by policy and role.

• Users are able to access and complete the recertification process.• New users are able to access and register for a TAA account.• An approval process is available for account creation or modification requiring

approval by a member of an application administration or management team.

The self-care application is deployed in a phased approach to better control and mitigates any issues, which might arise by implementing the following phases:

Phase 1: Host the self-care application and test in production using administration and test team member accounts.

Phase 2: Open the self-care application to internal employees by region. Example Corp. will do this through notification of employees of the new URL and capabilities during a simple training process. The training process consists of an informational e-mail describing the simple interface, capabilities, and a Web site they can go to for more information.

Phase 3: Open the self-care application to extranet members by notifying them of the URL and theinformational e-mail we just described.

Phase 4: Incorporate the remaining business partners that were not covered in phase 3 and customers.

Design considerations

Prior to implementing the requirements, there are design aspects Example Corp. must consider to ensure the correct implementation:

– The application needs to be lightweight and accessible anywhere, thus, a thickclient is precluded as a possible solution and a Web-based application isrequired.

– The application needs to be highly available; hence, the application leveragesthe high availability of the Identity Manager installation as much as possible.

– The capability of the application needs to reflect the access rights of the userwho accesses it. Therefore, a capability has to exist in order to restrict access

to certain portions of the application, depending upon the type of user accessingit.

– Since the business partner administrators need elevated privileges, ExampleCorp. has decided to create a Tivoli Access Manager-secured junction for theseusersto be able to access the standard Identity Manager interface for this functionality.

Implementation

The implementation of the self-care application consists of two distinct high-level tasks:

– The first is the development and test of the self-care application and the second is the deployment of the application.

– The development task has several subtasks as well, which are the creation of theoverall application, and the creation of individual capabilities to offer to the user. In the following sections, we discuss each of these tasks

Tivoli Role Modeling/Management

IBM Tivoli Security Role Modeling Assistant

The Role Modeling Assistant enables organizations to define and model an enterprise role. It aids customers in the process of collecting user and entitlement data to build roles from the bottom-up while also streamlining the collaboration between line of business and IT stakeholders through a top-down analysis. This provides a complementary foundation of what access privileges users DO have and what access privileges users SHOULD have. To receive maximum value, customers should have Tivoli Identity Manager V5.1 deployed. The Role Modeling Assistant includes the following capabilities:

-- Import user and entitlement data

-- Importable interview form template

-- Data search and analysis

-- Role mining

-- Role creation

-- Role editing

-- Role export

IBM Tivoli Security Role Management Assistant

The Role Management Assistant offers organizations a life cycle management process for their enterprise role and policy structure. It enables the collaboration of business policy makers and IT administrators to review and approve roles and policies while facilitating their automated deployment. To receive maximum value, customers should have Tivoli Identity Manager V5.1 deployed. The Role Management Assistant includes the following capabilities:

-- Import roles and policies

-- Assignment of role and policy owners and approvers

-- Send role and policies out for approval or recertification

-- Edit role and policy descriptions

-- Publish approved roles and policies for import into TIM

Picture 9

Roles typically represent collections of users and/or permissions. Role management, together with user provision-ing, automates the process of administering user access by delivering access rights to target systems based on the roles assigned to each user.Self-service requests can be configured to let you define which attributes a real lowed forself-service and which require approval. You can approve, modify or reject requests electronically through a Web browser, and users can be automatically notified of the status of their requests. To make the process easier for users, the self-registration and self-enrolment interfaces collect information automatically, and the approval of user requests can be auto-mated by a workflow engine.

Role Engineering Approaches

Top-Down

This approach is primarily business-driven, and roles are defined based on the responsibilities of a given job function. For roles to be effective there should be a strong alignment between business and IT objectives. Roles are defined by reviewing organizational business and job functions and mapping the permissions for each job function. This approach provides business oversight and alignment of roles with business functions and reusability.

Picture 10.

Following are the key steps for a top-down role engineering approach:

• For a successful role engineering project, it is pivotal to define the scope and boundaries for the project. If the organization has a large user population, it would be ideal to conduct a pilot to validate the approach and the outcome. The boundaries could be specific business units or applications that are being considered for role definition.

• It is important to identify enterprise access policies to determine entitlements for a given job function. The objective of this exercise is to define entitlements based on the least privilege access principle.

• The next step is to group users in a given business unit based on privileges correspondingto their job function. This would provide some basis for determining appropriate criteria to identify and define the user population.

This graphic Picture 10 describes the key steps of a top-down role engineering approach.

• One of the critical aspects of role definition is not to have mutually exclusive roles assigned to the same person. For example, a person who creates a purchase order should not be the one who approves it. These types of constraints are defined as part of segregation-of-duties policies. It is important to capture these constraints so that rules can be established to evaluate what types of roles can be assigned to a user for a given job function.

• Role hierarchies help simplify role definitions by aggregating roles. Role hierarchies usually follow the pattern of organizational hierarchies, where users in the higher organizational structure are able to perform the job functions of their direct and indirect reports. For example, a branch manager can perform the job function of an employees.

Creating role hierarchies simplifies the number of roles assigned to a user.

Bottom-Up

This approach is based on performing role-mining/discovery by exploring existing user permissions in current applications and systems. Once user permissions are explored, the next step is to perform role normalization and rationalization. In this approach, roles are defined to meet specific application or system access requirements.

One of the challenges of this approach is that it requires viable commercial tools to perform role mining. An alternate approach is to select a set of representative users and extract the entitlements that best describe the job function. If the user population is significant, it would be ideal to sample a certain percentage of the population to validate the accuracy of the results. One of the outcomes of this approach is that users often accumulate entitlements based on their previous job functions performed over a period of time; it can become too daunting to extract the entitlements without the business

involvement. This is a key aspect of role rationalization to be considered as part of a bottom-up approach.

Deliver access via a hierarchical role structure

Tivoli Identity Manager offers a role hierarchy that establishes parent/member role relationships to automatically create user access rights through the notion of inheritance between roles. You can administer a role structure that contains business roles (collections of users) and/or application roles (collections of permissions). And when roles are associated with provisioning policies, theycan automatically grant, modify, or remove user access rights. As a result, it reduces the number of administrative objects used to manage user access and enhances the visibility of access across your organization.

Leverage request-based provisioning and access entitlements

Managers and delegated administrators can take advantage of comprehensive, request-based provisioning to easily request (with approval workflow) user access to roles, accounts or a fine-grained access entitlement, such as shared folders and Web port lets. In addition, end users and line-of-business managers can view current access rights, personal profile information and status of pending requests; request new access to roles, accounts or fine-grained access entitlements (for example, shared folders or Lightweight Directory Access Protocol [LDAP] groups); update profile information; change or reset passwords; and take action on management tasks such as approving new access rights or recertifying existing access rights.

How does RBAC complement Provisioning?

Provisioning is the process of feeding the local access control systems with the information they need to enforce permissions on users. Provisioning is independent of the model that is used to structure this information. As such Provisioning can work with almost any known model, going from the most simple model (e.g. request-based), over abstract models (like RBAC) to the most complex models (e.g. rules based). The main reason behind the existence of all these different models is that there isn’t any “one sizefits all” model. Technical, political, organizational, financial and other factors influence which model is best suited for an organization.

So, how do we find out which Identity Management model our organization should choose?

Request-based Provisioning works, no doubt about that, but efficiency is challenged in an organization with several thousands of employees. Recurring requests can be reduced or even eliminated by abstracting them into a role. However, in the long run an organization will very likely be confronted with the fact that it will end up with too many roles, conflicting roles or too restrictive roles. Roles can be made more flexible and

their number reduced by extending them with rules; rules that control e.g. separation of duty and temporary assignment and activation.

At the core of our model, there will always be roles. In very simple models roles might behidden to the extend that we don’t even realize that we have them. E.g. a local group ona target system is a role. In most cases it is not an organizational or functional role, but itstill is a role. Often we call them technical roles. In other situations the role model can bevery visible. E.g. organizations with complex structure will very likely have a deep hierarchical role model.

Note that so far we have not yet mentioned meta-directories. The discussion of “provisioning” versus “meta-directories” is not relevant. Basically both are simply other ways of synchronizing data between different repositories and as such only provide the technical foundation of our identity management system.

It is the identity management model that sits on top of this foundation that will be responsible for the way an organization manages access control data. Because this document was produced in the context of ITIM, which is a provisioning based identity management system, we will only refer to provisioning in the remainder of this document, though the scope is of course also valid for meta-directories.

The following figure illustrates how a layered identity management approach can make sure that the identity management model can be made independent of the underlying target systems and synchronization mechanisms.

• Identity Management Foundation• Provisioning Meta-Directory• Identity Management Model• Identity Management Administration• Administrator

ConclusionsAs organizations embark on various RBAC-oriented IDAM initiatives, it is becoming evident that defining high-level roles with basic entitlements will not deliver expected business benefits. It is imperative for a successful role definition to have management support, sufficient funding for the role engineering effort, business unit participation, and resources committed to the project.

The importance of roles should not become an afterthought, but should be considered an integral part of any IAM initiative. Organizations also need to address requirements for roles from a compliance standpoint. Entitlement certification is becoming a critical aspect of various regulatory compliance initiatives.

It is important for organizations to get the expected business benefits with carefulconsideration for how roles are going to be defined and managed on an ongoing basis. Defining roles is difficult under any circumstances, but the process could be overbearing without established limits. It is important to define boundaries for user population, applications and platforms, and the number of business units to be covered by the project.

Role engineering, in a top-down or bottom-up approach, is a key cornerstone in the process of defining roles that meet the organizational requirements. Once the roles are defined and inventory has been published, it has to be maintained by both the business

and IT, as this helps to keep the information current and available for any future IAM initiatives.

20. Separation of Duty in Role Based Access Control System[72]

This system implements a rich set of conflict of interest policies that ensure a secure system.

• All administrative activities are subject to separation of duties to prevent any security lapses. A maker/creator who is usually clerk or an officer initiates a transaction in the system. A supervisor who after reviewing the transaction authorizes the transaction to complete the transaction. The supervisors in the system do not have access rights to create or initiate any transactions.

• To prevent corporation between users belonging to different departments, authorizers can only authorize transactions originated from a branch department they belong to.

• The system screens all transactions and ensures that the maker and the authorizer are not the same user, the maker and authorizer belong to the same class, and the level of the authorizer is higher than that of the maker.

• Users have currency limits beyond which they cannot initiate or authorize transactions.

Table 1 Process Separation of Duty Matrix example [22]

In his work titled “Separation of duty in computerized environments”, Sandhu [73] uses the payment of a check voucher as an example to illustrate the implementation of separation of duty in information systems. He identified three requirements for a system to implement the check voucher example, namely:

• Dynamic Separation of duties• Hierarchical Roles• Substitution of Attribution

He classified the objects within an information system into transient and persistent objects. The Transient objects have a finite sequence of steps, which disappears from the system. They have a complete history. Persistent objects have an unbounded existence in the system and an infinite sequence of steps is applied to them.

He stated that the first level of defense was to limit modifications to the database to only users executing correct transactions. He proposed a second line of defense to effectivelyenforce SOD by partitioning the objects in the database into transient and persistent objects and then enforcing controls on the transient objects.

Persistent objects get modified as a result of the modifications done on transient objects.In the example the transient objects are the vouchers and persistent objects are the accounts. He showed that this mechanism is able to enforce dynamic SOD, Hierarchical Roles and Substitution of Attribution.

Simon and Zurko [74] identified the various variations in separation of duty and categorized them. In role-based environments assigning users to roles controls access. These roles are defined by first grouping according to users who may act in a role, operations or actions comprising what may be done in the role, the object or target to be acted upon. They identified three types of constraints on the roles: Role membership, role activation and role use constraints.

They categorized separation of duty into Static Separation (strong exclusion) andDynamic separation of duty (weak exclusion). Static Separation Duty none of the users is allowed more than one role. It implements the role membership constraint. Static separation of duty is too rigid to meet the separation of duty requirements of organizations. Dynamic separation of duty makes use of role activation and role use constraints to make it possible to implement a richer set of separation of duty requirements of organizations. They identified four variations in this policy namely:

• Simple Dynamic Separation of duty• Object-based separation of duty• Operational separation of duty• History based separation of duty

They also identified that History based separation of duty as a combination of both the object based and the operational separation of duty. Each step may consist of order-dependent or order-independent actions.

Separation of Duty in Role Based Access Control System:

The case study of Role Based access control system in a major European bank wasconducted by Schaad etal [78]. They discussed the overall structure of the system and compared it to the other models. In addition to that they were also able to answer the question of the relationship betweenthe number of users and the number of roles in the system. The system used was not specific to a single operating system or application.

Figure 1 : The basic structure of the FUB

The FUB is an example of an enterprise-wide role-based access control system. Applications cannot make access control decisions on their own. They grant access to data on the basis of a centrally provided security profile. Over 600 applications within thebank make use of this system. These cover a wide area of organisational functions such as private customer instruments at the local branch, credit data checks, automated signature approval and the administration of Unix accounts.

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.

The FUB system is a RBAC system the roles are defined by the combination of the official position and job function. One of the weaknesses they identified in the FUB

system was that a user could be assigned to more than one role and upon logging in had access to all those all the access rights in the roles. This was at variance with the other model which only one role can be active per session.They also discussed inheritance and were able to make a distinction between inheritances as it occurs along official positions and inheritance between job functions.

Clark and Wilson’s defined the commercial security policy for integrity [75] identifiedSeparation of Duty because one of the two better mechanisms to opposite fraud and error time ensuring the correspondence between data objects within a system and the real world objects they appear as. At the policy aligned, processes were divided into steps; with each step as performed by a different person.

Accordingly Separation of Duty is tightly responsible to application semantics or commands. Clark and Wilson suggested further safeguarding rail collusion by random selection of the sets of humans to perform some operation, consequently that bit proposed collusion is alone safe by chance [76].

Clark and Wilson defined the Separation of duty in security policy for integrity along withwell-rounded transaction of two major mechanisms that control fraud and error. The use of well-rounded transaction shows that the computer information which are in the systeminternally reliable and separation of duty confirmed that object of the physical world arereliable with that information of object in the computer system.

They also explained that computer does not access to monitor in the real world, which means that computer cannot check the system directly to the external constancy [75]. Whenever the association is ensure indirectly separate subparts in all operation and requiring the subparts perform by different users.

The information security literature shows the idea of SoD that comes into view in Seltzer and Schroeder with the name of “Separation of privileges” [77].

The Roger Needham is the making of surveillance in 1973 that shows a protection mechanism that requires two keys to unlock it is more robust and flexible than one that requires only a single key. There is no single mishap, dishonesty or break of trust is sufficient to assist the protection information [76].Sandhu’s work on Transaction control Expressions [79] introduced symbols for DynamicSeparation of Duty. Roles were used to describe who burden problem which transaction steps.However, influence Sandhu’s model each user executing a step agency a transaction had to represent altered. To enforce this, the history of the implementation of each corporation was maintained. The constraints specifying the roles that could accomplish each move were associated with an object. These constraints turned into the history specifying which user executed each step on that object. Hierarchical roles were binding either on object or an extensive code.

A weighted voting syntax allowed the specification of complicated personauthorizations on a particular step on a particular entity Separation of Duty in Role Based Access Control System: A Case of portable security device used ascendancy the asking apple raised a figure of different issues around Separation of Duty. The system

determinate two disjoint groups of authorizing officers, and each day one or two officers from each of those groups were chosen as officer of the day. This was the aboriginal copy of the utility.

Utility of specifying cardinality because a differentiating role and of age - based roles [76,80]. Nash and Poland proposed the opinion of “object based Separation of Duty,” which forced every transaction censure an object to act as by a contra distinct user. They suggested using Sandhu’s Transaction Direction Expressions [79] to prolong the history of an object’s transactions.

Ferraiolo and Kuhn proposed the static and dynamic as a safety condition which shows that user as a member of the role is not mutually exclusive with any other role for which user have already gotten that one. That means no user cannot access the entire step that is needed to complete the task [81]. It is not the policy of Separation of duty but it is the requirement of Static mutually exclusive role.

Crapmton defined the set based approach in separation of duty. The access control system defined the state that as a set of sets and constraint is as a set, which would be forbidden in the system state. The system state will satisfied that if no element of the system state is the superset of constraint then the restrictive between different constraints is discussed [82].

In RBAC each session has only one user. And the task cannot be completed in one task.Several sessions are needed. Let takes as an example that permission place the order and issue the payment are two different roles. Which shows that these mutually exclusive in a DMER constraint. One can start the session, actives the role with the order permission, creates the order end the session. Start another session activates the role with payment permission and the access the payment against the order.

This breaks the SoD policy.

Linper explain the use of Static separation of duty for those, which are from programdevelopment side. Its means that installed the software should be separated from those, which develop the software. The purpose for doing the programmer is making it harder to insert secret code without any one knowing or seeing [83].

Jarger and Tidswell used the constraint and inheritance for Dynamically types access control model to implement the separation of duty [84,85]

Ferraiolo, Cugini, and Kuhn’s paper on RBAC [76,86] presented the beginnings of a formal model of RBAC. They have three kinds of Separation of Duty. The antecedent two were Static Separation of Duty and Dynamic Separation of Duty. These variants were resented influence previous assignment.

The third was Operative Separation of Duty, which introduced the impression of a “business function”, and the set of operations required for that function; a career functionresembles the opinion of job and duty any agency [76,87]. The formal bearing of Operational separation of duty stated that no role answerability admit the permissions toactualise all of the operations essential to a single calling function.

These forces all business functions to desire at first two roles to represent used for their aftermath. The average description of Operational Separation of Duty assumes the rolesinvolved keep disjoint memberships (Static Separation of Duty), forasmuch as that no single person has access to all the operations access a calling function [76].

As we know that the Access control mechanism in enterprise level is very difficult because of number of users, information object, and various kinds of Security policy like subject to object security and organization structure and interrelation of business process etc. so access control mechanism DAC, MAC and RBAC have little limitation applies in the Enterprise level. RBAC policies can be modeled such that can be easily beintegrated with the application that easy to understand analysis and use.

• From our case study the we used Role based access control to manage theadministration of user profiles. Users were assigned to roles based on their workfunction and the departments or branches to which they belong. This enabled the Example Corp. ensure that there is uniformity in access rights assignments and mitigated against the risk of a user acquiring access rights that are beyond their responsibilities or departments.

• We made use of separation of duties to prevent conflict of interests, fraud and also for error correction. The Example Corp. implemented a strict mutual exclusion of roles. Users in the supervisor role could not initiate or create any transactions. Even though within the hierarchy of the Example Corp. a supervisor should be able to assume the access rights of an employee, the mutual exclusion of roles ensured that their access rights only limited them to the authorization of transactions initiated by their subordinates.

Picture 11

• We implemented static separation of duties. For any given type of transaction a user could only perform one operation. Customer service o had access rights that limited their activities in the system to only the creation and maintenance of customer accounts. They cannot perform any other activities neither can tellers

• Perform any customer service activities. The advantage of using static separation of duties lies in its simplicity in reducing the risk of conflict of interest, fraud and errors.

• However, the disadvantage of applying such a simple policy is that in the event that there is an absence of the users responsible for the performance of some important task the operations of the Example Corp. would be adversely affected

Summary and Conclusions

In many organizations in industry and civilian government, the end users do not ``own'' the information for which they are allowed access. For these organizations, the corporation or agency is the actual ``owner'' of system objects, and discretionary access

control may not be appropriate. Role-Based Access Control (RBAC) is a nondiscretionary access control mechanism which allows and promotes the central administration of an organizational specific security policy.

Access control decisions are often based on the roles individual users take on as part of an organization. A role specifies a set of transactions that a user or set of users can perform within the context of an organization. RBAC provide a means of naming and describing relationships between individuals and rights, providing a method of meeting the secure processing needs of many commercial and civilian government organizations.

Various forms of role based access control have been described and some are used in commercial systems today, but there is no commonly accepted definition or formal standards encompassing RBAC. As such, evaluation and testing programs for these systems have not been established as they have for systems conforming to the Trusted Computer Security Evaluation Criteria. This paper proposed a definition of The requirements and access control rules for RBAC proposed in this paper could be used as the basis for a common definition of access controls based on user roles.

References

1. http://en.wikipedia.org/wiki/RBAC

2. Identity Management Advanced Design for IBM Tivoli Identity Manager http://www.redbooks.ibm.com/redbooks/pdfs/sg247242.pdf

3. Role engineering and RBAC standards http://csrc.nist.gov/groups/SNS/rbac/standards.html

4. The NIST Model for role-Based Access Control: Towards A Unified Standard

Ravi Sandhu, David Ferraiolo and Richard Kuhn

5. Sturges, H. A. (1926). "The choice of a class interval". J. American Statistical Association: 65–66.

6. Scott, David W. (1979). "On optimal and data-based histograms". Biometrika 66 (3): 605–610. doi:10.1093/biomet/66.3.605.

7. Freedman, David; Diaconis, P. (1981). "On the histogram as a density estimator: L2 theory". Zeitschrift für Wahrscheinlichkeitstheorie und verwandte Gebiete 57 (4): 453–476. doi:10.1007/BF01025868.

8. W. N. Venables and B. D. Ripley: "Modern Applied Statistics with S", Springer, in (4thedition) section 5.6: "Density Estimation"

9. The AIX and UNIX developerWorks zone provides a wealth of information relating to all aspects of AIX systems administration.

10.developerWorks technical events and webcasts : Stay current with developerWorks technical events and webcasts.

11.Podcasts : Tune in and catch up with IBM technical experts.

12."Documentation:AIX6.1 Information"

13."Redbook:AIX V6 Advanced Security Features Introduction and Configuration" 14.Understanding advanced AIX features: Role-based access control in simple

steps Rajesh K. Jeyapaul (jrkumar@in.ibm.com),

15. National Institute of Standards and Technology, “The Economic Impact of RBAC”, USA, http://csrc.nist.gov/rbac/

15. Kampman, Kevin, “The Business of Roles”, Methodologies and Best Practices, vol. 1, 1

16.“Administration in Role Based Access Control” Ninghui Li, Ziqing Mao

17.“An Administration Concept for the Enterprise Role Based Access Control Model”, Axel Kern, Andreas Schaad & Jonathan Moffett.

18.“Automated Checking of SAP Security Permissions”, Sebastian HÄohn and JanJÄurjens, Software & Systems Engineering, Informatics, TU Munich, Germany

19. “Future Directions in Role-Based Access Control “by David F. Ferraiolo and D.Richard Kuhn National Institute of Standards and Technology ferraiolo@csmes.ncsl.nist.gov,kuhn@nist.gov

20. P. Samarati and S. de Capitani di Vimercati, Access control: Policies, models, and mechanisms, 2001.

21. Anderson, 2001] R. Anderson, “Security Engineering – A guide to buildingDependable distributed systems”, Wiley, NY, 2001

22. [Fox & Zonneveld, 2006] C. Fox, P. Zonneveld;“IT control Objectives dor Sarbanes-Oxley: The Role of IT in the Design and Implementation of Internal Control Over Financial Reporting, 2nd Edition”, IT Governance Institute,2006

23.”Analysis of Authorizations in SAP R/3”, “Untersuchung des Berechtigungskonzepts im SAP R/3 System”, Manuel Lamotte

24.An agens consulting: Virsa Compliance Calibrator, 2007.http://www2.agens.com/sap_grc_calibrator.html, accessed: 2007-11-27.

25.BG94. Bachmair, Leo and Harald Ganzinger: Rewrite-Based EquationalTheorem Proving with Selection and Simplification. Journal of Logic and Computation, 4(3):217–247, 1994.

26. Erbert, Sebastian: Prozessintegration einer Immobilienfinanzierungsplattformmit SAP R/3. Diplomarbeit, Fachhochschule f¨ur Technik und Wirtschaft Berlin, 2002.

27. Hay, David and Keri Anderson Healy: Defining Business RulesW˜ hat Are They Really? Final Report Revision 1.3, the Business Rules Group, formerly the GUIDE Business Rules Project, 2000http://www.businessrulesgroup.org/first_paper/BRG-whatisBR_3ed.pdf, accessed: 2010-03/1028. Management, Planning and Organization of IS, chapter 2, pages 88–91. Information Systems Audit and Control Association, 2005 http://www.isaca.org/Content/ContentGroups/Certification3/ CRM_Segregation_of_Duties.pdf, accessed: 2010-04-10

29.Nonnengart, Andreas, Georg Rock and Christoph Weidenbach: On Generating Small Clause Normal Forms. In CADE-15: Proceedings of the 15th International

Conference on Automated Deduction, pages 397–411, London, UK, 1998. Springer-Verlag

30. Nonnengart, Andreas and Christoph Weidenbach: Computingsmall clause normal forms, volume 1, chapter 6, pages 335–367. Elsevier,Amsterdam, the Netherlands, January 2001.

31. Prevosto, Virgile and Uwe Waldmann: SPASS+T. In Sutcliffe,Geoff, Renate Schmidt and Stephan Schulz (editors):

32.Workshop on Empirically Successful Computerized References 73 Reasoning, volume 192 of CEUR Workshop Proceedings, pages 18–33, Seattle, WA, USA, 2006

33. SAP AG: Third Quarter 2007 Results and Nine Month 2007 Results,2007.http://www.sap.com/about/investor/reports/quarterlyreport/2007/pdf/Q3_2007_e_final_presentation.pdf, accessed: 2010-03-10.

34.Weidenbach, Christoph, Bijan Afshordel, Uwe Brahm, Christian Cohrs, ThorstenEngel, Enno Keen, Christian Theobalt and Dalibor Topic: System Description: SPASS Version 1.0.0. In Ganzinger, Harald (editor): Automated deduction

35. 16th international conference on automated deduction, volume 1632 of LectureNotes in Computer Science, pages 378–382, Trento, Italy, July 1999. Springer

36. Weidenbach, Christoph, Uwe Brahm, Thomas Hillenbrand, Enno Keen, Christian Theobalt and Dalibor Topi´c: SPASS Version 2.0. In Voronkov, Andrei (editor): Automated deduction,

37. 18th International Conference on Automated Deduction,volume 2392 of Lecture Notes in Artificial Intelligence, pages 275–279,Kopenhagen, Denmark, 2002. Springer

38. Weidenbach, Christoph, Bernd Gaede and Georg Rock: SPASS & FLOTTER, Version 0.42. In McRobbie, M. A. and J. K. Slaney (editors): Proceedings of the 13th International Conference on Automated Deduction (CADE-13), volume 1104 of Lecture Notes in Artificial Intelligence, pages 141–145, New Brunswick, USA, 1996. Springer.

39.Weidenbach, Christoph, Renate Schmidt, Thomas Hillenbrand,Rostislav Rusev and Dalibor Topic: SPASS Version 3.0.In 21st International Conference on Automated Deduction (CADE-21),Bremen, Germany, 2007. Springer, Accepted for Publication

40. Policy-Based Authorization, William R. Cook, Department of Computer SciencesUniversity of Texas at Austin

41. J. Bacon, K. Moody, and W. Yao. A model of OASIS role-based access control and its support foractive security.ACM Transactions on Information and System Security (TISSEC), 5(4):492-540,November 2002

42. J. Barkley, K. Beznosov and J. Uppal. Supporting Relationships in Access Control Using Role Based Access Control. In Proc. of the Fourth ACM Workshop on Role-Based Access Control, October 1999, 55-6543. E. Bertino and H. Weigand An approach to authorization modeling in object-oriented database systems Data & Knowledge Engineering, 12(1), February1994, 1-29.

44. E. Bertino, W. Kim, F. Rabitti and D. Woelk. A model of authorization for next-generation database systems. ACM Transactions on Database Systems (TODS), 16(1), 1991

45. R.A. Botha. CoSAWoE – A Model for Context-sensitive Access Control in Workow Environments. PhD Thesis, Rand Afrikaans University, November 2001

46. R.K. Burns. Report on the Homework Problem. Research Directions in Database Security, Springer- Verlag, 1992, 109-123

47. R.G.G. Cattell and D.K. Barry. The Object Database Standard (ODMG) 3.0. Morgan Kaufmann, 2000

48. N. Damianou, A.K. Bandara, M. Sloman, E.C. Lupu. A Survey of Policy Specification Approaches Unpublished manuscript, 2002

49. N. Damianou, N. Dulay, E. Lupu, M. Sloman. The Ponder Specification Language. Workshop on Policies for Distributed Systems and Networks (Policy2001), January 2001, 29-31

50. T. Didriksen. Rule based database access control - a practical approach. ACM Workshop on Role-Based Access Control, 1997, 143-151

51. L. Giuri, P. Iglio. Role templates for content-based access control. ACM Workshop on Role-Based Access Control 1997, 153-159

52. S. Godik, T. Moses (eds.). eXtensible Access Control Markup Language (XACML) OASIS Standard 1.0, 2003

53. Object Management Group. Unified Modeling Language (UML) version 1.5, 2003

54. R. Goodwin, S. Goh, F. Wu. Instance-level access control for business-to-business electronic commerce. IBM Systems Journal 41(2), 2002, 303-321.Page 10

55. P. Griffiths, B.W. Wade. An authorization mechanism for a relational database system. ACM Transactions on Database Systems (TODS), 1(3), 1976, 242–255

56. T. Gross. Creating Abstract Discretionary Modification Policies with Reconfigurable Data Objects. In Proc. of the IFIP Working Conference on Database Security (DBSec) 1994, 335-351

57. B. Hilchenbach. Observations on the real-world implementation of role-based access control. In Proc.of 20th National Information Systems Security Conf., 1997, 341-352

58. J. Hoagland, Specifying and implementing security policies using LaSCO, the language for security constraints on objects, Ph.D. dissertation, 2000

59. S. Jajodia, P. Samarati, M. L. Sapino, and V. Subrahmanian. Flexible support for multiple access control policies. ACM Transactions on Database Systems, 26(2).214--260, June 2001

60. S. Jajodia, P. Samarati, V.S. Subramanian, E. Bertino, A Unified Framework forEnforcing Multiple Access Control Policies. In Proc. of the 1997 ACM International SIGMOD Conf. on Management of Data, 1997.

61. B. Lampson. Protection. Proc. 5th Princeton Conf. on Information Sciences and Systems, 1971 Reprinted in ACM Operating Systems Rev. 8, 1 (Jan. 1974), pp18-2462. J.D. Moffett, M.S. Sloman. Content-dependent access control. Operating Systems Review, 25(2), April 1991, 63-70

63. R. Pandey and B. Hashii. Providing Fine-Grained Access Control for Java Programs. In Proc. European Conf. on Object-Oriented Programming (ECOOP), LCNS 1628, June 1999, 449-473.

64. C. Ribeiro A. Zuquete, P. Ferreira and P. Guedes. SPL: An Access Control Language for Security Policies and Complex Constraints. In Proc. Network and Distributed System Security Symposium, 2001.

65. R.S. Sandhu, E.J. Coyne, H.L. Feinstein, and C.E. Youman. Role-based access control models. IEEE Computer, 29(2), February 1996, 38-47

66. M.W.A. Steen and J. Derrick, , Formalising ODP Enterprise Policies. In Proc. Third Int. Enterprise Distributed Object Computing Conf. (EDOC), 1999, 84-93

67. J.A. Talvitie. An Object-Oriented Application Security Framework. In Proc. of the OOPSLA Workshop on Security for Object-Oriented Systems, 1993, 55-75

68. J.L. Zhao, H.J. Wang, S.S. Huang, and G. Chen, Relationship Driven Access Control in a Supply Web. In Proc. of the 12th Workshop on Information Technologyand Systems, 2002.

67. A pattern language for security models. Eduardo B. Fernandez and Rouyi PanDept. of Computer Science and Eng. Florida Atlantic University Boca Raton, FL 33431, ed@cse.fau.edu

68. C.P. Pfleeger, Security in computing, (2nd Ed.), Prentice-Hall 1997

69. R. C. Summers, Secure Computing: Threats and Safeguards, McGraw-Hill, 1997.70. C. Wood and E. B. Fernandez, ``Authorization in a decentralized database system,'' Proceedings of the 5th International Conference on Very Large Databases, 352-359, Rio de Janeiro, 1979.

71. E. B. Fernandez, R. C. Summers and T. Lang, ``Definition and evaluation of access rules in data management systems,'' Proceedings 1st International conference on Very Large Databases, Boston, 1975, 268-285.

72. Separation of Duty in Role Based Access Control System: A Case Study Authors: Francis M. Kugblenu, Memon Asim, Department of Interaction and System Design School of Engineering Blekinge Institute of Technology, Box 520 SE – 372 25 Ronneby, Sweden

73. (Sandhu, 1990) R. Sandhu;”Separation of Duties in Computerised Information Systems”, Proc. of the IFIP WG11.3 Workshop on Database Security, Halifax, U.K,1990

74. (Simon & Zurko, 1997) R. Simon, M.E. Zurko;”Separation of Duty in Role-Based Environments”; Proceedings of the 10th Computer Security Foundations Workshop (CSFW’97), page 183, 1997

75. Clark, D.D., Wilson, D.R. “A Comparison of Commercial and Military Computer Security Policies” Proc. 1987 IEEE Symposium on Security and Privacy, 184-194, April 1987.

76. “Separation of Duty in Role-Based Environments” by Richard T. Simon The Open Group Research Institute Eleven Cambridge Center Cambridge, MA 02142 by r.simon@opengroup.org Mary Ellen Zurko The Open Group Research Institute Eleven Cambridge Center Cambridge, MA 02142 m.zurko @ opengroup.org

77. J. H. Seltzer and M. D. Schroeder. “The protection of information in computer systems.” Proceedings of the IEEE, 63(9):1278–1308, September 1975.

78. (Schaad et al, 2001) A. Schaad, J Moffet, J. Jacob; “The Role Based Access Control System of a European Bank: A Case Study and Discussion”; Proceedings of the sixth ACM symposium on access control models and technologies, 2001

79.Sandhu, R. “Transaction Control Expressions for Separation of Duties” Proc. 4th Aerospace Computer Security Conference, 282-286, Dec. 1988.

80. M. J. Nash and K. R. Poland. “Some conundrums concerning separation of duty”. In Proceedings of IEEE Symposium on Research in Security and Privacy, pages 201–209, May 1990.

81. J. Crampton. Specifying and enforcing constraints in role-based access control.In Proceedings of the Eighth ACM Symposium on Access Control Models and Technologies (SACMAT 2003), pages 43–50, Como, Italy, June 2003.

82. J. Crampton. “Authorizations and Antichain”. PhD thesis, Birbeck College, University of London, UK, 2002.83. T. Jaeger and J. E. Tidswell. “Practical safety inexible access control models”. ACM Transactions on Information and System Security (TISSEC), 4(2):158–190, 2001.

84. T. Jaeger and J. E. Tidswell. “Practical safety inexible access control models”. ACM Transactions on Information and System Security (TISSEC), 4(2):158–190, 2001.

85. J. Tidswell and T. Jaeger. “An access control model for simplifying constraintexpression”. In Proc. ACM Conference on Computer and Communications Security(CCS), pages 154–163, 2000.

86. Ferraiolo, D., Cugini, J., Kuhn, D. R. “Role-Based Access Control (RBAC): Features and Motivations” Proc. 1995 Computer Security Applications Conference,241-248, December 1995. Wesley Longman, 1994

87. Thomas, R. K., Sandhu, R. S. “Conceptual Foundations for a Model of Task-based Authorizations” Proc. of The Computer Security Foundations Workshop VU, June 1994