I am currently working on transitioning a Seam 2.2.0 application that I work on from JBoss 4.2.3.GA to 5.1.0.GA (due to a short turnaround IA issue) and have ran into a problem with my secure SOAP web services. The web services were secured using an LdapLoginModule and requiring a plain-text UsernameToken (was planning on going to a digest with the move to JBoss 5.1.0.GA). This worked well in JBoss 4.2.3.GA, but my soapui test suites that validate that bad passwords are rejected all fail now in JBoss 5.1.0.GA.

Doing some searching my initial path to correct was to change the @SecurityDomain annotation from org.jboss.annotation.security.SecurityDomain to org.jboss.ejb3.annotation.SecurityDomain per the guidance found here: https://community.jboss.org/thread/157593.

After making that switch I recieved an IllegalStateException on startup, which also seems to be a common error in the JBoss 5.1.0 community. The prescribed workarounds for this issue seemed to imply that you must annotate EVERY EJB in your application with the same security domain if you annotate any of them. I attempted this solution annotating every EJB in my application with the security domain, however, JBoss still failed during startup due to the Seam EJB's missing the annotation. At that point I felt that this was an unacheivable solution path with Seam applications (short of overriding every Seam EJB with install precedence and adding the annotation).

Right now what I am "settling on" is creating my own request handler that does LDAP authentication and inserting that in the top of my handler chain for the endpoints that I want to be secure.

Obviously I would prefer if there were a way to not do this in 5.1.0.GA by just using the configuration/pattern that worked so well in 4.2.3.GA.

Has anyone solved this problem in JBoss 5.1.0.GA with a Seam 2.2.X application?

I have come up with a solution that I am happy with as it allows my service tier authentication authorization to take advantage of the identity-store I have defined for seam in components.xml.

By inserting my own request handler in the handler chain, grabbing the username and password out of the soap header, and then looking up the Seam Identity component to perform the authentication I keep a decoupling from authentication method in my workaround (no specific tie to LDAP or DB or JCIFS auth) and only had to change one configuration file (standard-jaxws-endpoint-config.xml to insert my handler in the handler chain). This also prevents me from having to duplicate my LDAP configuration in components.xml and login-config.xml.

I am not sure if this solution will work beyond 5 as I have not worked with jbossws-cxf in 6.1.0.Final yet, but since we are not funded to make the transition to Java EE 6, JPA 2, arquillian for testing yet that will be factored in as a "migration risk" for future migration efforts.

Here is my code if anyone else is interested in doing something like this: