From what I've seen of the WebSphere related traffic so far it has all related to authentication problems. I only have a small amount of experience with WebSphere, and none of it was dealing with security setup, so I can only give you general info here.

Slide doesn't handle any authentication itself. All authentication is handled by the application server. The application is responsible for verifying the identity of a user and assigning that user to the appropriate roles. The Slide webapp then tells the application server which roles it requires a user to have in order to access the webapp. This is done in the web.xml file. By default Slide is configured to require one of "root", "user" or "guest". Note that these roles are in NO WAY associated with the /roles/root, /roles/user and /roles/guest nodes in Slide. Those nodes are used internally by Slide for authorization, so don't be confused.

The problem is most likely that WebSphere doesn't have the roles that the Slide webapp is looking for. If you've already got roles defined for another webapp you can modify Slide's web.xml to require those roles to access Slide, or you can configure WebSphere so that it has the roles Slide is looking for.

Configuring WebSphere is going to be a murky area in these instructions ;). Slide provides a Realm implementation for Tomcat that lets Tomcat determine username:password pairs and role membership using the /users/* and /roles/* nodes (I know I said the two aren't related, and they aren't, but this Realm creates an exception and connects the two). The Slide/Tomcat bundles are configured to use the Realm. It may be possible to use the Realm for WebSphere, but I kinda doubt it.

Slide also provides a JAAS module. I've never used it, and I've never worked with JAAS, but the module does the same thing the Tomcat Realm does (exposes the /users/* and /roles/* nodes to the application server to use for authentication). You may have luck with this. There are Tomcat specific instructions for using the module on the Slide website. You'll have to interpret them for working with WebSphere.

The other option is to manually create roles in WebSphere and handle user/role membership externally somehow. In Tomcat this can be done using a tomcat-users.xml file, or through LDAP or several other Realm implementations. WebSphere will have something similar. If you go this route I'd recommend just creating a single role that all users with access to the system will have (rather then seperate root, user, guest roles) then do finer grained permissioning inside of Slide.

Hope this helps.

-James

Mihir Solanki wrote:
Hi all,



This question is already pointed out two three times that whether it is possible

to deploy slide binary version 2.0 on WAS 5.0 version successfully or not?



I have installed the slide.war file in the WAS version 5.0 and I can connect through

network place also. (i.e. http://localhost:9080/slide). But when I try to open any of the

directory (say “users” or “files”) it is not opening properly. Even if I try to put any file

or try to create a folder it is giving “Forbidden” error.



One thing that I have noticed is when I have deployed the slide.war file in WAS 5.0

and opened web.xml file WAS is showing errors on the WebDAV methods (i.e. PUT, PROPFIND etc..)



So anybody please help us (who all are need to do this) to port the slide.war file successfully

on WAS 5.0 version.



Also I would like to have an authentication ON (not slide authentication but basic HTTP authentication)

So please provide some help on this…



Regards,

Mihir

*Sr. Software Engineer*

*SBU: eBiz, Gandhinagar*

* *

/"Imaginations... its limits are only those of the mind itself"/




------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to