49 Get Started with Security

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. The following figure illustrates the layered architecture that combines these two security frameworks.

Figure 49-2 Oracle Platform Security Services Architecture

The previous figure 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 49-2, other providers include the role mapping and audit providers.

The Security Service Provider Interface (SSPI) layer is accessed through OPSS APIs and provides Java EE container security. It also provides resource-based authorization for the environment, thus allowing customers to choose their security model.

For more information about SSPI, see the Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server guide.

Related Links

The following document provides additional information about Oracle Fusion Middleware topics discussed in this section:

• For more information about OPSS, see the Understanding Security Concepts section in the Oracle Fusion Middleware Securing Applications with Oracle Platform Security Services, in the Oracle Fusion Middleware Online Documentation Library.

Oracle Web Services Manager (Oracle WSM) provides a policy framework to consistently secure Web services.

Oracle Fusion Applications make use of an Oracle WSM feature called global policy attachments (GPA). Using GPA, web service policies are not attached locally, but are specified at a global level. At runtime, components simply inherit the global policy and Oracle WSM enforces it.

Unlike local policy attachments (LPA), which need to be added at every Web service client and server, global policy attachment can be attached at a domain level. This makes it easy for the system administrator to have a uniform policy for all Web services across the domain.

Because certain scenarios exist in which GPA cannot be used, Oracle Fusion application developers may need to use local policy attachment (LPA) for Web services and Web service clients. Application developers may attach policies locally using JDeveloper to the clients and services.

Authentication and authorization are enforced on the services by Oracle WSM based on the policies attached either at the domain level or locally on 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.

Related Links

The following document provides additional information about Oracle Fusion Middleware topics discussed in this section:

• For more information about Oracle WSM, see the Oracle Fusion Middleware Administering Web Services guide.

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 the following figure.

Figure 49-3 Policy Interceptors Acting on Messages Between a Client and Web Service

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.

For details about the policy interceptor that Web services in Oracle Fusion applications use, see Securing Web Services Use Cases .

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 enables declarative, permissions-based security policies that grant users access to ADF bounded task flows and top-level web pages that use ADF bindings.

By default, ADF application resources are protected and thus require the application developer to configure security policies that grant role-based access privileges to enable access by users. A security administrator combines the declarative security policies with the domain-level policy store and configures a domain-level identify store with application users and role memberships.

At runtime, authenticated users are conferred access rights to the ADF resources by a combination of their role membership and the permission grants they inherit from these role memberships.

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 policy definitions on ADF application resources.

Related Links

The following document provides additional information about Oracle Fusion Middleware topics discussed in this section:

• For more information about ADF Security, see the "Enabling ADF Security in a Fusion Web Application" chapter of the Developing Fusion Web Applications with Oracle Application Development Framework, in the Oracle Fusion Middleware Online Documentation Library.

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 Implementing Application User Sessions.

Oracle Fusion Data Security implementation is a solution specifically for Oracle Fusion Applications. The security policy definitions for who can access what data are stored in the Oracle Fusion Data Security repository in the Oracle Fusion Applications schema. Oracle Fusion application developers who create new business objects can customize these definitions using Oracle Authorization Policy Manager, which can be accessed by the developer through the Setup and Maintenance work area of any Oracle Fusion Setup application.

Additionally, Oracle Fusion application developers must opt into the Oracle Fusion Data Security definitions in their application. In the context of an Oracle Fusion application, developers who want to require users to have sufficient data privileges 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 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. VPD controls access to rows and columns by adding a dynamic WHERE clause to a SQL statement issued against a database 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. Use VPD when securing Personally Identifiable Information (PII) on the database level, for example.

Using VPD affects performance. As such, make sure to evaluate your performance requirements before implementing the VPD solution.

Related Links

The following document provides additional information about Oracle Fusion Middleware topics discussed in this section:

• For more information about VPD, see the "Using Oracle Virtual Private Database to Control Data Access" chapter of the Oracle Database Security Guide, in the Oracle Fusion Middleware Online Documentation Library.

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.

Related Links

The following document provides additional information about Oracle Fusion Middleware topics discussed in this section:

• For more information about ODI, see the "Understanding Oracle Data Integrator" part in the Oracle Fusion Middleware Developing Integration Projects with Oracle Data Integrator, in the Oracle Fusion Middleware Online Documentation Library.

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.

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, ODI authentication happens in two phases.

The following figure 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.

Figure 49-4 ODI Authentication

Application Identity

There are several Fusion Web application use cases in which privilege elevation is required. For example, when creating a new employee record, a new Trading Community Architecture (TCA) party record must be created. However, the identity of the user creating the employee has only employee creation privileges. A service must be invoked with temporarily elevated privileges to create the required party and complete the process. To enable privilege elevation, you can switch the identity of the invoker to a common identity with a higher level of access.

Audit Identity

When switching to the application identity, you must propagate the identity to be audited to preserve the submitting identity for auditing purposes.

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. The following example illustrates the syntax of this method.

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 the following example.

ApplSession.setHistoryOverrideUserName()

ApplSession session = ApplSessionUtil.getSession();
if (session != null)    
session.setHistoryOverrideUserName(historyOverrideUserName);

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.

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.

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

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 to access 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 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.

Related Links

The following document provides additional information about Oracle Fusion Middleware topics discussed in this section:

• For details about resource permissions and using APIs, see the "Understanding Security Concepts" part in the Oracle Fusion Middleware Applications Security Guide, in the Oracle Fusion Middleware Online Documentation Library.

You can use Expression Language to access security context information to determine the access rights of the authenticated user. Following are some useful expressions:

• securityContext.taskflowViewable

• securityContext.regionViewable

• securityContext.userGrantedPermission

Related Links

The following document provides additional information about Oracle Fusion Middleware topics discussed in this section:

• For more information about ADF Security-based EL utility methods, see the "Enabling ADF Security in a Fusion Web Application" chapter of the Developing Fusion Web Applications with Oracle Application Development Framework, in the Oracle Fusion Middleware Online Documentation Library.

For information about using APIs and Expression Language to secure data, see Implementing Oracle Fusion Data Security.

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:

• OPSS Keystore APIs for encryption and decryption

• Oracle Fusion Data Security

• Oracle Virtual Private Database for row and column level security

The security requirements for the PII attribute determine the technologies to be used.

Related Links

The following document provides additional information related to Oracle Fusion Applications topics discussed in this section:

• For more information about OPSS encryption/decryption APIs, see the Oracle Fusion Middleware Securing Applications with Oracle Platform Security Services guide, in the Oracle Fusion Middleware Online Documentation Library.

• For more information about using VPD to control data access, see the Oracle Database Security Guide, in the Oracle Database Server Online Documentation Library.

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 product-specific security guides.