Oracle JHeadstart Developer's Guide - Downloads - Oracle

10.1.4. Custom Security
10.1.5. ADF Model Security
• The “Jobs.Update” permission determines how the items on the Edit Job page
will be rendered: as read only when the user does not have a role with this
permission, or as updateable when the user does have this permission.
• The “Jobs.Delete” permission determines whether the “Delete Job” button is
rendered.
By hardcoding permission names in application code, the security schema of your
application is fully configurable at runtime, new roles can be added and existing roles
can be deleted or changed by adding or removing permissions, without changes to the
application code. Adding new permissions still requires a new application code release,
but this release was needed anyway to add the new application function that is to be
secured by the new permission.
To use permission-based security with JHeadstart, you check the service-level checkbox
Authorize Using Group Permissions?.
JHeadstart comes with a set of database tables to store the role and permission
information, and an administration application that can be used to maintain this
information. When used in combination with JAAS-based authorization, JHeadstart
performs the authorization check by first looking up all the roles that provide access to a
permission and then make the isUserInRole()API call to check whether the user has
access to such a role.
Instead of using JAAS, you can use the JHeadstart custom security mechanism. This is
implemented in application logic using a servlet filter that redirects to a login page when
an unauthenticated user tries to access a secured application. When the user submits the
login page, custom logic fires to authenticate the user and to retrieve the user’s roles and,
optionally, permissions.
Historically, a common reason for implementing security this way is that the security
information is stored in the same database as the application tables and is accessed using
the Business Service layer of the application.
Note however that by using a JAAS Custom Login Module, the same database tables
could be accessed. The only drawback of using JAAS is the double maintenance of role
information; new roles must be added to the web.xml as well.
ADF allows you to secure the executables (iterator bindings), action and value bindings
defined in the ADF page definitions, part of the ADF Model layer (also known as ADF
Data Bindings layer).
This provides additional security on top of the security defined in the View layer. If, for
example the user is now allowed to create a new employee, the “New Employee” button
is typically hidden in the user interface. Using ADF Model Security, an additional check
can be added on the “CreateEmployee” action binding in the page definition. Should the
user somehow manage to submit an HTTP request to create a new employee, the ADF
Model layer will prevent this and raise an application error as the user does not have the
privilege to execute the “CreateEmployee” action binding.
JHeadstart Developer’s Guide Application Security 10- 5