[ http://issues.apache.org/jira/browse/JS2-297?page=all ]
David Le Strat resolved JS2-297:
--------------------------------
Fix Version: 2.0-M4
Resolution: Fixed
Please reopen if the patch applied does not work out.
> 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
> Fix For: 2.0-M4
> 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]
