ADF security (ODTUG 2006)

Being a major important technology for Oracle, many presentations on this year’s ODTUG conference covered ADF. The showcase, the demonstration of the forthcoming AJAX enabled ADF Faces, has been described in detail by Lucas (AMIS) and Wilfred. But just as worthwhile were the two presentations on ADF security.

The first one was by Peter Koletzky titled "JAZN – implementing the superstition in JDeveloper". He started off with a general introduction to security and mentioned some of the myths that are, unfortunately, stille quite common like "Users always do what you expect them to do" and "Only those who should access your data do access your data". Although, this raised some laughter, we clearly understood the message: pay attention to security and do it well.

Things have been changed since the old Forms days. Now, webapplications are available to a much wider, internet, audience and we therfore cannot rely anymore on the traditional implementation based on database users and roles and privileges. We need an new mechanism to login to an application (authentication) and to organize access to (parts of) the application and data (authorization).
The standard mechanism for Java applications is called JAAS (Java Authentication and Authorization Services). This offers functionality to verify user logins and restric access to resources, based on roles. JAZN provides a JAAS implementation within Oracle’s J2EE container (OC4J). Currently, two options are available: file based (JAZN-XML) and LDAP based (JAZN-LDAP). Since the interface is the same, it is easy to switch from one to another, e.g. when you go from the development environment to a test or production environment, just by changing one line in the oc4j application.xml:
<jazn provider="XML" location="jazn-data.xml" default-realm="jazn.com"/> to <jazn provider="LDAP" location="ldap://ldap.example.com:389">
If necessary, it is possible to implement your own mechanism; e.g. when users and roles are stored in your own database.
All this was demonstrated with a simple ADF Faces application. Peter created a simple two page applications, defined users and roles, defined the authorization method (basic, form-based or others) and added security constraints to certain pages, all in a declaritive mannen.

Later on the day, Duncan Mills presented the follow-up presentation called "Lockdown! – Securing your ADF applications". He started with a startling demonstration of SQL injection on a standard ADF Faces search page (see picture). This clearly demonstrated his point that security is certainly also the developers responsibility. He also elaborated on the fact that jsf does not provide default security functionality as Struts does. However, he showed us the open source initiative jsf-security that extends the JSF EL with a security scope. Note that this is only front-end security (also called security by obscurity) and, although quite usefull, that it is quite easy to override with HTML manipulation. So you’ll need additional authorization, e.g. at ADF binding level. It is also recommended to take good care in organizing the jsf pages to enable role based authorization on url (directory) patterns.
Duncan’s demo continued where Peter Koletzky left. He demonstrated how to implement item-level authorization like a manager is allowed read/edit access to the salary while the employee only has read access. Another aspect he addressed was data auditing. ADF can automagically provide auding information like the current user and the modification time. If this is handled in the database, make sure not to use the pseudo-column USER anymore, since typically webapplications use one user for database access. Instead, use a mechanism that is based on Oracle’s sys-context option.

O, and did I already mentioned that Peter and Duncan are writing a new JDeveloper book.