[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12317010 ]
David Le Strat commented on JS2-297: ------------------------------------ I made slight changes to maven.xml based on fixes made to address JS2-281. security-providers.xml, security-spi.xml, transaction.xml are copied from portal-webapp assembly to avoid duplicate configuration. Removing security_repository.xml from the jetspeed-security*.jar when building the sar is not required anymore. I also applied fixes addressing JS2-281 for the security component. http://issues.apache.org/jira/browse/JS2-281 Changes for JS2-281 have only been applied to security component for now. I will apply similar changes to other components. Basically, /META-INF/security_repository.xml has been moved to /META-INF/ojb/security_repository. Also, /META-INF/security.xml has been removed. Tests now use the *.xml from portal-webapp assembly whenever possible. Other *.xml for test should be in the test directory. I will apply similar changes to other components as well. Please validate that this is working for you. > 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, jboss-security-service-20050630.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]
