:( ... The distinguishing factor in my requests is neither the user credential nor the resource being accessed. The same user should be able to access the Slide Repository either via my WebService or via MS-Word/Excel/etc. I.e. The same user could access the same resource in either mode. When accessed via WebService, my application is doing the authorization. When accessed directly, I would have to override the default slide security implementation with my custom implementation.
I think I would have to try the clustering solution only with my custom security implementation (since the direct slide access should also follow the same security checks as done in my application). But I won't be able to get to it may be for another month. A couple of questions regarding custom security implementation... 1. Is the security implementation class configurable via Domain.xml? There is a security store configuration in Domain.xml but I haven't seen the entry for the security helper class. 2. Which methods would have to be implemented if I am interested only in the authorization checks and not the assignments? Thanks, Ritu -----Original Message----- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Friday, August 27, 2004 11:44 AM To: Slide Users Mailing List Subject: Re: A question on security configuration Done a little more thinking about this. I think separate namespaces sounds like a good idea, but there may be a problem. Since the Store configurations are per-namespace it's likely that the ExtendedStore cache will be per namespace as well. If this is the case then you're back to a situation where you'll need clustering to keep the caches in sync. Unless you really want everything to run in the same webapp you'd probably be better off just running a cluster with two nodes. Stefan's suggestion gave me an idea, though (several actually). What you really need is a way to bypass the security checks in SecurityImpl based on some aspect of the request. I went through several ideas involving extending WebdavServelt or Domain to provide different NamespaceAccessTokens with different Security implementations based on where the request came from. This should be viable, but as I was writing this I realized that simply providing your own Security implementation that always returned true for a specific user should be enough. You'll still need to authenticate to the app server as that user, but since the Security implementation doesn't actually do any checking it should speed things up. For requests that aren't from the special user come in your implementation can just call ACLSecurityImpl (or another implementation) to do the checking, which should add very little overhead to the existing system. -James Ritu Kedia wrote: >>>BTW how does JAAS decide what client currently accesses the webdav server? > > > JAAS can't detect that. In my case below I would have distinguished between > the 2 modes by the namespace (if that solution was possible). > > Regards, > Ritu > > -----Original Message----- > From: Stefan Lützkendorf [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 26, 2004 2:50 PM > To: Slide Users Mailing List > Subject: Re: A question on security configuration > > > > I recently thought about a "scoped SecurityImpl" because we want > to have different security checking mechanics on different scopes. > On one scope we want to use Slides ACL Security and on an other > we want to use the Security checking of our own system. > > We could of course have a SecurityImpl that permits all actions. > > But I'm not sure that meets your problem, because your need to use > different scopes. > > BTW how does JAAS decide what client currently accesses the webdav server? > > Regards, Stefan > > Ritu Kedia wrote: > >>I am using Slide in 2 modes: >>1. From within my Application, in which case my application acts as the >>entry point for a client. >>2. From a third party client, in which case Slide is the entry point for > > the > >>client. >> >>Slide is accessed from within my application using the Slide WebDAV client >>lib. Whereas it is accessed from the third party client via WebDAV (e.g. >>WebFolders in MS). >>In both these cases, the authentication is done using JAAS. And >>authorization depends on the mode of access. When accessed from within my >>application, the authorization will be done by my application but when >>accessed directly from a 3rd party client, the authorization should be > > done > >>by Slide's security support. In other words, my requirement is to turn off >>Slide's security in one mode and turn it on in the other mode. Both modes >>would be active simultaneously. Could someone please provide me any >>hints/help with designing a solution for the above requirement? >> >>One thought is to have 2 different namespaces, one for each of the above >>mode. Both these namespaces would access the same store but would have >>different security configurations. Is this achievable? I think this > > depends > >>on whether slide.properties is applicable per namespace or per domain. If >>anyone has implemented such a solution, then please do let me know. >> >> >>Regards, >>Ritu >> >> >> >>--------------------------------------------------------------------- >>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]
