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]
