Ajax - Asynchronous JavaScript and XML - clearly is in the focus of software development. Strongly associated with the new Web 2.0 term, Ajax today is everbody's darling.

Inspired by the promise and the developer uptake of Ajax, I thought on doing a reality check on one of my favorite pets: container managed security, authentication in particular. There are a couple of issues that just don't work well with container managed security

a) Basic Authentication logon dialogs cannot be customized
b) Forms based authentication takes the focus off the current page
c) Forms based authentication hardly works with JavaServer Faces pages because it requires the form to be submitted to j_security_check, something JSf is not capable todo

With Ajax, so my theory, I could request for a protected page, intercept the server side http response and do whatever I want.

For basic authentication, I could try and add the WWW-Authenticate: Basic username:password information to the header (where "username:password" need to be base64 encoded). I would repeat this game for as many attempts the user would need to eventually remember the correct password.

First surprise: You don't have to think so difficult, username and password can be passed to the server as part of the open function of the XmlHttpRequest object

username_var=document.htmlform.usernamefield.value;
password_var= document.htmlform.passwordfield.value;
requestObject = xmlHttpRequestHandler.createXmlHttpRequest();
requestObject.onreadystatechange=onReadyStateChangeResponse;
requestObject.open("POST","protectedpage.html",true);
requestObject.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
requestObject.send(null);

I think that authentication is a good usecase for synchronous Ajax requests because there is no sense in continuing the user work if there isn't a clear decision about who he is and what he is allowed to do.

Note that I used an asynchronous request - despite the fact I think the synchronous call is a better usecase - because this is what Ajax is good for. Using asynchronous requests allows you to add some end-user entertainment like showing a progress bar through the process of authentication. This can be done based on the current XmlHttpRequest state (0,1,2,3,4).

function onReadyStateChangeResponse(){
var ready = requestObject.readyState;
if(ready==0){
//animation 1 here
}else if(ready==1){
//animation 2 here
}
else if(ready==2){
//animation 3 here
}
...

}

Back to my authentication challenge: Basic autentication the Ajax way worked great! At least it did until I entered the wrong password. And there it was again, the browser logon dialog.

My lesson learned from this approach is that it is good to know that the XmlHttpRequest object cannot bypass container managed security. It seems that the browser looks at the returned http error code first before XmlHttpRequest gets to see it. Thus the browser logon dialog pops up instead of giving me a second change to do it my way.

Form based authentication is next. The idea is that I create a logon form that only retruns the JavaScript and form fields needed to send the logon information. I could use a <DIV></DIV> element to show the logon and error form instantly on my JSP page.

I haven't yet implemented this yet and thus cannot say if it is again a waste of my time, but one thing I can see already is that it is a far too complicated approach compared to how easy it is in Web 1.0 (Note that while Web 2.0 exist, there is no Web 1.0. I just don't want to call it the "old days Web" because the old days are too current).

I hope that Ajax isn't moving farther away from container managed security though and that there will be an option in the near future to programmatically handle this type of authentication.

A JAAS callback handler for Ajax also could make sense if it is integrated with the container. In fact, there are some more good requirements to list for good authentication in Ajax. Or, why should everybody deal himself with encryption, decryption and nonrepudation? Maybe wen browsers will become client comntainers similar to what J2EE containers are on the server. Of course, I don' forget that Ajax is not J2EE ;-)

I'll keep on trying and will post a note whenever I am blessed with some success, or a new lesson learned that is worth sharing.

Frank

I have just completed the move of my site to the new dedicated host. Finally! with lots of trips away over the last month it has taken some time to get the new site up and running. I just have....[Read More]

Posted by Pete On 21/04/06 At 09:51 PM

• Install Oracle Database
  Should work with most versions, note that only certain DB versions are "certified" for use with BPEL, meaning they are tested and supported by Oracle.
  
• Install BPEL developer on PC
  This will install Oracle Lite and configure the developer version to use this, we will fix this in a minute.
  Assume that we installed BPEL into $ORACLE_HOME then the $BPEL_HOME referred to in this entry will be $ORACLE_HOME/integration/orabpel
  
