Ritu Kedia wrote:
I very much appreciate your taking the time to think about the different
issues that people have (I have seen you giving great suggestions on a lot
of other issues too). Definitely thanks for your help.

Thanks! I appreciate the compliment.


The second suggestion that you gave below about clustering, is exactly what I was thinking of. But as you pointed out that it is a new feature and *very untested*, I would opt for that solution as a last resort. At this point I am looking for a very quick and sure shot solution. I was just hoping that may be slide.properties could be configured per namespace. Alas I don't think thats possible, at least with the current implementation.

One question on performance impact due to security checks: what is the most
time consuming aspect of slide security? Is it the enumeratePermissions
method?

I think the problem is more with Security.hasPermission() since it iterates through all of the inheritted permissions. I could be wrong, though. Maybe someone else can shed some light on this.


-James


Regards, Ritu

-----Original Message-----
From: James Mason [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 26, 2004 9:42 AM
To: Slide Users Mailing List
Subject: Re: A question on security configuration


Ok, so you don't like my ideas :).

I've never played with namespaces, so that could be a good option and I wouldn't know it :). However, since security is controlled in the slide.properties file you're probably going to need a completely separate instance of Slide.

So my *new* suggestion is to try running two instance of Slide in a cluster, one with security and the other without. There's info for how to configure this on the Wiki. Clustering is very untested at this point, so if you've got the time it would be great if you could put it through its paces :).

-James

Ritu Kedia wrote:

Thanks for the reply James.

Your approach has 2 problems:
1. The most important one is : I want to avoid slide security checks for
performance reasons and specially since I am already doing the
authorization, I definitely want to avoid slide side overhead.
2. Even if I ignore performance, I still face a problem with the user info
logging against every activity. In other words I lose the information

about

who uploaded the file/locked it/checked it in.

What about the namespace solution... is it possible to configure different
security properties for a different namespace in the same App Server
instance?
Or could you suggest some other alternate whereby I could turn off

security

checks when accessed from a particular client?

Regards,
Ritu

-----Original Message-----
From: James Mason [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 24, 2004 10:28 PM
To: Slide Users Mailing List
Subject: Re: A question on security configuration


Ritu,
One option might be to have a user account with all access to every node in your store and always use that account when connecting with your application.


-James

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]




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



Reply via email to