ADF Security

1. OPSS provides a credential store in which sensitive information, such as database

passwords for applications that use a JDBC URL connection or authentication details
for accessing protected Web Services, are stored safely.
2. The credentials are saved and deployed in a file, cwallet.sso.
3. User groups are also referred to as enterprise roles because they are not
application specific.
4. Authentication is delegated to the Java EE container, whereas authorization is
performed with JAAS.
5. ADF Security settings are stored in the application-wide jazn-data.xml file.
6. One benefit of using the jazn-data.xml local policy file during application
development is that it can be source controlled and that it makes it easy for
developers to zip up applications as a test case for other developers or quality testing
(QA) engineers.
7. For testing, and later for production, the application is deployed to the Oracle
WebLogic Server. Upon deployment, the jazn-data.xml file content is copied to the
Oracle WebLogic Server domain system-jazn-data.xml
8. The system-jazn-data.xml file represents the OPSS file-based policy store and
contains JAAS permissions and grants.
9. The two permission classes in ADF Security are PagePermission and
RegionPermission. They do exist in the ADF framework and dont need to be
created by the application developer.
10. BTF's are secured by default if authorization is enabled for ADF Security.
11. The unbounded task flow is not secured.No specific task flow permission is
required to access content of an unbounded task flow.
12. Permissions consist of a permission class- such as RegionPermission, used to protect
an ADF page, a target-which is the name of the resource to protect, and an actionwhich defines what the user is allowed to do with the resource. Actions that are
available for the RegionPermission include view or customize, which is what the
Oracle WebCenter product uses in addition to view.
13. An AuthorizationException is thrown if authorization in ADF Security fails. The
ADF Controller directs such failures to the defined exception handler.
NOTE
To protect JSF pages that are not ADF bound, you can make them ADF bound using
an empty PageDef file.
To create an empty PageDef file, right-click a page and choose Go To Page
Definition from the context menu.
Be aware that, after this, the page is added to the ADF lifecycle, which is a minimal
overhead added to the page runtime.
Both the authenticated and anonymous roles are specific OPSS roles that are not
explicitly defined in the jazn-data.xml file at design time and the system-jazndata.xml file at runtime.

ADF Security Design Time:

1. To enable ADF Security, from Oracle JDeveloper 11g by choosing
Application | Secure submenu provides the following security related options:
(Choose Configure ADF Security to enable application level security)
Configure ADF Security Starts the ADF Security configuration wizard to enable,
configure, and disable ADF Security for an application.
Application Roles Application roles are created in the jazn-data.xml file for the
application. In ADF Security, application roles are used to grant security permissions
to authenticated users through mappings to enterprise user groups after deployment.
Users For testing purpose, ADF Security allows developers to create users in the
jazn-data.xml file.
Groups Security is seldom granted to individual users, but is usually granted to
user groups for easier administration. You can create user groups for testing purposes
in jazn-data.xml.
Configure Security Deployment Defines how deployed security configurations
are treated if existing configurations are detected on the target WebLogic Server. In
addition, test users and groups contained in the application jazn-data.xml file can be
excluded from deployment.

Choosing the Authentication Type

In the second page of the Configure ADF Security Wizard enables you to choose
the type of authentication that the application should use. The choices are:
HTTP Basic Authentication: Browser authentication is used; the user name and
password are not encrypted. This is useful for testing authentication without the
need for a custom login page.
HTTP Digest Authentication: Browser authentication is used; the user name and
password are encrypted, so it is more secure than basic authentication.
HTTPS Client Authentication (Public Key Certificate): This strong authentication
mechanism uses a certificate and transmits over SSL(Secure Sockets Layer).
Form-Based Authentication: The developer can specify a login page and a page to
display when login fails. If you specify a page that uses ADF Faces components,
you must use faces/ in the path, such as faces/login.html. If you select the Generate
Default Pages check box, JDeveloper generates a login page and an error page for
you.
2. When you enable security for the ADF application, some files get updated to make the
security feature work for the application.

web.xml :

The initialization parameter remove.anonymous.role is set to false for the

JpsFilter filter as this filter is the first filter defined in the file.
Filter mapping for adfBindings along with adfAuthentication is added. This is
added for the authentication servlet.
The servlet and the servlet mapping are added for adfAuthentication .
The security constraint is added for the authentication servlet so that when
the framework invokes it, authentication gets triggered.

weblogic.xml :
This file is used as the deployment descriptor for the web application deployed in
the WebLogic server. The security role is assigned in the weblogic.xml file, which
is located in the same folder as that of the web.xml file, using the following code:
<security-role-assignment>
<role-name>valid-users</role-name>
<principal-name>users</principal-name>
</security-role-assignment>

adf-config.xml :
The runtime configurations for the ADF web application are added to this file. The metadata
for the UI page is configured using adf-config.xml. The JaasSecurityContext element is
added. The authorizationEnforce and authenticationRequire options will be set to true for
the property using the following code:
<sec:JaasSecurityContext initialContextFactoryClass="
oracle.adf.share.security.JAASInitialContextFactory"
jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurity Context"
authorizationEnforce="true" authenticationRequire="true"/>
jps-config.xml :(Java Platform Security)
The security service is provided and the service instances are defined in this file.
Oracle Platform Security Services (OPSS) are defined for different security stores.
Credential Store Service Provider , Login Module Service Provider ,
XML-based IdStore Provider , XML-based PolicyStore Provider , and Anonymous
Service Provider are the service providers added to the file.
Different login modules are added. The equivalent file in the WebLogic server is used for
security.

