Oliver,
It did technically work fine in the Engine element for slide, no problem at all. Sorry if I misunderstood.
Tim
Oliver Zeigermann wrote:
Maybe you got me wrong. Of course the behavior you describe and want is the generally desired one. I was just asking why it did not work *technically* to have the slide realm in the engine section. It has the namespace attribute in it which used to work before. Anyway, I will try the setting you proposed...
Oliver
On Wed, 03 Nov 2004 21:35:38 -0500, Tim Frank <[EMAIL PROTECTED]> wrote:
Oliver,
It did "work" in the Engine element, however, that would require me to set up all the Tomcat admin/manager accounts as accounts within slide. Not exactly the default behaviour I was expecting. Also, the Tomcat docs indicate that adding entries to the tomcat-users.xml file will allow access to the admin/manager apps. This was no the case in the bundle.
Putting the JAAS Realm inside the Context element inside the Host element allows slide to operate independently of other applications that require authentication. My assumption was this would be the default case as I would assume slide would not be the only webapp running on a server.
I guess it is just my opinion that separating the Tomcat users from the slide users would be desired. If not, then putting it in the Engine element as it stands is fine, but if so, why not remove the other Realm entries in the Engine element (or comment them out since they don't work).
Tim
Oliver Zeigermann wrote:
Hi Tim, any idea why this did not work for you in the engine element?
Oliver
On Wed, 03 Nov 2004 16:11:14 -0500, Tim Frank <[EMAIL PROTECTED]> wrote:
It was my inexperience with Tomcat that caused the problem... and due to that a misunderstanding of the instructions on the following page:
http://jakarta.apache.org/slide/howto-jaas.html
ALSO, and more importantly, the server.xml bundled with the 2.1b2 binary including Tomcat 5 has the JAAS Realm set in the Engine element. This causes the Tomcat admin/manager apps to not work per the default setup instructions for Tomcat.
I have modified my server.xml to place this block inside of the Host element defining localhost instead and then (finally) everything works!
<Context path="/slide" debug="0" privileged="true" useNaming="true"> <Realm className="org.apache.catalina.realm.JAASRealm" appName="slide_login" userClassNames="org.apache.slide.jaas.spi.SlidePrincipal" roleClassNames="org.apache.slide.jaas.spi.SlideRole" name="Slide DAV Server" namespace="slide" useContextClassLoader="false" /> </Context>
Thanks to Nick for pointing out the wiki page which made me realise I did not have this Realm inside of the correct element.
I think it would be helpful to change the default bundle to handle this change as well, and maybe also point it out more explicitly on the JAAS instruction page for newcomers like myself.
Thanks,
Tim
Nick Longinow wrote on 03/11/04 03:07 PM:
Tim
I was able to get this working using Slide 2.1B2. The wiki steps shown are almost completely sufficient (on Windows)
Nick
-----Original Message----- From: Tim Frank [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 3:03 PM To: Slide Users Mailing List Subject: Re: Accessing Tomcat Manager and Admin apps with Slide/Tomcat bundle ?
I would just like to add that I am having the exact same problem with the 2.1b2 bundle that uses JAAS authentication. The only way I can login to the Tomcat admin/manager apps is to change the server.xml file to not use JAAS but the old MemoryRealm. Which of course then doesn't let me login to slide.
I also apologise if this is a Tomcat issue, but it IS an issue with the 2.1b2 bundle you provide for download.
Thanks,
Tim
Nick Longinow wrote on 03/11/04 01:26 PM:
Hi,
Again, apologies for what may be a Tomcat issue, but...
Per Tomcat's documentation, I am trying to set the credentials for the
admin
and manager webapps that ship with Tomcat. I've added them to the tomcat-users.xml file (root/root), but when I try to login to http://localhost:8080/admin I get a stack dump like this:
WARNING: Login exception authenticating username root javax.security.auth.login.LoginException: org.apache.slide.common.DomainInitializationFailedError: Domain initialization error : Domain.xml (The system cannot find the file specified)
Any ideas ?
Nick
-----Original Message----- From: Ryan Rhodes [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 12:58 PM To: [EMAIL PROTECTED] Subject: RE: Custom authorization and authentication best practices
John,
Well, it looks like there are three cases we need to handle and we are
only
handling one of them. Right now the username/password/url are coming from
the connection spec. They can also come from configuration properties.
The case I need is when the credentials come from the JAAS Subject as a: javax.resource.spi.security.PasswordCredential.
I don't think that the JCA specifications are clear on exactly which credentials should be used when they are supplied through more than one method.
I'm using JBoss. I'm pretty sure the PasswordCredential should work the same under weblogic because I was using a lot of weblogic docs for info.
I
think weblogic also supports caller impersonation.
I was really hoping somebody could shed some light on making the url configurable. I'm doing it from a config property right now like you
said.
That means I can only set the url to the slide root. I'm then using WebdavResource.getChildResources() to navigate down, but I feel like that might be doing a whole bunch of extra round trips, when I usually only
want
one resource at a time.
Whats the best way to do this?
Regards,
-Ryan Rhodes
From: "John Gilbert" <[EMAIL PROTECTED]> Reply-To: "Slide Users Mailing List" <[EMAIL PROTECTED]> To: "Slide Users Mailing List" <[EMAIL PROTECTED]> Subject: RE: Custom authorization and authentication best practices Date: Wed, 3 Nov 2004 12:22:20 -0500
Ryan,
What kind of changes are you looking to do for the jca connector? I was thinking of doing the same thing. For example, providing a property for the url and using container managed authentication.
Also, are you using weblogic?
- John
-----Original Message----- From: Ryan Rhodes [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 11:31 AM To: [EMAIL PROTECTED] Subject: RE: Custom authorization and authentication best practices
Hi Morten,
I'm working on something similar to this right now. One way it "Could" be done is this.
1) Use a JAAS Login module to make slide the authentication realm for the web container. This way users and roles are pulled from Slide for web applications.
2) Use the JCA Connector to connect web applications to Slide.
3) Use a second JAAS login config for the JCA Connector. JCA supports 3 or 4 different types of authentication. The type called "Caller Impersonation" allows you to pass on the user/roles from the calling web/ejb application to be used by the JCA connection. This way you don't have to keep around the username/password from the web login to re-use with Slide. The application server handles it for you, and the web user will automatically be limited to whatever document permisions they have in slide.
Right now, the JCA Connector doesn't support any type of declarative configuration. The login/pass are passed programatically through the WebDavConnectionSpec when you create a connection.
When I finish making it configurable I'll submit the changes, but I'll warn you that (#3) will always require configuration that is specific to the application server. Not every app server supports Caller Impersonation, and I think (#1), at least on Jboss, requires a JAAS Login Module that uses propriertary JBoss libraries and I heard those can't be mixed with Apache License, so... it probably won't be support by Slide.
Hope that Helps,
Ryan Rhodes
From: Morten <[EMAIL PROTECTED]> Reply-To: "Slide Users Mailing List" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Custom authorization and authentication best practices Date: Mon, 01 Nov 2004 19:15:34 +0100
Hi.
I will be using Slide as a file system based content repository. It
will be
part of a web-application which contains a UI to add/remove users and
set
permissions at folder level.
This means I need to integrate Slide with my web-app. I see 2 possible methods:
1. Slide accesses an external data-source for authentication and authorization, possibly via a custom plug-in (could be done using WCK,
but
that impacts DeltaV).
2. The users and permissions get set in Slide explicitly using an API (pointers to which greatly appreciated).
Functionally, I need to be able to answer the questions "Is user X with
password Y a valid user?" and "Can user X access folder Z?"
Which of the above is the preferred approach and what is the "proper"
way
to go about it? What's considered best practices? Studying WCK, Realms,
JAAS, Projector gives lots of options on authentication, but I fail to
find
options for authorization.
Br,
Morten
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
---------------------------------------------------------------------
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]
--------------------------------------------------------------------- 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]
