[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12314533 ]
Michael Lipp commented on JS2-297: ---------------------------------- Find attached a patch (patch.txt) and some files (files.tar.gz) (I'll use the attach multiple files and better names next time). files.tar.gz contains the improved implementation of the JBoss security service with its own LoginModule (that accesses the service). I have removed all configuration files that have turned out to remain duplicates of existing files after cleaning up the configuration (that's why I have provided the files and not a patch, patches don't remove files). Please make sure that the no longer needed files are really removed when checking in. patch.txt updates the .classpath for eclipse. > 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 > Assignee: David Sean Taylor > Attachments: files.tar.gz, jetspeed-secsvcs.tar.gz, patch.txt > > 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]