• Create a user on the DB with connect and resource priviliges
  Using sqlplus connect to the database as user system or sys and create a user, the actual username and password doesn't matter.  Life will be easier if you start sqlplus from the $BPEL_HOME/system/database/scripts/server directory
  
  sqlplus system/manager@ORCL
  create user bpel101202 identified by bpel101202;
  grant connect, resource to bpel101202;
  
• Install BPEL schema into DB using scripts in $BPEL_HOME/system/database/scripts/server
  Use your sqlplus session to login as the user you created (bpel101202 in our example) and execute the two scripts server_oracle.ddl and domain_oracle.ddl
  
  connect bpel101202/bpel101202
  @server_oracle.ddl
  @domain_oracle.ddl
• Modify $BPEL_HOME/system/appserver/oc4j/j2ee/home/config/data-sources.xml to point at the database instead of OLite.
  Comment out the two Oracle Lite entries in the file
  
  <!-- Use these datasources to connect to Oracle Lite -->
  <!--
  <data-source class="com.evermind.sql.DriverManagerDataSource"
               name="BPELServerDataSource"
               location="jdbc/BPELServerDataSourceWorkflow"
               xa-location="BPELServerDataSource"
               ejb-location="jdbc/BPELServerDataSource"
               connection-driver="oracle.lite.poljdbc.POLJDBCDriver"
               username="system"
               password="any"
               max-connections="30"
               min-connections="10"
               connection-retry-interval="30"
               max-connect-attempts="10"
               url="jdbc:polite4@127.0.0.1:100:orabpel"/>
  <data-source class="com.evermind.sql.DriverManagerDataSource"
               name="BPELSamplesDataSource"
               location="jdbc/BPELSamplesDataSource"
               xa-location="BPELSamplesDataSource"
               ejb-location="jdbc/BPELSamplesDataSource"
               connection-driver="oracle.lite.poljdbc.POLJDBCDriver"
               username="system"
               password="any"
               max-connections="5"
               min-connections="2"
               connection-retry-interval="30"
               max-connect-attempts="10"
               url="jdbc:polite4@127.0.0.1:100:orabpel"/>
  <data-source class="com.evermind.sql.DriverManagerDataSource"
               name="AdminConsoleDateSource"
               location="jdbc/AdminConsoleDateSource"
               xa-location="AdminConsoleDateSource"
               ejb-location="jdbc/AdminConsoleDateSource"
               connection-driver="oracle.lite.poljdbc.POLJDBCDriver"
               username="system"
               password="any"
               max-connections="80"
               min-connections="2"
               connection-retry-interval="30"
               max-connect-attempts="10"
               url="jdbc:polite4@127.0.0.1:100:orabpel"/>
  -->
  
  Uncomment the Oracle 9i entries in the file (also works fine with 10g) and modify the three (3) entries to point to your database.
  
  <!-- Use this datasource to connect to Oracle 9i -->
  <data-source class="com.evermind.sql.DriverManagerDataSource"
           name="BPELServerDataSource"
           location="jdbc/BPELServerDataSourceWorkflow"
           xa-location="BPELServerDataSource"
           ejb-location="jdbc/BPELServerDataSource"
           connection-driver="oracle.jdbc.OracleDriver"
           max-connections="150"
           min-connections="10"
           connection-retry-interval="30"
           max-connect-attempts="10"
           url="jdbc:oracle:thin:orabpel101202/orabpel101202@localhost:1521:ORCL"/>
  
  <data-source class="com.evermind.sql.DriverManagerDataSource"
           name="BPELSamplesDataSource"
           location="jdbc/BPELSamplesDataSource"
           xa-location="BPELSamplesDataSource"
           ejb-location="jdbc/BPELSamplesDataSource"
           connection-driver="oracle.jdbc.OracleDriver"
           max-connections="150"
           min-connections="10"
           connection-retry-interval="30"
           max-connect-attempts="10"
           url="jdbc:oracle:thin:orabpel101202/orabpel101202@localhost:1521:ORCL"/>
  
  <data-source class="com.evermind.sql.DriverManagerDataSource"
               name="AdminConsoleDateSource"
               location="jdbc/AdminConsoleDateSource"
               xa-location="AdminConsoleDateSource"
               ejb-location="jdbc/AdminConsoleDateSource"
               connection-driver="oracle.jdbc.OracleDriver"
               max-connections="80"
               min-connections="2"
           connection-retry-interval="30"
           max-connect-attempts="10"
           url="jdbc:oracle:thin:orabpel101202/orabpel101202@localhost:1521:ORCL"/>

