Developers and Identity Services - Modernizing Access Control with Authorization Service. An Oracle White Paper November PDF

Please download to get full document.

View again

of 14
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report
Category:

Health & Fitness

Published:

Views: 6 | Pages: 14

Extension: PDF | Download: 0

Share
Related documents
Description
Developers and Identity Services - Modernizing Access Control with Authorization Service An Oracle White Paper November 2008 Developers and Identity Services - Modernizing Access Control with Authorization
Transcript
Developers and Identity Services - Modernizing Access Control with Authorization Service An Oracle White Paper November 2008 Developers and Identity Services - Modernizing Access Control with Authorization Service Executive Overview...3 Introduction...4 Authorization Challenge...4 Protecting Business Logic...4 Enforcing Data security...6 Incorporating Risk...6 Administration...7 Policy Sharing...7 Delegation...7 Audit...8 Authorization Service The Modern Approach...8 Externalization...8 PAP, PEP, PDP & PIP...8 Centralized Administration Sharable, Re-useable policies Externalize & Centralize with Oracle Entitlements Server Extend Authorization Service with Risk-aware Oracle Adaptive Access Manager Conclusion Developers and Identity Services Modernizing Access Control With Authorization Service Page 2 Developers and Identity Services - Modernizing Access Control with Authorization Service EXECUTIVE OVERVIEW Service-Oriented Security (SOS) aligns with the overall Application-Centric approach of the entire Oracle Fusion Middleware platform - with the goal of providing a comprehensive, standards-based, developer-friendly platform. By leveraging and sharing many of the common Identity Services, SOS allows developers to spend the effort on where it counts the most the application logic itself. However, to truly move away from the traditional silo-based approach in dealing with identity management, application developers building identity-enabled applications must look to the benefits of these services and understand when and how to use these services in their application design. However, to truly move away from the traditional silo-based approach in dealing with identity management, application developers building identity-enabled applications must look to the benefits of [Identity Services] and understand when and how to use these services in their application design. This is the second in a series of Developers and Identity Services whitepapers, each intended to focus on a specific area of Identity Services from a developer standpoint. It builds on the concepts of Identity Services and Identity Externalization defined previously in - Service-Oriented Security An Application Centric Look at Identity Management - available at: df Our first paper, Developing with Identity Services Tacking Identity Data with Identity Hub available at: examines the first key ingredient in any identity-enabled application the identity data. As a developer begins to design the business logic of the application, the next security challenge is to ensure proper access to various aspects of the application from data and transactions to application access. The topic of Authorization will be the focus of this paper. Developers and Identity Services Modernizing Access Control With Authorization Service Page 3 INTRODUCTION At the onset, application authorization appears to be an application-specific problem to be solved by the application developer. After all, it is the application and its resources that need to be protected. Traditional applications often define proprietary policies that can only be enforced and administered by proprietary mechanisms. A developer may want to restrict access to certain business logic. Business objects may also be subject to restrictions on the kinds of operations a user is authorized to perform - operations such as viewing or modifying. At the lower level, access to application or identity data from the repository must also be carefully considered. Whether it is a packaged application from a vendor or a custom application within an enterprise, once an application is deployed in a production environment, any new requirements, customization or any modification to the authorization model would likely require a change in the code by the developers. These limitations highlight a general problem in that there is no enterprise level visibility and control over user entitlements the set of privileges governing what an application user can do. With applications scattered across an enterprise, administration of these proprietary authorization policies become a nightmare. In many situations, policies governing similar applications - for example, a set of financial applications - will likely to be similar. Administrators are forced to define and maintain different flavours of similar policies across these applications. And when it comes to compliance, the ability to audit and report on user entitlements across these disjoint systems becomes extremely difficult if not nearly impossible. These limitations highlight a general problem in that there is no enterprise level visibility and control over user entitlements the set of privileges governing what an application user can do. AUTHORIZATION CHALLENGE Security requirements of an application are as important as the business requirement of any enterprise applications today. In fact, with the emergence of tighter corporate policies and government regulations, authorization has become an integral part of the business requirements. Developers are being asked to deliver applications that can enforce a high level of security right out of the box in both the enforcement and administration of user entitlements. Protecting Business Logic In a nutshell, securing the business logic of an application technically boils down to securing the application software components and the application business objects. The runtime logic needs to decide whether or not to allow access to a particular function or a particular piece of data. From a developer s perspective, if the Developers and Identity Services Modernizing Access Control With Authorization Service Page 4 The emergence of LDAP directory services as a centralized user and group repository allows application developers to leverage this information for both authentication and authorization purposes. application data contains all the data needed for making authorization decisions, he can implement the security around the application data itself. Traditionally, this is the approach and it gives the developer full control over the entire authorization model from the types of information needed for the authorization decision to the decision logic itself. This creates a rather rigid model where authorization logic is completely hard-wired inside the application. While it gives the developer a great deal of control over the authorization model during development, it gives very little room for customization or expansion once the development has completed and the application has been deployed. Any changes needed in the authorization logic will likely require a code change. Also, any existing information from other applications or repositories must be pulled into the application metadata in order to be consumed, making data synchronization the responsibility of the developer as well. For example, a manager is allowed access over her direct reports salary information. The manager-direct-report relationship, which may exist in a human resource management system (HRMS) or an LDAP directory, must be synchronized into the application metadata. The emergence of LDAP directory services as a centralized user and group repository allows application developers to leverage this information for both authentication and authorization purposes. Some applications integrate directly with LDAP by directly connecting to the directory. In the J2EE world, Java Authentication and Authorization Service (JAAS) and Java Authorization Contract for Containers (JACC) provide a container layer of abstraction, freeing the developer from dealing with the underlying authorization provider and its implementation. They provide developers a framework to implement declarative security by defining application-level permissions and privileges, which are then mapped to a set of security roles. These roles are in turn assigned to either any individual user or a group from underlying provider. The permission and privilege definitions, along with the role mappings, are defined outside of the application in the various deployment descriptors, which can be modified without changing the application. Furthermore, changes to users, groups and group membership in the provider (for example, an LDAP provider) can alter the security of the application without involving the developers. However, certain changes such as adding a new permission class or changing the descriptors would still require a change in the application or a redeployment of the application. While it is not a complete de-coupling, this level of authorization externalization has given developers and application administrators some flexibility in customizing and expanding application security. But role-based security has its limitation. Suppose a financial application would like to enforce a policy that a customer service representative can only view customer data between the hours of 9am to 5pm. Here the current time is being used as part of the authorization criteria. In addition, enforce a policy where the customer service representative can only see your social security number on the screen but is not allowed to print it - while an account manager is allowed to do so when printing a report. In this example, the output type (screen vs printer) becomes part of the authorization criteria on the Developers and Identity Services Modernizing Access Control With Authorization Service Page 5 same subject (social security number). These kinds of authorization decision require a much richer context to provide all the necessary information for evaluation. Programmatic security is always an option by once again hard-wiring the decision logic into the code which puts the developer back to the original dilemma. Once the logic is baked in, it is difficult for the deployment to customize them. What is more important is the ability to reflect any data security enforcement as a security policy rather than a baked-in logic in the code. Enforcing Data security Suppose in our financial application, a policy is defined to allow the regional account manager to only see the customer accounts in his region. From a developer standpoint, a way to enforce this is by programmatically generating the right filter during a database lookup or, in other words, generating the right WHERE clause for a SELECT statement. While this is doable from within the application, the authorization decision should belong outside of the application. Access by any database client or any application should ideally be secured by the same logic. For example, a reporting utility should be governed by the same policy and should not be required to re-implement the predicate generation logic over and over again. What is more important is the ability to reflect any data security enforcement as a security policy rather than a baked-in logic in the code. Using the same example as before a policy stating that a manager is allowed access over her direct reports salary information may need to be enforced at the data level. Incorporating Risk While user entitlements define who has access to what, enterprises are beginning to look for more context-aware authorization mechanisms to protect their enterprise environment. For example, in deciding whether a user should be allowed to transfer corporate funds to a holding account, a financial application may authorize the transfer if the risk is not too high where the risk is calculated based on certain criteria in the context of the transaction. In this example, a transaction might be considered as high risk if the user is connecting from outside the corporate network and is not using strong authentication. It might also be considered as high risk because the user has already made more than 4 transfers within the past 24 hours. These types of risk-based policies in particular are very customer focused and tend to change frequently as well - making them difficult requirements for a developer to satisfy during the development cycle of the application. Developers and Identity Services Modernizing Access Control With Authorization Service Page 6 In most cases, it is business users rather than IT administrators who maintain and administer user entitlements. How user entitlements are represented is an important consideration. Administration When dealing with a single application, a proprietary handling of policy administration may not be a big deal. However, when you look at a typical enterprise with its large number of applications deployed, a consistent administration experience becomes crucial. Lack of any standards has allowed developers to take different approaches in how authorization policies are defined and administered. While the JACC/JAAS model provides some consistency in the way LDAP and J2EE security is used, developers are often asked to develop more business-user friendly interfaces within the application rather than forcing business users to deal with XML files and LDAP users and groups. In most cases, it is the business users rather than IT administrators who maintain and administer user entitlements. How user entitlements are represented is an important consideration. Where user entitlements are stored is also an administration headache. For example, a user s LDAP group membership may determine her entitlements in a JAAS-enabled J2EE application while her responsibilities in some of the ERP systems are defined within the ERPs own authorization models. With scattered authorization mechanisms across an enterprise, obtaining an enterprise view of user entitlements is a non-trivial task as it requires access to multiple systems. Each application will carry a similar policy and will implement its own authorization decision logic all doing virtually the same thing. Policy Sharing When looking across multiple applications, the lack of ability to share and reuse authorization policies is also apparent. Consider one of the previous policies mentioned where the regional account manager is restricted to see and manage only the customers within the region. There could be multiple financial applications in place each of which will likely require a similar policy to be created. The result each application will carry a similar policy and will implement its own authorization decision logic all doing virtually the same thing. This creates a huge headache for the administrators to, not only understand the different policy models, but also to maintain integrity across the enterprise. Delegation Delegation of access control is a common but difficult problem for any developer. In a financial application, an account owner might want to delegate certain capabilities, such as transfer privilege, to other account users. An account manager might delegate access to his clients to his manager while he goes on vacation. For a developer, the problem is not as simple as assigning the appropriate access to the account manager. Suppose while during the vacation, one of the clients has moved to another account manager under a different management chain. The initial delegation is now obsolete since the client no longer belongs to this management chain. These types of authorization integrity are difficult to capture within the application logic because the desired delegation model is often complex and customizable. Developers and Identity Services Modernizing Access Control With Authorization Service Page 7 Similar to the administration pain, the lack of enterprise level visibility of user entitlements is a key contributor in the challenges and inefficiencies seen in the area of audit and compliance. Audit With government regulations such as Sarbanes-Oxley, the ability to report and review user entitlements across an enterprise is mandatory for enterprises. The pitfalls in policy administration, policy sharing and delegation are amplified in the ability to efficiently perform audit on user entitlements. Policies may be defined in ways that are not obvious to determine the exact user entitlements. Since each application has it own way of defining policies, any auditor or attester may have to deal with inconsistent formats spanned across multiple applications of various flavours in order to obtain the full picture of user entitlements. Similar to the administration pain, the lack of enterprise level visibility of user entitlements is a key contributor in the challenges and inefficiencies seen in the area of audit and compliance. AUTHORIZATION SERVICE THE MODERN APPROACH As we can see, there is a strong need to define a centralized Authorization Service that provides the necessary support for both the developers and application customers to satisfy their authorization requirements. This distinction and separation allows authorization policies to change without impacting the application logic or in other words, allowing a greater degree of customization without requiring a change in the application code. Externalization The key concept of Authorization Service is to enable entitlement externalization. To a great extent, the JACC/JAAS model has taken a step in this direction. Entitlement externalization separates the authorization logic from the business logic within an application. The application takes care of enforcing the authorization check. For example, it triggers a check whenever a customer s social security number is to be fetched to see if the person accessing the application has access to this data. The decision, however, is made completely outside of the application. It is made by the authorization services based on policies defined within the authorization services. The application logic does not care whether the policy only allows the data to be fetched between business hours or disallows it if access to the application is through VPN. This distinction and separation allows authorization policies to change without impacting the application logic or in other words, allowing a greater degree of customization without requiring a change in the application code. PAP, PEP, PDP & PIP To efficiently support entitlement externalization, the following services must be present as part of the authorization service to provide the needed functionalities: A Policy Administration Point (PAP) where administrators can create and modify application specific policies. Developers and Identity Services Modernizing Access Control With Authorization Service Page 8 A Policy Enforcement Point (PEP) that is responsible for triggering entitlement policy decisions within applications. A Policy Decision Point (PDP) that provides the actual entitlement decisions on behalf of the PEP. One or more Policy Information Points (PIPs) which supplies data and information to the PDP to help it make accurate policy decisions. Figure 1. Authorization Service Architecture By reaching out to the PIPs, PDP will consider Joe s current identity (including any groups, attributes or roles he may be aligned with), any attributes tat he may have (such as his State), and compare these against policies currently established for the resource SSN. The centerpiece of this architecture is the PDP. It must contain application specific policies and be able to take requests from the PEP such as, Can this user have this privilege on this resource? The PDP will consult its policies and either returns a Grant or Deny response to the application PEP along with any additional criteria or Obligations that the PEP must fulfill either before or after granting access to the user. For example, our financial application, the PEP, might ask the PDP, Can user Joe have the view privilege for the resource SSN? By reaching out to the PIPs, PDP will consider Joe s current identity (including any groups, attributes or roles he may be aligned with), any attributes that he may have (such as his State), and compare these against policies currently established for the resource SSN. Joe happens to be a customer service representative accessing a use
Recommended
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks