[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12314290 ]
David Sean Taylor commented on JS2-297: --------------------------------------- also, if no one objects, we can make building this a part of the full build... > 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: 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]