jazn-data.xml :
This file is primarily a policy store. The default security realm (jazn.com) is added to this
file in the same folder. The security realm is determined by the file in the WebLogic server
domain using the following code:
<jazn-realm default="jazn.com">
<realm>
<name>jazn.com</name>
</realm>
</jazn-realm>

Security permissions :
1. Security permissions for an ADF web application are given to
business objects, task-flows, pages, and page fragments.
2. Pages and page fragments are protected through the respective page definition files.
Permission class of protectedjsp-oracle.adf.share.security.authorization.RegionPermission
Permission class of task-flow-oracle.adf.controller.security.TaskFlowPermission

Security for business objects (EO or Attributes) :

Security option is available in the General section for the Entity object.
There are 3 operations for an entity. They are read, update, removeCurrentRow.
These operations are enabled based on the security requirement.
We can apply security for the Entity attribute from the Security section.
Ex: Only the update operation is available as a security option for the attribute Deptno.

Granting Privileges on Entity Objects or Attributes

In Structure window, right-click entity object or attribute and select Edit Authorization.
Select privileges to grant to application roles (you check the appropriate permissions to
grant to each role).

Security for task flows and page :

Security for task Flows, web pages, and page definition files is configured in the
jazn-data. xml file.

Creating a login page :

1. The simplest way of creating a login page is to use the form-based authentication
available as part of the wizard that is used to secure the application and check Generate
Default Pages.
2. Login Page will be named login.html and Error Page is named error.html
3. With HTTP based Authentication selected, the login prompt cannot be asked for
unless you restart the server.
In Form based Authentication, the user is redirected to the login page if the user's
session expires.
4. The web.xml entry will change from BASIC to FORM as shown in the following code:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>
5. And for the user that gets added, the changes will be in the jazn-data.xml file as follows:
<users>
<user>
<name>webuser</name>
<display-name>webuser</display-name>
<credentials>{903}hUdKmD5fW+iPvOj6ssYILvxD/eZNB5Tf
</credentials>
</user>
</users>

Application Authentication at Run Time

Application authentication can be one of two types:
1. Implicit: The adfBindings servlet filter checks to see if page is viewable based on JAAS
permission that you have assigned for the anonymous-role, which can access any page
on which no web.xml security constraint is defined for the anonymous-role, and the view
privilege has been granted.

2. Explicit: A login link is directed to the adfAuthentication servlet, which is secured

through a Java EE security constraint. In an explicit authentication scenario, a public page
has a login link, which when clicked, triggers an authentication challenge to log in the
user. The login link may optionally specify some other target page that should be
displayed (assuming the authenticated user has access) after the successful authentication.
On the first access to a page, if there is no Subject defined, then one is created containing
the anonymous user principal and the anonymous-role role principal. With this role
principal, the user can access anypage on which no web.xml security constraint is defined
for the anonymous-role principal and for which the view privilege has been granted.
At runtime, the following security sequence is performed for ADF Security protected
applications:
Implicit authentication (security sequence) :
1. A user requests an ADF bound ADF Faces page or bounded task flow.
2. The ADF Security layer in ADF checks whether security is enabled for the ADF
application configuration.
3. If security is enabled, the security layer checks whether security is enabled for
authentication only or for authorization, too.
4. If authorization is enforced, ADF Security checks whether an anonymous principal
exists and if the permissions granted to anonymous users are sufficient to run the
page or task flow. This usually is the case for public pages. However, it is important
to note that page and task flow permissions must be explicitly granted to the
anonymous role to make them publicly accessible.
Explicit authentication (security sequence) :
1. If page access is not possible with the privileges of the anonymous user account,
the framework triggers authentication by redirecting the request to the protected
ADF authentication servlet.
2. The servlet delegates the authentication request to the Java EE container.
3. Using Oracle WebLogic Server, the container responds to the request with a login
form or by sending a response header that makes the browser display its login form.
4. The user-provided credentials are checked against the identity stores that are
configured for the WebLogic Server domain. If authentication is successful, the
server redirects the request to the authentication servlet. The session now is
authenticated and the user Subject contains the user and enterprise group principals.
5. If ADF Security is configured to use a single application entry point for
authenticated users, the authentication servlet directs the request to this page. If not,
it directs the user to the originally requested page.
6. ADF Security now checks whether the user Subject has permission to run the
requested resource. For this, it performs permission checks for the page or task flow
in the context of the authenticated user.
NOTE :
1. The WebLogic security role assignment has nothing in common with
applicationroles defined in the jazn-data.xml. Roles in the weblogic.xml file are
Java EE roles defined in the web.xml file that are mapped to user groups or users in
WebLogic Server.
2. By default, the anonymous-role built-in role is a member of the test-all role, so any
resources granted to test-all do not require a login.