slide 2.1 security websphere 6.0.2.11
Problem:
Slide 2.1 does not work "out-of-the-box" with WebSphere 6. It seems most slide-users have worked around it by turning off security. Clearly, this is not an option for a production system - so we need to get it working.
Solution:
This is a elaboration on my post #12099 to the slide-user list. Thanks to the post on the list from Lynn Richards #10690. A committer is welcome to add any content from here to the Slide-Wiki on WebSphere Setup. It certainly needs more detail. You will need:
- slide-server-2.1 source code - in order to make corrections and re-build.
- IBM HTTP Server (IHS) and the Web Server Plugin
Slide Source Changes - UTF-8
There are a two places (that I could find) in the code where the content type is set to"text/xml; charset=\"UTF-8\"". The WebSphere servlet container can't handle the quotes around the encoding. This needs to be changed to "text/xml; charset=UTF-8". This works for Tomcat too, so perhaps it should be committed in the server source?- jakarta-slide-server-src-2.1\src\webdav\server\org\apache\slide\webdav\method\AbstractWebdavMethod.java
128c128 < public static final String TEXT_XML_UTF_8 = "text/xml; charset=\"UTF-8\""; --- > public static final String TEXT_XML_UTF_8 = "text/xml; charset=UTF-8";
- jakarta-slide-server-src-2.1\src\webdav\server\org\apache\slide\webdav\util\DirectoryIndexGenerator.java
145c145 < res.setContentType("text/html; charset=\"UTF-8\""); --- > res.setContentType("text/html; charset=UTF-8");
Slide Configuration
"/" Path "Forbidden"
The issue where all paths appear to be "/" no matter what path is accessed on Slide is due to the following code in jakarta-slide-server-src-2.1-\src\webdav\server\org\apache\slide\webdav\util\WebdavUtils.java and a difference in implementation between WebSphere and Tomcat String result = null;
if (config.isDefaultServlet()) {
result = req.getServletPath();
} else {
result = req.getPathInfo();
}
req.getServletPath() seems to always be "/" in WebSphere when the WebDAV servlet is mapped to "/". The solution is to force slide to use the getPathInfo() method by turning off the Default Servlet flag in the web.xml:<param-name>default-servlet</param-name> <param-value>false</param-value>
The EAR file might be corrupt? web.xml validation
When you install a war file on WebSphere the web.xml is parsed and validated against the spec. Any discrepancies with the spec will give you the un-helpful error that the "EAR file might be corrupt". Add the detail below to you opening node in the web.xml and make sure it is valid according to the schema (using an editor such as XML Spy) before including it in the war file:<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"; xsi="http://www.w3.org/2001/XMLSchema-instance" schemalocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">You'll find that all the <description> nodes are in the wrong place within the <init-param> nodes - they should be the first child rather than the last.
More importantly is the security-constraint section. To get authentication, you must define the constraint for all the possible http (WebDAV) methods. The problem is according to the web.xml spec, the only valid http-method values are: HEAD, GET, POST, PUT, DELETE, OPTIONS and TRACE. To have the other WebDAV methods secure as well, leave the specific http-method constraints out. This node is optional and if you don't specify any, all Http methods will be secure and this will include the WebDAV extensions too.
<!-- Uncomment this to get authentication -->
<security-constraint>
<web-resource-collection>
<web-resource-name>DAV resource</web-resource-name>
<url-pattern>/*</url-pattern>
<!-- comment out the explicit http-method list
'valid' Http Methods
<http-method>GET</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
Http Extensions
<http-method>COPY</http-method>
<http-method>LOCK</http-method>
<http-method>MKCOL</http-method>
<http-method>MOVE</http-method>
<http-method>PROPFIND</http-method>
<http-method>PROPPATCH</http-method>
<http-method>UNLOCK</http-method>
<http-method>VERSION-CONTROL</http-method>
<http-method>REPORT</http-method>
<http-method>CHECKIN</http-method>
<http-method>CHECKOUT</http-method>
<http-method>UNCHECKOUT</http-method>
<http-method>MKWORKSPACE</http-method>
<http-method>UPDATE</http-method>
<http-method>LABEL</http-method>
<http-method>MERGE</http-method>
<http-method>BASELINE-CONTROL</http-method>
<http-method>MKACTIVITY</http-method>
<http-method>ACL</http-method>
<http-method>SEARCH</http-method>
<http-method>BIND</http-method>
<http-method>UNBIND</http-method>
<http-method>REBIND</http-method>
<http-method>SUBSCRIBE</http-method>
<http-method>UNSUBSCRIBE</http-method>
<http-method>POLL</http-method>
<http-method>NOTIFY</http-method>
-->
</web-resource-collection>
<auth-constraint>
<role-name>SlideAdmin</role-name>
<role-name>User</role-name>
</auth-constraint>
</security-constraint>
WebSphere Configuration
Global Security
How to configure WebSphere with a Custom or LDAP realm is beyond the scope of this post (maybe later) but with Security turned on, you will need to either Turn off "Java 2 Security" or define a policy file for the slide web-app.With Java 2 security on, slide will get AccessControlException(s) when it tries to check for the existence of things like its properties file (from the "java.home" location? See Configuration.java - it will catch the exception if the load fails but not if the file.exists() check is forbidden).
WebServer Integration
It appears that when the WebSphere AppServer handles HTTP requests it assumes the same default as the IBM WebServer, namely - content is only to be expected and read for POST and PUT requests. This page on IBM's support site is old but seems to apply for v6 as well: SoftwareGroup Ref #1145705.
To get the WebDAV extensions to HTTP working you need to configure the IBM WebServer with the AppServer using IBM's WebServer Plugin. It's in the Plugin where you're then able to allow content in all HTTP/WebDAV requests. Ie "true" for
AcceptAllContent
Specifies whether or not users can include content in POST, PUT, GET, and HEAD requests when a Content-Length or Transfer-encoding header is contained in the request header. You can specify one of the following values for this attribute:
- true if content is to be expected and read for all requests
- false if content only is only to be expected and read for POST and PUT requests.
If you have version 6, with the WebServer and AppServer on the same machine and the Server setup to propagate changes to the plugin-cfg.xml file, you can set this flag in the Admin Console:
- Web servers > webserver1 > Plug-in properties > Request and response
Check the box for - Accept content for all requests
Aside: If you try a URL like: http://localhost/snoop/hello/world/ok you will see the difference between the ServletPath and PathInfo in WebSphere and why we need to force slide to use the later.
You could actually use a WebServer other than IBM's. The difference will be that you may need to manually configure the Plugin in the AppServer and WebServer and then when the Admin console updates the plugin-cfg.xml file you may need to copy this to the place where the WebServer expects.
Installing Slide
After you install/deploy the slide.war (I gave it the enterprise application name of "slide") you need to edit the Class Loading properties.Class loader mode = Parent Last
WAR class loader policy = Application
This avoids the problem of WebSphere v6 including an older version of JDOM (1.0Beta7) in its lib folder as well as property file loading issues. Check that slide has been correctly associated with the WebServer Plugin:
- Enterprise Applications > slide > Map modules to servers
You should see something like:
Server
WebSphere:cell=wasNode01Cell,node=webserver1_node,server=webserver1
WebSphere:cell=wasNode01Cell,node=wasNode01,server=server1
After starting the slide application it should be accessible via the WebServer (port 80 by default). All access will have to be via the WebServer and this should hopefully work without error and will be secure.
No comments:
Post a Comment