| Oracle® Fusion Applications Developer's Guide 11g Release 4 (11.1.4) Part Number E15524-09 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Developer's Guide 11g Release 4 (11.1.4) Part Number E15524-09 |
|
|
PDF · Mobi · ePub |
This chapter describes the components that developers use to secure Oracle Fusion applications and web services by enforcing authentication and authorization.
This chapter includes the following sections:
Section 47.1, "Introduction to Securing Oracle Fusion Applications"
Section 47.2, "Authentication Techniques and Best Practices"
Oracle Fusion Applications security consists of two main components, namely authentication and authorization. Authentication establishes the identity of the user. Authorization ensures that users only have access to resources to which they have been granted access.
When developing an Oracle Fusion application, it is necessary to ensure that authentication and authorization polices are properly enforced throughout the application. The implementation details may vary depending on the technology used in the application.
For complete details about the Oracle Fusion security approach, including concepts and best practices, see the Oracle Fusion Applications Security Guide.
Additionally, for information about security and extending Oracle Fusion applications, see the Oracle Fusion Applications Extensibility Guide.
Oracle Fusion applications are built on top of a fixed set of internal and third-party technologies. This set of technologies defines what may be used to develop, build, package, and run all Oracle Fusion applications. Each technology and component may have its own specific requirements for security implementation.
Figure 47-1 depicts the components in the Oracle Fusion Applications security approach.
The Oracle Fusion Applications key technologies and features include:
Application resources including ADF task flows, ADF components, and ADF Business Components. For more information, see:
Oracle Platform Security Services (OPSS) security. For more information, see:
Oracle Web Services Manager (Oracle WSM). For more information, see:
Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Oracle WSM policy interceptors. For more information, see Chapter 51, "Securing Web Services Use Cases."
Identity providers including the LDAP-based provider and the file-based provider (jazn-data.xml file). For more information, see:
Oracle Fusion application user sessions. For more information, see Chapter 48, "Implementing Application User Sessions."
Oracle Fusion Data Security policies for data security. For more information, see Chapter 49, "Implementing Oracle Fusion Data Security."
Oracle Fusion Applications security policies for function security. For more information, see Chapter 50, "Implementing Function Security."
Some of the technologies have an additional layer of security on top of the main security technologies.
OPSS security framework provides security to Oracle Fusion Middleware, including Oracle WebLogic Server, Oracle SOA Suite applications, Oracle WebCenter Portal, Oracle ADF applications, and Oracle Entitlements Server. OPSS is designed to be portable to third-party application servers. Developers can therefore use OPSS as the single security framework for both Oracle and third-party environments, thus decreasing application development, administration, and maintenance costs.
OPSS comprises Oracle WebLogic Server security and Oracle Fusion Middleware security. Figure 47-2 illustrates the layered architecture that combines these two security frameworks.
Figure 47-2 depicts the various security components as layers. The uppermost layer includes the Oracle WebLogic Server and the Java applications running on the server; under it, is the layer consisting of APIs for Authentication, Authorization, Credential Store Framework, User and Role, and identity virtualization; the bottom layer includes the Security Service Provider Interface (SSPI) layer and the service providers. The bottom layer interacts with security data repositories, such as LDAP and database servers.
In addition to the list of providers shown in Figure 47-2, other providers include the role mapping and audit providers.
For more information about OPSS, see the "Understanding Security Concepts" part in the Oracle Fusion Middleware Application Security Guide.
The Security Service Provider Interface (SSPI) layer is accessed through OPSS APIs and provides Java EE container security in permission-based (JACC) mode and in resource-based (non-JACC) mode. It also provides resource-based authorization for the environment, thus allowing customers to choose their security model.
Oracle Web Services Manager (Oracle WSM) provides a policy framework to consistently secure Web services. Application developers attach policies using JDeveloper to the clients and services. Authentication and authorization are enforced on the services by Oracle WSM based on the policies attached to the service. The policies determine how the client and service communicate. For the predefined policies the naming convention indicates the behavior of the policy.
For example, given a policy called:
oracle/wss11_saml_token_with_message_protection_client_policy
oracle is the path of the policy,
ws11 indicates the Web services standard,
saml_token is the authentication token,
with_message_protection indicates whether message protection is enabled,
client_policy indicates the type of policy, server or client.
For more information about Oracle WSM, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
How Policies are Executed
When a request is made from a service consumer (also known as a client) to a service provider (also known as a Web service), the request is intercepted by one or more policy interceptors. These interceptors execute policies that are attached to the client and to the Web service. There are five types of interceptors (reliable messaging, management, WS-Addressing, security, and MTOM) that together form a policy interceptor chain. Each interceptor executes policies of the same type. The security interceptor intercepts and executes security policies, the MTOM interceptor intercepts and executes MTOM policies, and so on.
Policies attached to a client or Web service are executed in a specific order via the Policy Interceptor Pipeline, as shown in Figure 47-3.
When the interceptor encounters a policy that deals with authentication or authorization, it delegates the task to OPSS. If the authentication using OPSS is successful, a security subject with the identity is established. Similarly, processing continues only if the authorization using OPSS for the established identity is successful.
Oracle ADF security framework is the provider of authentication and authorization services to Oracle Fusion Applications. Oracle ADF security is built on top of OPSS architecture, and provides declarative, permissions-based protection for ADF bounded task flows and top-level web pages that use ADF bindings.
Oracle ADF security and Oracle JDeveloper provide the tools to interact with the file-based identity and policy store, as well as the architecture to enforce the security definitions on the secured resources.
For more information about ADF Security, see the "Enabling ADF Security in a Fusion Web Application" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).
Application user sessions allow applications to store the security and application context for Oracle Fusion Applications. Session attributes contain common information such as the current user and the user's associated roles, current language, date and number formatting, as well as application-specific attributes.
A session is created after the security subject has been established. In the context of Oracle ADF, a session is created using a filter, while a context is created in Oracle SOA Suite using an interceptor. When a session is created, information about the user's associated roles are stored in the session.
Oracle Fusion Data Security relies on the security context in the session when deciding whether a user is allowed to access particular data. If the session is not established, the user cannot access any secured data.
Application user sessions are associated with pillars and, ideally, there should be only one session per pillar. In the case of web services, if the client and server are on the same pillar then they share the same session. Subsequently, session context is specific to a particular pillar. That is, everything running on that same pillar should see the same context.
For details about application user sessions, see Chapter 48, "Implementing Application User Sessions."
Oracle Fusion Data Security implementation is a solution specifically for Oracle Fusion Applications. The security definitions for who can access what data are stored in the Oracle Fusion Data Security model in the Oracle Fusion Applications schema. Developers create these definitions through SQL scripts, APIs or UIs. The definitions are then extracted and version controlled as seed data.
Oracle Fusion Data Security definitions are enforced either declaratively or programmatically in their application. In the context of an Oracle Fusion application, developers can do the following:
Declaratively enforce security on the entity object level,
Declaratively enforce security on the view object level through view criteria,
Programmatically apply security view criteria,
Programmatically call APIs to check whether a user is authorized to access data or obtain a predicate used to retrieve the data the user is authorized to access.
The data security implementation relies on the security context defined in the application user session. Even if OPSS authenticates the user and the security subject is established, the user cannot access any data unless the application user session is established.
For details about Oracle Fusion Data Security, see Chapter 49, "Implementing Oracle Fusion Data Security."
Oracle Virtual Private Database (VPD) enables controlling access to data on the database level using security policies associated with database objects. Use VPD when securing Personally Identifiable Information (PII) on the database level, for example.
For more information about VPD, see the "Using Oracle Virtual Private Database to Control Data Access" chapter in the Oracle Database Security Guide.
Oracle Data Integrator (ODI) is used to move and transform data among systems using specific features for authentication and authorization. Authentication is based on Oracle Platform Security Services (OPSS). Following authentication, processing specific to ODI occurs in which OPSS principals are mapped to definitions stored in ODI to determine identity access rights. The security definitions controlling authorization decisions are stored in an ODI master repository.
For more information about ODI, see the "Understanding Oracle Data Integrator" part in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Oracle Fusion applications reside in containers that automatically handle authentication. The container intercepts all requests entering the system, and ensures that users are properly authenticated and the security context propagated.
Invoking the ADF Security wizard when developing an application configures the application to enforce security at runtime.
When a request is received with no subject defined, Oracle Platform Security Services creates a subject containing the anonymous user principal and the anonymous role role principal. Oracle Platform Security Services is configured by the JPSFilter. With this security subject, unauthenticated users can access public resources. When accessing secure resources, the adfAuthentication servlet forces users to authenticate. The security configuration determines the login module to be used for authentication.
By default, Oracle WebLogic Server is the authenticator used when developing applications with Oracle ADF. Different configurations can also be used, such as an Oracle Single Sign-On solution.
Oracle Identity Management Repository stores users, enterprise roles and their relationships. During development the identities exist in two places; the jazn-data.xml file in Oracle JDeveloper and the embedded LDAP of JDeveloper's Integrated WebLogic Server. In staging environments, these definitions reside in LDAP on standalone Oracle WebLogic Server.
Test users created during development within Oracle JDeveloper enable testing applications in development. These test users are not migrated with the completed application. Rather, they are for testing purposes only. Enterprise users are added by a system administrator who defines users/groups in the enterprise identity store.
Users are not assigned permissions directly, rather access is assigned to roles. Roles group particular permissions required to accomplish a task; instead of assigning individual permissions, roles match users with the permissions required to complete their particular task.
There are two main types of roles, enterprise and application. Oracle Identity Management Repository contains enterprise roles that are available across applications. These are created as groups in LDAP, making them available across applications. Application roles are stored in the application-specific policy store.
Functional roles include job, duty, data, abstract and privilege roles. Role are enforced by a role hierarchy. In Oracle Identity Management Repository, these logical roles are translated into technical Oracle Platform Security Services roles.
Segregation of Duties (SOD) ensures that no single individual has control over two or more phases of a business transaction or operation. The goal of segregation of duties is to prevent information misuse such that the same user cannot both create and approve transactions.
Oracle Applications Access Controls Governor (AACG) is used to manage, remediate and enforce user access policies. AACG ensures effective segregation of duties at the implementation site.
The data in the file-based identity store (jazn-data.xml file) is used when authenticating within Oracle JDeveloper running Integrated WebLogic Server. The identity data in the jazn-data.xml file should not be synchronized with the identities in the LDAP staging server. By default, the deployment configuration disables data synchronization between the jazn-data.xml file and the LDAP server. This setting should not be modified.
The data in the file-based security policy store (jazn-data.xml file) is used when authorizing within Oracle JDeveloper running Integrated WebLogic Server. Changes to the security policies in the jazn-data.xml file must be migrated to the LDAP staging server by a security administrator. By default, the deployment configuration disables data synchronization between the jazn-data.xml file and the LDAP server. This setting should not be modified.
Identity propagation is a fundamental requirement for securing Oracle Fusion Applications. It provides that the same user identity is visible across different processes and technologies boundaries. While there some cases where the identity is implicitly propagated, in several scenarios explicit configuration is required.
Web Services and SOA
In the case of Web services and SOA applications, you can propagate identities by attaching Oracle Web Services Manager policies to the client and service. When a client sends a request to a service, a policy interceptor intercepts the request. On the client side, the policy interceptor packages the identity to be transported according to the policy attached to the client. On the service side, the interceptor processes the request based on the policy and delegates authentication to Oracle Platform Security Services. If the authentication succeeds, a security subject with the identity is established.
Remote Method Invocation (RMI)
The executing user is automatically propagated when using RMI. If a different identity than the executing user needs to be propagated, it has to be explicitly passed through Java Naming and Directory Interface (JNDI) context.
Oracle WebCenter Portal
Oracle Fusion applications deploy Web Services for Remote Portlets (WSRP). As web services, they rely on Oracle Web Services Manager for Identity Propagation.
Oracle Data Integrator (ODI)
In a OPSS-enabled environment (Oracle Platform Security Services), ODI authentication happens in two phases.
Figure 47-4 depicts the first phase is OPSS authentication, during which time a subject is created using the OPSS framework. The second phase is the ODI authentication itself, which is based on the previously created subject. ODI lists the ODI roles having one or more OPSS principals of the subject as members. Users will need to choose one ODI role from here. ODI will then create an ODI security token based on this role. This ODI security token contains an ODI role and the list of principals associated with the current OPSS subject.
Audit Identity
When switching to the application identity, in order to preserve the submitting identity for auditing purposes, you must propagate the identity to be audited.
Auditing is based on who columns, which are populated with session data. When the session is established, it is initialized using the current identity. The session APIs expose a method to manipulate the identity to be used for auditing. This method allows teams to control which identity is stored as the audit identity. Example 47-1 illustrates the syntax of this method.
Example 47-1 Controlling which Identity Is Stored as the Audit Identity
ApplSession.setHistoryOverrideUserName()
The session is not propagated, rather only the identity is propagated. As the session is initialized using the identity, any application specific values are lost. To prevent this, you must pass the audit identity and override the audit identity on the session.
It is recommended for the service provider to add an extra parameter to the service so as to store the original user ID (historyOverrideUserName, of type String). In order to invoke the service, the service method consumer must fill in the original user ID as part of the payload. Within the service, the value passed is populated on the session as shown in Example 47-2.
Application user sessions are associated with pillars and, ideally, there should be only one session per pillar. In the case of web services, if the client and server are on the same pillar then they share the same session. Subsequently, session context is specific to a particular pillar. That is, everything running on that same pillar should see the same context.
Authorization ensures that users only have access to the resources to which they have been granted access. Authorization decisions are based on policies stored in a policy store. There are two main types of policy stores: OPSS application security repository and Oracle Fusion Data Security repository. The OPSS repository contains the security definitions that control access to applications. The Oracle Fusion Data Security repository contains the security definitions controlling data access.
The enterprise security administrator exports the OPSS application security repository to the jazn-data.xml file policy store. The security definitions in these repositories control access to application functions. The policies defined in the jazn-data.xml file are used during development. For testing and implementation, the file-based policy store content is migrated into LDAP.
Policy Store Content
Enterprise security administrators are responsible for managing application security policies. Oracle Fusion Applications developers can add new application security policies, but must not modify existing application security policies.
Roles
The jazn-data.xml file identity store contains the application roles specific to a given application. These roles are not visible outside the application. The policies are created against an application role. Permissions are grouped into a permission sets for administrative purposes. And permission sets are granted to the application roles. Developers must not allowed to modify role hierarchy or remove privileges defined by the permission sets granted to existing application roles.
Design Time
During development, you can interact with the jazn-data.xml file policy store using the tools and user interfaces provided in Oracle JDeveloper.
For more information, see the "Enabling ADF Security in a Fusion Web Application" chapter in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).
Runtime
When Oracle ADF security is enabled in an application, the Web container uses the policies in OPSS application policy store for authorization. Oracle ADF security enforcement logic checks whether the user, represented by the JAAS subject, has the correct permissions to access the resource.
The subject contains the user's principals, which include a user principal with the user's name and list of role principals, as well as enterprise roles and application roles obtained from the policy and identity stores. The principal is created to represent all of the user's memberships in application roles defined in the policy store. In turn, each application role may have multiple granted permissions in OPSS application policy store.
At runtime, the page context determines whether the current user has view permissions for the page being accessed. If the page includes an activity of a bounded task flow, the task flow controller determines the permissions. If the page is a top-level page with an associated page definition file, the Oracle ADF model determines the permissions for the page.
The OPSS service provider interface checks whether the subject includes the roles with the relevant permissions required to access the page. If the user is authorized to access the page, then the task flow is initiated. If the user is not authorized, ADF Controller throws an exception and passes control to an exception handler specified by the task flow configuration.
It is also possible to include an API that checks whether the current user has access to a resource.
Developer created additions to the policy store must be migrated to LDAP by a security administrator.
Oracle Fusion Data Security repository is used to control access to data.
Policy Store Content
Enterprise security administrators are responsible for managing data security policies. Oracle Fusion Applications developers can add new data security policies, but must not modify existing data security policies.
For more information about Oracle Fusion Data Security, see Chapter 49, "Implementing Oracle Fusion Data Security."
Design Time
During development, developers can interact with the Oracle Fusion Data Security repository through the Oracle Authorization Policy Manager.
Runtime
Data security relies on session information for the user identity. When a user session is created at runtime, the user information for that session and the flattened list of roles for the user are propagated to the database. This information is used to identify the user and the user's access level based on the policies in Oracle Fusion Data Security repository.
Data security is not automatically enforced, rather developers must enforce data security either declaratively on the entity object or view object, or programmatically, using API calls.
There are some cases in which you must implement authentication from an external source or using a different identity. You can implement authentication using APIs, Expression Language or a non-browser based login.
You can implement authentication by using user and role APIs. For more information, see the "Developing with the User and Role API" chapter in the Oracle Fusion Middleware Application Security Guide.
You can use the security subject APIs to run an application under an identity different from the current user.
You can use Expression Language to access security context information. Some useful expressions are as follows:
securityContext.userName
securityContext.authenticated
securityContext.userInRole
securityContext.userInAllRoles
securityContext.userGrantedPermission
securityContext.userGrantedResource
securityContext.taskflowViewable
securityContext.regionViewable
Note that decisions about user's access rights should not rely on the user's role information since role definitions may be changed. Instead access should be based on available permissions.
For more information, see the "Enabling ADF Security in a Fusion Web Application" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).
For information about using non-browser based security, see the "Securing Your Integrated Excel Workbook" chapter in the Oracle Fusion Middleware Desktop Integration Developer's Guide for Oracle Application Development Framework.
Authorization is implemented using function security policies that control access to application functions. At the most fundamental level, authorization is based on standard JAAS (Java Authentication and Authorization Services) permissions and OPSS permission sets (also called entitlements) which may be granted to secure specific application artifacts. Oracle ADF defines the JAAS permissions needed to secure certain Oracle ADF application artifacts, including ADF bounded task flows and, in the case of top-level web pages, ADF page definitions files.
Security is automatically enforced on all ADF bounded task flows and top-level web pages that use ADF bindings and are not contained in a bounded task flow.
Security is not automatically enforced on web service methods. You can use API calls to define permissions in the policy store and enforce security based on these permissions.
Implementing function security requires the following main steps:
Consult a security administrator to export all predefined function security policies of the application that you are customizing into a jazn-data.xml file.
Copy the exported jazn-data.xml file into the application workspace.
Create an entitlement to group one or more ADF resources and their corresponding actions to entitle end users to access the resource.
Grant the entitlement to a custom duty role that was added to the Oracle Fusion application policy store.
Enable ADF Security for the application by running the Configure ADF Security wizard.
After running the ADF Security wizard, any web page associated with a bounded ADF task flow will be protected. Therefore before running the application and testing security, developers must first create security policies that grant end users access.
For more information, see Chapter 50, "Implementing Function Security."
In general, the JAAS permission determines the allowed operations that the end user may perform on the application resource. However, from the standpoint of Oracle Fusion Applications, end users typically need to interact with multiple resources to complete the duties designated by their provisioned roles. To simplify the task of creating function security policies, developers work with entitlement grants (defined as OPSS permission sets) to grant privileges for a variety of securable resources, including ADF task flows, web services, and SOA work flows to a role.
Developers use the Oracle JDeveloper to create the entitlements (with one or more resource-action pairs) and then grant one or more entitlements to the desired application roles (the grantee).
For details about creating entitlement-based security policies, see Chapter 50, "Implementing Function Security."
Task flow, page definition, and web service resource permissions are tightly coupled with code artifacts. These permissions are assumed to be associated with concrete code artifacts. In some circumstances, permissions are required, but no code artifacts exist with which the permissions could be associated. For example, suppose the same page is used to view and update tasks. The same code artifact is used for both actions such that one cannot control access to both view and update tasks separately. Resource permissions enable creating abstract permissions which can be referred to with API calls.
For details about resource permissions and using APIs, see the "Understanding Security Concepts" part in the Oracle Fusion Middleware Application Security Guide.
You can use Expression Language to access security context information. Following are some useful expressions:
securityContext.taskflowViewable
securityContext.regionViewable
securityContext.userGrantedPermission
For more information, see the "Enabling ADF Security in a Fusion Web Application" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).
Implementing data security requires the following main steps:
Use Oracle Authorization Policy Manager to create security definitions based on the Oracle Fusion Data Security model. This step is common, regardless of the technology being used.
Refer to these security definitions from the code artifacts. This step varies depending on the technology used, as well as the functional requirements of the application.
For more information about implementing Oracle Fusion Data Security, see Chapter 49, "Implementing Oracle Fusion Data Security."
For more information about using Oracle Authorization Policy Manager, see the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
For information about using APIs and Expression Language to secure data, see Chapter 49, "Implementing Oracle Fusion Data Security."
Oracle Virtual Private Database (VPD) enables creating security policies to control database access at the row and column level. Access is controlled at the database level. VPD adds a dynamic WHERE clause to a SQL statement issued against an object to which an VPD security policy has been applied.
VPD can be useful for enforcing security when a development team must enforce security at the database level. Using VPD affects performance. As such, make sure to evaluate your performance requirements prior to implementing the VPD solution.
For more information regarding VPD implementation, see the "Using Oracle Virtual Private Database to Control Data Access" chapter in the Oracle Database Security Guide.
PII (Personally Identifiable Information) is any information that can be used to uniquely identify a person. This information is considered sensitive and must be protected from misuse for the purposes of legal regulation, financial liability and personal reputation. For example, only authorized users should be allowed access to the social security numbers of people stored in a system. PII authorization is only implemented on data identified by the PII working group in the data privacy Oracle Fusion uptake document.
PII authorization is implemented using one or more of the following technologies:
Encryption and decryption APIs
Oracle Fusion Data Security
Row level Oracle Virtual Private Database
The security requirements for the PII attribute determine the technologies to be used.
Installations of Oracle Fusion Applications may require a large number of roles that must be provisioned. For data security purposes, it is often necessary to create the roles as the data security rules are not known at design time.
For more information regarding data role templates, see the "Data Security" chapter in the Oracle Fusion Applications Security Guide.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
