[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12313600 ]
Michael Lipp commented on JS2-297: ---------------------------------- Thanks for the positive feed-back. I'll adapt my directory structure and improve the ".../jboss/" part. One hint regarding the integration into the maven build system. In order to bundle the dependent libraries, I have introduced a property <sar.bundle>. As the libraries included with "&dep...; " obviously do not have this set, I have repeated the dependencies. You'll have to decide if you move <sar.bundle> to the etc/project-dependencies/*.xml. The WebLogic module will pose a specific challenge: In order to generate and compile the MBeans for Weblogic, you need a WebLogic installation. How should such an installation be referenced from within the maven build system? And how can building the MBeans be made dependend on the availability of the installation? (To a minor degree this applies to the JBoss MBean, too. It would be nice if the security service MBean could extend the JBoss Service interface, but this introduces a dependency on JBoss libraries (at compile time; if you use the SAR, it is reasonable to assume that the JBoss libraries are available ;-)). > Design flaw in JBoss/JAAS security provisioning > ----------------------------------------------- > > Key: JS2-297 > URL: http://issues.apache.org/jira/browse/JS2-297 > Project: Jetspeed 2 > Type: Bug > Components: Security > Versions: 2.0-M3 > Environment: JBoss > Reporter: Michael Lipp > Attachments: jetspeed-secsvcs.tar.gz > > There is a design flaw in the JBoss security provisioning. The login module > JBossLoginModule can only be found if authentication is requested by the > Jetspeed portal web application, as it is in the web application's classpath > only. If you want to authenticate the access to an EJB from a stand-alone > client or to a web service (usually supplied by a different web application), > the JBossLoginModule cannot be found by the JBoss application server. > This is a pity, because it restricts the usability of the (otherwise nice) > user/group/role management facility that comes with Jetspeed. The problem > will become even more apparent when you try to use Jetspeed2 security > provisioning in other application servers such as WebLogic. There, security > providers must be packaged and deployed independently of any application as > special MBeans that "extend the server". > The solution to this problem is in supplying a JBoss JAAS login module that > is fully functional without (i.e. independant of) the Jetspeed2 portal. This > may in general be done by adding all required files to the JBoss installation > in server/*/lib or by deploying an appropriate service archive (SAR). I > prefer the second approach as it does not clutter up your installation. Note > that although the libraries to not end up as files in your JBoss > installation, they will still be added to the application server's classpath > if you deploy the SAR directly (by putting it in the JBoss deploy/ > directory). This may introduce some problems because the SAR contains quite > some "common" libraries that should usually not be provided by the AS. The > SAR should therefore better be bundled in the EAR that wants to use Jetspeed > security management (and that may, but need not contain a Jetspeed portal). > Attached to this issue you find the files required to produce such a SAR as > subtree to jakarta-jetspeed-2.0-M3/. It is not fully integrated in the build > as I wanted to keep it an add-on until I know if this approach is accepted by > the Jetspeed2 team. Run maven in secsvcs/jboss (secsvcs/weblogic is still to > come ;-)), this produces the service archive. > The main component of the service archive is jetspeed-security-*.jar. It is > repacked, i.e. security.xml is removed and security-repository.xml is moved > to the SAR's META-INF/, see JS2-281. All libraries that > jetspeed-security-*.jar depends on are added. A spring configuration is > created in META-INF/jboss-secsvc/. And we have to use our own > repository_database.xml because a SAR has no ENC and thus we cannot map > java:comp/env/jdbc/jetspeed to the global JNDI entry, rather we have to use > the global JNDI entry of the data source directly. > As I do not have a complete knowledge of Jetspeed2's modules (it's getting > better), I have found the components needed by jetspeed-security.*.jar by > trial and error. Most things seem quite logical, only the jetspeed-cm > component should IMHO not contain the factorybeans. > In its current state, the security service module just get things running. > I'm prepared to add some features such as making some properties configurable > in the jboss-service.xml (i.e. the MBean configuration) if this solution is > accepted in general by the Jetspeed2 team. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
