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 "Michael Lipp (JIRA)" <je...@portals.apache.org> on 2005/06/14 14:33:52 UTC
[jira] Created: (JS2-297) Design flaw in JBoss/JAAS security provisioning
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
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
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Resolved: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "David Le Strat (JIRA)" <je...@portals.apache.org>.
[ 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12314289 ]
David Sean Taylor commented on JS2-297:
---------------------------------------
applied patch, please review, thanks
> 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12314298 ]
Michael Lipp commented on JS2-297:
----------------------------------
(1) WAS files (tools and libraries) will be needed at compile time, so there is no need to include anything in the project. Compilation will, however, only be possible if WAS is installed somewhere and the location has been made known to maven.
(2) The new structure looks good. I'll test it and will port my changes (setting data source as MBean property, improved JBossLoginModule coming soon) to it.
(3) I totally agree about avoiding duplications of files. The point here is that I hadn't finished yet (I still have to understand some things). I don't think that a security MBean needs all the security components that are configured for the portal (e.g. there is no need to have the group manager available). So my idea was to get things running by copying the files and then stripping them down to what is really required.
> 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12314139 ]
Michael Lipp commented on JS2-297:
----------------------------------
Another question: what package name should I use for the module? The proposed directory structure is OK but unsuitable as package name due to the dashes.
> 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
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12314287 ]
David Sean Taylor commented on JS2-297:
---------------------------------------
Suggested package name:
org.apache.jetspeed.appservers.jboss
or
org.apache.jetspeed.appservers.security.jboss
Each project will need a typical maven src/java directory structure
Regarding Weblogic modules, do we have to import modules?
If yes, then its not possible by license.
Im going to be investigating WAS integration tomorrow...
> 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
[jira] Reopened: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=all ]
Ate Douma reopened JS2-297:
---------------------------
As Michael reports: its not working yet :(
> 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12314533 ]
Michael Lipp commented on JS2-297:
----------------------------------
Find attached a patch (patch.txt) and some files (files.tar.gz) (I'll use the attach multiple files and better names next time).
files.tar.gz contains the improved implementation of the JBoss security service with its own LoginModule (that accesses the service). I have removed all configuration files that have turned out to remain duplicates of existing files after cleaning up the configuration (that's why I have provided the files and not a patch, patches don't remove files). Please make sure that the no longer needed files are really removed when checking in.
patch.txt updates the .classpath for eclipse.
> 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, 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12314297 ]
David Sean Taylor commented on JS2-297:
---------------------------------------
Michael,
Is there a reason for duplicating the Spring security files under META-INF/jboss-secsvc ?
Im -1 on having 2 copies of any file in the CVS ... could these be copied over from the /portals subproject as a part of the 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Updated: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=all ]
Michael Lipp updated JS2-297:
-----------------------------
Attachment: jetspeed-secsvcs.tar.gz
> 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
[jira] Updated: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=all ]
Michael Lipp updated JS2-297:
-----------------------------
Attachment: files.tar.gz
> 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, 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "David Le Strat (JIRA)" <je...@portals.apache.org>.
[ 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Updated: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=all ]
Michael Lipp updated JS2-297:
-----------------------------
Attachment: jboss-security-service-20050630.tar.gz
Files to remove in svn:
app-servers/security/jboss/src/java/META-INF/jboss-secsvc/security-atz.xml
app-servers/security/jboss/src/java/META-INF/jboss-secsvc/security-managers.xml
app-servers/security/jboss/src/java/META-INF/jboss-secsvc/security-spi-atn.xml
app-servers/security/jboss/src/java/META-INF/jboss-secsvc/security-spi-atz.xml
app-servers/security/jboss/etc/repository_database.xml
> 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12314776 ]
Michael Lipp commented on JS2-297:
----------------------------------
Here is another update to the JBoss security service. The JdbcConnectionDescriptor for OJB is now completely initialized from data obtained from the data source, so the service should automatically adapt to different RDBMs.
Attached files:
Subtree to replace: jboss-security-service-20050630.tar.gz (file comment has list of deletes)
patch.txt (see previous comment, still to be applied)
> 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12318631 ]
Michael Lipp commented on JS2-297:
----------------------------------
I do not have the priviledges to re-open. However, it does currently not work! I have the patches to get it working again, but they depend on JS2-326 and so I'll send them when issue JS2-326 has been solved.
> 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Updated: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=all ]
Michael Lipp updated JS2-297:
-----------------------------
Attachment: patch.txt
> 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, 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12313600 ]
Michael Lipp commented on JS2-297:
----------------------------------
Thanks for the positive feed-back. I'll adapt my directory structure and improve the ".../jboss/" part.
One hint regarding the integration into the maven build system. In order to bundle the dependent libraries, I have introduced a property <sar.bundle>. As the libraries included with "&dep...; " obviously do not have this set, I have repeated the dependencies. You'll have to decide if you move <sar.bundle> to the etc/project-dependencies/*.xml.
The WebLogic module will pose a specific challenge: In order to generate and compile the MBeans for Weblogic, you need a WebLogic installation. How should such an installation be referenced from within the maven build system? And how can building the MBeans be made dependend on the availability of the installation?
(To a minor degree this applies to the JBoss MBean, too. It would be nice if the security service MBean could extend the JBoss Service interface, but this introduces a dependency on JBoss libraries (at compile time; if you use the SAR, it is reasonable to assume that the JBoss libraries are available ;-)).
> 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
[jira] Resolved: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "David Le Strat (JIRA)" <je...@portals.apache.org>.
[ 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:
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
[jira] Updated: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Michael Lipp (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=all ]
Michael Lipp updated JS2-297:
-----------------------------
Attachment: j2-jboss-security-service-20050826-patch.txt
This patch makes things work again. Please keep the files in jboss-secsvc/*! The component assembly for this JMX module *is* different from the default assembly for the web module (and flexible assembly configurations is what Spring is all about, isn't it).
> 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:
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
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "David Le Strat (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12322695 ]
David Le Strat commented on JS2-297:
------------------------------------
Applying patch from Michael. Hopefully, this will close this issue.
> 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:
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
[jira] Assigned: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=all ]
David Sean Taylor reassigned JS2-297:
-------------------------------------
Assign To: David Sean Taylor
> 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ 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
[jira] Commented: (JS2-297) Design flaw in JBoss/JAAS security provisioning
Posted by "Scott T Weaver (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-297?page=comments#action_12313597 ]
Scott T Weaver commented on JS2-297:
------------------------------------
+1
> 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