Cannot retrieve user: Unable to locate current JTA transacti

[kpalania]

I am trying to retrieve a user from the JBoss Portal DB using the APIs provided, and I am running into a JTA Transaction exception ("unable to locate currentJTA transaction"). I've confirmed that the SessionFactory object used in HibernateUserModuleImpl is not null.

UserModule userModule = (UserModule) new InitialContext().lookup("java:portal/UserModule");
User user = userModule.findUserByUserName("admin");

[kpalania]

Error stack:

org.hibernate.HibernateException: Unable to locate current JTA transaction
 at org.hibernate.context.JTASessionContext.currentSession(JTASessionContext.java:61)
 at org.hibernate.impl.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:542)
 at org.jboss.portal.identity.db.HibernateUserModuleImpl.getCurrentSession(HibernateUserModuleImpl.java:291)
 at org.jboss.portal.identity.db.HibernateUserModuleImpl.findUserByUserName(HibernateUserModuleImpl.java:91)

[soshah]

kpalania-

You need to call this in the context of an active Transaction

Thanks

[indyjones]

kpalania,

In your web app, you need a WEB-INF/jboss-portlet.xml.

Inside there try adding this...

<portlet-app>

<portlet>
<portlet-name>NameofYourPortlet</portlet-name>
<transaction>
<trans-attribute>Required</trans-attribute>
</transaction>
</portlet>

<service>
<service-name>UserModule</service-name>
<service-class>org.jboss.portal.identity.UserModule</service-class>
<service-ref>:service=Module,type=User</service-ref>
</service>

</portlet-app>

thanks

indy

[indyjones]

forgot somthing....



<portlet-name>UserManagerPortlet</portlet-name>

<trans-attribute>Required</trans-attribute>

[kpalania]

Thanks folks, but I am not making this call in a portlet. I am trying to authenticate the user WITHOUT using the Out-of-the-box FORM-based authentication and as part of these changes, I've disabled FORM-based authentication, created a new servlet that does the authentication and a redirect based on the user's original request.

So, I need to get a handle to the UserModule (and therefore, the user) outside the scope of a JBoss portlet. How can I accomplish this? Thanks very much for your help.

[kpalania]

ok, i think i found it. i am doing it programmatically using the JBossTransactionManagerLookup.getTransactionManager() API.

While this works, and I am able to explicitly set the "portal.principal" session attribute to a HashMap that contains the Portal User object, I am still not able to get past the main issue which is JBoss Portal not finding the principals though the user has been authenticated.

The only thing to note here is that there are 2 applications here, and the session contexts are different.

[soshah]

kpalania-

UserModule needs to be called within the context of an already active Transaction.

Try something like this:

SessionFactory identitySessionFactory = (SessionFactory)new InitialContext().lookup("java:/portal/IdentitySessionFactory");
Session session = identitySessionFactory.openSession();
Transaction transaction = session.beginTransaction();
boolean success = false;
try
{
 UserModule userModule = (UserModule) new InitialContext().lookup("java:portal/UserModule");
User user = userModule.findUserByUserName("admin");

//other business logic etc etc

success = true;
}
finally
{
 if (transaction != null)
 {
 if (success)
 {
 transaction.commit();
 }
 else
 {
 transaction.rollback();
 }
 }

 if (session != null)
 {
 session.close();
 }
}

This code maynot compile as is, but you get the idea ;)

Thanks

[kpalania]

Thanks Sohil. Yes, this is exactly what I am doing (I also tried using the JBoss TransactionManager class directly, and that worked too). Now, I am able to explicitly set the "portal.principal" session attribute to this user but like I mentioned earlier, it still doesn't help.

The principals are not set by JBoss Portal and therefore, I can't access the portal. Authentication is done using a custom security realm and all of it goes through fine but for some reason, it doesn't find the principals.

If you could suggest a way to set the principals manually after doing the authentication, that would be immensely helpful. Thanks.

- krish

[soshah]

krish-

JBoss Portal relies on JAAS/Tomcat integration for setting up the Portal security Subjects.

So in your case I would recommend using a Tomcat Valve to process your authentication and set up the Subjects the way JAAS does it inside Tomcat.

There is a fair bit of hacking involved here.


btw- why can't you re-use JBoss Portal's JAAS mechanism and just plug in your own LoginModule for your application specific authentication logic?

Thanks

[kpalania]

"So in your case I would recommend using a Tomcat Valve to process your authentication and set up the Subjects the way JAAS does it inside Tomcat. "

Is this my ONLY option? I am not familiar with either how Tomcat valves work, or how subjects are set inside Tomcat, so it might be a little painful to get this done in a day or so :(

"btw- why can't you re-use JBoss Portal's JAAS mechanism and just plug in your own LoginModule for your application specific authentication logic? "

Could you elaborate on this? I've implemented a number of custom login modules that are stacked. I was able to authenticate the users against this security realm SO LONG as I used container managed authentication and j_security_check. Everything worked fine. But, I need to move away from that and explicitly initialize the LoginContext (using the same security realm) due to some other reason and that is where things are not working.

[kpalania]

If there is a simple way to move away from container managed FORM-based authentication for JBoss Portal and invoke the security realm explicitly, keeping everything else the same, that would work perfect for me.

[soshah]

to integrate with the JAAS security realm, your best bet/cleanest solution would be to write your own Tomcat Authenticator (which is actually a form of Tomcat Valve)

Authenticators are actually pretty simple in tomcat and best source of "How To" is the tomcat source code and see how the existing Authenticators like Form, basic, etc are written.

You should be able to write your own looking at that.


On the otherhand, I don't know what your authentication requirements are but most of the times LoginModules are able to create application state just fine. You have access to the HttpServletRequest, HttpServletResponse, and HttpSession inside your LoginModule, so what other objects do you need to populate/setup the proper LoginContext for your application?

Thanks

[indyjones]

Sohil,

You said...

why can't you re-use JBoss Portal's JAAS mechanism and just plug in your own LoginModule for your application specific authentication logic?

I would LOVE to know how to do this...

Is there a wiki reference or somewhere you can point me?

Thanks

Indy

[kpalania]

to integrate with the JAAS security realm, your best bet/cleanest solution would be to write your own Tomcat Authenticator (which is actually a form of Tomcat Valve)

Authenticators are actually pretty simple in tomcat and best source of "How To" is the tomcat source code and see how the existing Authenticators like Form, basic, etc are written.

You should be able to write your own looking at that.


On the otherhand, I don't know what your authentication requirements are but most of the times LoginModules are able to create application state just fine. You have access to the HttpServletRequest, HttpServletResponse, and HttpSession inside your LoginModule, so what other objects do you need to populate/setup the proper LoginContext for your application?

Thanks

Thanks Sohil. Yes, I do have access to the objects I need and this is what I do -

* I have a servlet implemented that uses the LoginContext and invokes my security realm. It passes through the various login modules and authentication succeeds. However, JBoss Portal throws an authorization exception as the principals were never set.
* If I kept everything else the same but just removed the servlet I added and used container managed authentication by using j_security_check, everything works fine and the principals are set.
* The only thing to note here (just in case) is that the JAR file that contains the login module code is added as a shared library in JBoss and is used by multiple applications but I don't suppose this is causing any issues as the other application that uses the same security realm works just fine with the same set of changes. It is only JBoss Portal that complains..