portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Le Strat (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Resolved: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Date Mon, 05 Sep 2005 23:59:31 GMT
     [ http://issues.apache.org/jira/browse/JS2-297?page=all ]
David Le Strat resolved JS2-297:

    Resolution: Fixed

Please validate the patch.

> 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, j2-jboss-security-service-20050826-patch.txt, 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:
For more information on JIRA, see:

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message