You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "David Sean Taylor (JIRA)" <je...@portals.apache.org> on 2005/06/14 17:05:49 UTC

[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning

    [ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12313592 ] 

David Sean Taylor commented on JS2-297:
---------------------------------------

I reviewed the code. This looks really good. If no one objects, I will create a new directory project where other  app server specific integration code can be stored. Look forward to seeing the Weblogic solution.  In plans for Geronimo, Orion, Websphere :)

I'd like to propose creating a new maven project root:

${JETSPEED-HOME}
    - app-servers
            -security-services
                    - jboss
                    -  weblogic
                     ....


> 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
>  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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org