Someone called N1V1Hd $3c41r3 has posted exploit code for the bug in the package function SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_METADATA to the bugtraq mailing list. The post is titled " Oracle 10g 10.2.0.2.0 DBA exploit " and it details how a package function can....[Read More]

Posted by Pete On 20/04/06 At 11:13 PM

Security expert calls for Oracle makeover - by Martin Veitch "A UK security expert has called for change in Oracle’s security strategy, including the removal of the firm’s chief security officer.....[Read More]

Posted by Pete On 20/04/06 At 10:46 PM

• Step 1: your async process needs a unique ID that you can find it back - the easiest way to this, is to use com.collaxa.cube.util.GUIDGenerator:generateGUID() which returns you a really unique id


• Step 2: This id must be stored in the NormalizedMessage as property with name conversationId, or you can use the constant (NormalizedMessage.CONVERSATION_ID)


• Step 3: Initiate your process with the post() api (com.oracle.bpel.client.delivery.IDeliveryService:post())


• Step 4: due to the async delivery mechanism in BPEL (and worker picks up the message from the delivery queue - it might take some seconds 'til you find the instance) -> introduce some wait time


• Step 5: Find the instance through it's conversationId, via lookupInstanceByConversationId on the Locator API, which get's you either an instance of IInstanceHandle, or an ORABPEL-02154 -> instance not found


• Step 6: Check if the instance is closed (completed or faulted) by using IInstanceHandle:getState() and IInstanceHandle.STATE_CLOSED_COMPLETED, or IInstanceHandle.STATE_CLOSED_FAULTED


• Last step is to retrieve the variable defined in you BPEL flow by using getField(String fieldName):java.util.Hashtable(). Why a hashtable? Because you can have multiple parts and each part is an entry here, with the key being the name of the part

• First we need to define some kind of callback interface, I decided to go with 2 methods, that a developer needs to implement
  
  
  
  • public void onResult (Map pResultMessageParts); which is called when the process has finished, and
  
  
  • public String getVariableName (); which is called by our thread to determine the field we need to return to the above content
  
  
  
  An implementation of this callback would be passed later on to the thread, and would be used to signal the callback.
  


• Now it's time to dive into the BPEL interfaces, and get an idea of what information you'd need to query for an instance, and where to get it from
  
  
  
  • To logon to the domain you need a DomainAuth object (which represents a "BPEL" session) - this can be retrieved from the Locator:getDomainAuth()
  
  
  • A conversationId to find your process instance back
  
  
  • and the field name to examine the data, all from the interface described a step above
  
  
  
  


• Next step was to implement a Thread (say be extending java.lang.Thread, that would query the BPEL Server for getting the instance, and later its state)


• All you need to do next is add a constructor, that takes these parameters, and add some logic to the run() method - with a condition when the thread should stop. I chose to break after I triggered the callback's onResult method


• The run() method does the following
  
  
  
  • has an initial sleep, to minimize the chance of an instance not found error
  
  
  • uses the Locator to findthe instance (lookupInstanceByConversationId)
  
  
  • asks the instance for it's state - if completed it (IInstanceHandle:getState())
  
  
  • retrieves the field (IInstanceHandle:getField(String))
  
  
  • and calls the onResult method on the passed callback instance. When this happens it breaks the loop