Wrong security Principal in ADF BC deployed as EJB SessionBean

Question

Hi everybody,
We have an ADF Web application using ADF Faces and ADF BC. Due to security reasons we need to execute the ADF Faces layer and the ADF BC layer at separate machines (in separate security zones), so we tried to deploy and access ADF BC as EJB Session Beans (i.e. to use "remote" Business Components). We used the necessary JDeveloper wizards to make it, we did have problems to achieve it on JDev 11.1.1.2 and JDev 11.1.1.3 (due to runtime java.lang.ClassCastException: oracle.adf.model.servlet.HttpSessionContextImpl cannot be cast to oracle.jbo.SessionContext, which probably is a bug), but eventually we succeded on JDev 11.1.1.4.
Unfortuanetly we encountered a problem - in the remote ApplicationModuleImpl (at "ADF BC" tier, where the EJBs were deployed) <tt>ADFContext.getCurrent().getSecurityContext().getUserName()</tt> does not return the username of the currently authenticated user (e.g. the session user in the presentation tier), but it returns the username of the user who has been current when this particular AM instance has been created (e.g. next time when this AM instance is reused by another user the method does not return his username but the username of the AM instance's creator). Note, that our EJBs are configured by default with <tt><use-caller-identity/></tt> and we have established Global Trust between the WLS domains, so the current authenticated Subject from the client tier should be propagated to the remote EJB (in order to execute the EJB in the security context of the client application).
We rely on the username in ApplicationModuleImpl.prepareSession() to setup a security context in the database session, so it is crucial for us to get the correct username. The method <tt>ApplicationModuleImpl.getUserPrincipalName()</tt> returns the proper username, but not always, because of a well-known bug appearing since JDev 11.1.1.2, so we could not use this method either.
My questions are:
(1) Has anybody encountered such a problem?
(2) What should happen in such a configuration, e.g. how and when the "remote" ADF SecurityContext is (re)loaded in such an environment?
(3) How could we resolve the problem?
Our environment is JDeveloper 11.1.1.4 + WebLogic Server 10.3.4.
Thanks,
Dimitar
Edited by: Dimitar Dimitrov on Feb 4, 2011 6:53 PM

Answer 1

Hi codeplay,
The forum has excluded this thread from my watch list when I have marked the thread as answered and I have missed your questions, so I appologize to you. Now I am answering your questions despite it may be too late for you.
Q: I am very interested to know that besides this wrong security principal issue, what else problems do you encounter for BC-as-EJB deployment?1) The EAR file that is generated for the remote ADF BC (i.e. for the ADF BC deployment at the remote server) puts the EJB JARs in <tt>lib</tt> folder within the generated EAR instead of <tt>APP-INF/lib</tt> (which is part of the CLASSPATH in WebLogic by default). As a result we were receiving ClassNotFound exceptions. The problem is solved by specifying <tt>APP-INF/lib</tt> as a target for the "Application Libraries" file group in the corresponding EAR deployment descriptor;
2) We were receiving "Exhausted ResultSet" or "ResultSet is already closed" exceptions (I cannot remember well which ones, please excuse me, it was some time ago). We solved this problem by setting <tt>jbo.ejb.txntype=global</tt> in AM's configuration (i.e. we instructed the framework to use global (e.g. JTA) transactions instead of local ones). However, this setting caused another problem - after COMMIT/ROLLBACK the framework did not start a new global transaction immediately. We solved this problem by implementing <tt>afterCommit()</tt> and <tt>afterRollback()</tt> methods to our ApplicationModuleImpl class where we started a new JTA transaction explicitly.
Q: For EO attributes that are configured as "Track Change History" (created/updated by), will the correct values be stored? Assume we couldn't get correct user name from remote BC, what else features do we lose? (eg, protect EO attributes using ADF security?)As far as I know history attributes rely on the method <tt>ApplicationModule.getUserPrincipalName()</tt>. This method is considered as a deprecated, but in fact the history attributes rely on it instead of the <tt>ADFContext.getCurrent().getSecurityContext().getUserPrincipal().getName()</tt>. The method getUserPrincipalName() returns a wrong result only during the 1st chekout after AM's establishment in the AM pool. Then it works correctly even if recycling the AM instance in another user session. In fact this method was the most reliable "username" source (but not reliable during the initial checkout).
Q: My understanding is that you will go for this kind of deployment in your project regardless of all known issues, is it?A: No, we abandoned this kind of deployment because of all these problems and because we realized that Oracle's support for this feature is very poor and Oracle did not confirm commitment to this feature in the future.
Lastly, did you ever try to reproduce this issue in jdev 11.1.2?A: No, we have not tried JDev 11.1.2 because it was not existing at the time when were doing our trial and because our application was going to be a WebCenter application. JDev 11.1.2 does not have WebCenter extension yet.
Dimitar