|
|
The requirements for providing security access to enterprise applications have evolved dramatically in the past decade. The advent of the Web led to the need to protect the perimeter of the enterprise with technology principally focused on “keeping the bad guys out.” The introduction of Web security and single sign-on solutions pushed access and security deeper into the enterprise. Identity management systems enabled the management of millions of users. Access control and federated identity systems allowed customers and partners to reach deeper into the enterprise, increasing automation and self-service, and improving cost-efficiency.
In the last few years, changes in the enterprise application landscape have mandated a change in the approach to enterprise security. Sarbanes-Oxley mandates documented controls on who has access to information systems that affect the finances of publicly held companies. Health care and privacy laws have placed stricter requirements on access to applications and auditing of access. A rapid rise in outsourcing of application development means that security logic embedded in the application tier is no longer directly controlled by the enterprise. These changes in the regulatory and development environments mandate a change in how access to the application tier is managed.
The next wave of application security technology is the management of user entitlements and to the separation of application security logic from the application tier. Oracle Entitlements Server is a product that provides centralized entitlements management with distributed enforcement of access to both application components and application business objects. This document focuses on how Oracle Entitlements Server can be used to solve your application entitlements problem.
The word ‘entitlements’ can mean different things to different people. For the purposes of this paper we will define entitlements to be the set of privileges that govern what an application user can do. The ability to manage and enforce these permissions is also know as fine-grained authorization.
Figure 2-1 shows a typical scenario for an online, retail banking application. The application must provide certain capabilities to external users of the application as well as employees of the bank. Customers must be able to view their balances, change their profile information, and conduct certain transactions. Bank employees must be able to make balance adjustments to customers, open new accounts for customers and provide other customer services.
The bank’s entitlements system must be flexible and able to answer questions like the following:
The entitlements system is used to create and manage those actions and to make and record access decisions that are made at run time. The banking application may consist of a combination of software components (e.g. JSP’s, EJB’s, links) as well as logical objects such as customer accounts. The bank’s entitlements system must be able to manage entitlements for both types of resources in the application. The bank also needs to be able to provide new capabilities to their customers that they can roll out quickly. As these new capabilities are rolled out, the user’s entitlements will change also. The bank needs to do this without requiring recoding and retesting of the application.
There are a number of challenges associated with managing and enforcing entitlements in an application.
The first challenge is the presence of embedded decisions. These are authorization decisions that are hard-coded in the application code. Embedded decisions present several problems. The security logic may not be consistent across applications. Any change to the security logic requires changes to the application which must then be retested and redeployed. If these access decisions are in the application code then there is no central management or oversight over the security logic. There is also no way to analyze the access logic to determine who can do what. Finally, the decision may not be audited.
The second challenge is the presence of existing security technologies in the enterprise. Many companies have deployed centralized directories for storing user data, Web SSO systems, and user provisioning products. Any entitlements system must be able to integrate with these technologies to get user identities and user attributes required to make access decisions.
The last challenge is associated with the complexity of the entitlements model within an organization. Industries that are highly regulated may have to create complex rules to govern access to certain actions or data in an application. Furthermore, large enterprises may have complex hierarchies of roles, application resources or actions that can be performed. An Entitlements management system must allow the user to centrally define and manage application entitlements and enforce those entitlements across a variety of application development environments.
A major benefit of Oracle Entitlements Server is that it allows you to get security logic out of the application where it can be managed from a central point. Figure 2-2 shows a prototypical trading example. This application may be used by many different types of users. However, only those users who are traders are allowed to make trades in the application. Furthermore, traders are restricted to trade only for those client accounts for which they are authorized and only up to a specified limit set for each account.
The panel on the left shows the traditional way to control access in the application. In this case, the access control logic is embedded as code in the application. The application has to know how to go out to other systems in the infrastructure to get information about the user and information about the account. This makes the application brittle and difficult to change. It also means security logic is visible only by inspecting the code. Finally, the access decision may not be audited.
The panel on the right shows how the application would look using Oracle Entitlements Server to externalize the security decision. Instead of complex logic coded as part of the application, the developer uses an authorization call to get an access decision.
The authorization call (“Is Access Allowed”) is made with the following information:
In this case, Oracle Entitlements Server is responsible for getting the required information about the user and the account. It gathers the required information, evaluates the policies that apply to accounts in the application and returns an access decision. It also audits all the information about that decision.
It is important to note that what is shown in Figure 2-2 is how a developer would make an explicit call for an authorization decision. For objects managed by WebLogic Server, this call is made for you automatically by the server. For J2EE objects like JSPs, EJBs, Web Services and for WebLogic Portal objects like books, pages, and desktops, the “IsAccessAllowed” call is made any time an application tries to access one of these resources. To control access to these “container-managed” objects, the application does not need to be changed.
Any technology or product that is intended to solve the type of entitlements problem described above must be able to do certain things.
First, an entitlements solution must have a rich model for modeling access control. In particular it must be able to define and manage hierarchies of user roles, permission, and application resources. It must support an entitlements model that is rich enough to handle complex sets of conditions under which access will be granted (or denied). It must be able to enforce entitlements on both software components and business objects. Finally it must have the ability to represent and implement a variety of access control paradigms from role-based access control (RBAC) to data driven approaches based on user and resource attributes.
Next, an entitlements solution has to be easy to administer. Central management of entitlements is a key feature. However, while access should be administered centrally, those policies should be distributed to a set of policy decision points (PDPs) which are close to the application. Since business conditions are constantly changing, business users should be able to manage entitlements for their applications. The entitlements solution must provide the ability to approve and version security policy.
Finally, an entitlement solution should be easy to deploy and integrate with other systems in the corporate infrastructure. It should be flexible enough to allow the user to choose between a centralized policy decision point and a fully distributed set of policy decision points (PDPs). It should be possible to make calls to the PDP from a variety of applications environments through some language neutral approach (e.g. like Web Services). It should be easy to integrate the entitlements solution with security infrastructure that is already present in the enterprise including corporate user stores, Web SSO solutions, and user provisioning.
|