RE: A question on security configuration
On 30 Aug 2004 at 14:48, Ritu Kedia wrote: Hi Andreas, My application does use Slide's WebDAV Client Lib for communicating with Slide. So yes, both the direct access(via Word) and the access from my application are via WebDAV. I want to disable slide security checks in the direct access modeI would most likely use James' cluster refresh solution along with custom security implementation... So everybody is allowed to access as long as he or she goes via a WebDAV client? Is this really what you want? With reference to what you pointed below regarding performance issues with DeltaV turned on: Have you already faced a problem with that? If yes, then what is the nature of the performance problem? Is it just due to security checks or does it exist even with security turned off (i.e. for puts, checkin-checkout, etc)? I did not face the problem with the history folder, but I did experience it with normal folders. Putting the tenth thousand document into a single collection needs about 30 seconds. So having a collection in /history for each document would cause performance issues even if you don't have a single huge collection under /files. Therefor the hack is an interesting solution for this. The reason for the performance problem are: 1. adding a child means deleting all existing children from the store and adding the existing plus the new one. 2. loading a collection (Structure.retrieve()) means instantiating all children of this collection on stock, even if they are not needed. I haven't got experience with Security, but I think as long as you don't have very many ACLs the security checks should not slow down the system too much. I use DeltaV with both auto-versioning and security turned off. But I version every file in the system. Do you see any issues with the versioning once the # of files in the repository has gone above a particular limit? (I delete the version history when a file is deleted) Thanks for your comments. Regards, Ritu -Original Message- From: Andreas Probst [mailto:[EMAIL PROTECTED] Sent: Saturday, August 28, 2004 2:53 AM To: Slide Users Mailing List Subject: RE: A question on security configuration On 27 Aug 2004 at 13:19, Ritu Kedia wrote: :( ... 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. Can't you develop your HTTP application as a WebDAV client talking to Slide. You would use the login name and the password of the HTTP user to connect to Slide via WebDAV. So the information about who did the PUTs etc. wouldn't be lost. You would not need to implement the Security yourself. WebDAV users (Word) would talk to Slide directly. Actually checking the security stuff is not that expensive, although this probably depends on the number of ACLs on the path. You should be more concerned about performance when you get big directories, i.e. with more than thousand children. If you use DeltaV the /history folder could become a performance issue very soon. Maybe you've already explained why this is not possible for you, if so please excuse this remark... Regards, Andreas 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
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]
RE: A question on security configuration
:( ... 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
Re: A question on security configuration
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. It is configurable. Under XPath /slide/namespace/configuration you can set parameters for the security helper. It is called acl_semantics and expects whether one of two standard values (all-grant-before-any-deny or legacy-all-grant-before-any-deny) or a class name of your own security helper implementation. See the constructor of NamespaceAccessToken where the class is loaded. 2. Which methods would have to be implemented if I am interested only in the authorization checks and not the assignments? I guess the only method to override is evaluateAcl() like done in ACLSecurityImpl. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A question on security configuration
Stefan Fromm wrote:
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.
It is configurable. Under XPath /slide/namespace/configuration you can
set parameters for the security helper. It is called acl_semantics and
expects whether one of two standard values (all-grant-before-any-deny
or legacy-all-grant-before-any-deny) or a class name of your own
security helper implementation. See the constructor of
NamespaceAccessToken where the class is loaded.
2. Which methods would have to be implemented if I am interested only
in the
authorization checks and not the assignments?
I guess the only method to override is evaluateAcl() like done in
ACLSecurityImpl.
evaluateAcl() is private so override
public boolean hasPermission(SlideToken token, ObjectNode objectNode, ActionNode
actionNode)
e.g. you can use (if you extend ACLSecurityImpl
if (token.getCredentialsToken().getPrincipal().getName().equals(root)) {
return true;
} else {
return super(token, objectNode, actionNode);
}
Stefan
-
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]
RE: A question on security configuration
On 27 Aug 2004 at 13:19, Ritu Kedia wrote: :( ... 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. Can't you develop your HTTP application as a WebDAV client talking to Slide. You would use the login name and the password of the HTTP user to connect to Slide via WebDAV. So the information about who did the PUTs etc. wouldn't be lost. You would not need to implement the Security yourself. WebDAV users (Word) would talk to Slide directly. Actually checking the security stuff is not that expensive, although this probably depends on the number of ACLs on the path. You should be more concerned about performance when you get big directories, i.e. with more than thousand children. If you use DeltaV the /history folder could become a performance issue very soon. Maybe you've already explained why this is not possible for you, if so please excuse this remark... Regards, Andreas 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
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]
RE: A question on security configuration
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]
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]
RE: A question on security configuration
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. 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? 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]
Re: A question on security configuration
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
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]
RE: A question on security configuration
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]
