You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by "Hermann, Eckehard" <Ec...@softwareag.com> on 2002/01/24 12:27:41 UTC
RE: userpath in ACL (original posting in Slide User)
Hi Dirk,
o.k., I had a look into the ACL standard and you are right, a principal has
to be a webdav resource and so in slide we will need the userpath. My
example/trick with changing the userpath should just demonstrate that it is
possible to change the access rights without having write-acl permission.
But however the webdav (slide) admin has to spend special care to the
Domain.xml file for protecting it against unauthorized userpath
manipulation.
I had problems with your 'more flexible configuration' example. I didn't get
it to run. Is it a planned or implemented feature?
I think the standard says something about how to manage groups (principal
collections) and principals. In case of a principal the DAV:resourcetype
property should report DAV:principal. A collection principal should report
DAV:principal and DAV:collection.
regards Eckehard
-----Original Message-----
From: Dirk Verbeeck [mailto:dirk.verbeeck@pandora.be]
Sent: Tuesday, January 22, 2002 11:03 PM
To: 'Slide Developers List'
Cc: Hermann, Eckehard; Pill, Juergen
Subject: Re: userpath in ACL (original posting in Slide User)
Hi Eckehard,
My point is that the external principal href should be a real href and
there is a difference between this path, the slide path and the store
path.
An overview of the current situation:
======================================================
context = webapp path
servlet scope = scope parameter in web.xml, default ""
store scope = scope parameter in domain.xml (store dependent), default
"/"
users path = users path in domain.xml
A normal uri:
External path /slide/files/document.doc
Slide path (remove context & servlet scope) /files/document.doc
Store path (remove store scope) /files/document.doc
Example with servlet scope "/files" and a store mapped to scope
"/storeA"
External path
/slide/files/storeA/document.doc
Slide path (remove context & servlet scope) /storeA/document.doc
Store path (remove store scope) /document.doc
A principal uri (in acl or propfind request)
Original path /slide/users/john
Slide path (remove context) /users/john
Store path (1) /users/john
A principal from authentication
Principal slide token john
Slide path (add users path) /users/john
(Code in SecurityImpl:getPrincipal but I think it should be more towards
the servlet layer because it is a part of mapping your external
Principal object onto a slide path)
======================================================
Internally Slide uses a slide path for all operations/lookups.
Towards the web and towards the stores the slide path is manipulated.
The only thing that is missing is what I explained in my previous mail,
the mapping from a store principal to a slide principal (1).
If the "users" store is the same as the "files" store then we want the
current situation.
<scope match="/" store="jdbc" userspath="/" />
The acl store path is /users/john on /files/document.doc.
But with this more flexible configuration:
<scope match="/" store="memory" userspath="/users" />
<scope match="/files" store="jdbc" userspath="/users" />
<scope match="/users" store="JNDI" userspath="/users" />
The acl store paths are john on document.doc
The JDBC store has a rule for "john" on "document.doc" and slide knows
where "john" is defined (userspath from line 2).
With this configuration you can move the store scope without
manipulating the uris.
If your realm returns the domain together with the username, use
something like /users/myserver/tom as a slide principal path.
<scope match="/" store="memory" userspath="/" />
<scope match="/files" store="jdbc" userspath="/users/myserver" />
<scope match="/users/myserver" store="OS-store"
userspath="/users/myserver" />
You define that the jdbc store acl rule with user "tom" is the user as
defined in "/users/myserver/tom"
If you later get another "tom" in another user store (another NT domain)
then you add:
<scope match="/files2" store="jdbc" userspath="/users/myserver2" />
<scope match="/users/myserver2" store="OS-store"
userspath="/users/myserver2" />
and a store that needs to know about both: (the internal user is then
"myserver/tom")
<scope match="/files2" store="jdbc" userspath="/users" />
Your trick with changing the userpath is not a real-life example, in
real-life you would create a group "editors" and add "tom" to the group
when he needs write permission.
I'm not sure what to do with groups, are the also mapped under /users or
under /groups.
Another issue is that currently a group acl principal needs a '+' sign
in front of it, should that be removed or not?
I thinking of keeping it to indicate to the store the parameter is not a
user but a group.
All of this is rather complex, mapping multiple stores into the same
namespace but that is part of the slide architecture.
Regards
Dirk
"Hermann, Eckehard" wrote:
>
> Hi Dirk,
>
> for authentication we would like to use as user-database the current OS,
so
> we wrote a Tomcat realm that does an authentication against the current OS
> platform. Because of slide uses its one user-database for authorisation
> (defined by the userpath) the user that is authenticated by Tomcat
differes
> from the user used for the authorisation by slide. For example we have a
> user 'tom' with a password 'cat' that is authenticated against the NT
domain
> 'myserver'. For the authorisation the user tom will get the userpath
prefix
> myserver/acl/users, defined by the slide domain.xml file. For a file
> testfolder/doc.xml two ACEs are defined one for the user
> myserver/acl/users/tom with the right deny read and one for the user
> testserver/acl/users/tom with the right grant read. For changing the right
> of user tom from deny read to grant read I don't need to have the
write-acl
> right on the node testfolder/doc.xml, I just must be able to update the
> userpath in the domain.xml file.
>
> I would like to be able to define an ACE with a principal like it is
passed
> from the authentication part to the authorisation part of my webdav server
> and not maipulated by adding a userpath on its way later, which could be
> updated by a third party. Yes it is true, I can define a store where I
> remove the userpath when I go to the store, but in this case I still have
to
> add the userpath during I define an ACE with the ACL method and after this
> it seems for me that it is used for nothing as just for slide internal
> usage, but if it is so, I don't understand why I have to see it in the ACL
> and PropFind methods. Please correct me if I'm on the wrong way.
>
> regards Eckehard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: userpath in ACL (original posting in Slide User)
Posted by Dirk Verbeeck <di...@pandora.be>.
Hi
Protecting the server configuration is needed, a misconfigured
domain.xml can do a lot of damage.
The more flexible configuration is one of the features of slide.
http://jakarta.apache.org/slide/namespace.html
I never used it myself and it is quite possible that there are problems
with it.
It also adds a lot of complexity to the slide engine (multiple
serverces, transactions,...) maybe it is not worth it or maybe we should
delegate this functionality to a higher (servlet container) or lower
(backend store) level.
Testing these configurations is not a priority for me, I only use one
scope for each domain.
It is a good way to start digging into the lower levels of slide if you
have the time.
Dirk
"Hermann, Eckehard" wrote:
>
> Hi Dirk,
>
> o.k., I had a look into the ACL standard and you are right, a principal has
> to be a webdav resource and so in slide we will need the userpath. My
> example/trick with changing the userpath should just demonstrate that it is
> possible to change the access rights without having write-acl permission.
> But however the webdav (slide) admin has to spend special care to the
> Domain.xml file for protecting it against unauthorized userpath
> manipulation.
>
> I had problems with your 'more flexible configuration' example. I didn't get
> it to run. Is it a planned or implemented feature?
>
> I think the standard says something about how to manage groups (principal
> collections) and principals. In case of a principal the DAV:resourcetype
> property should report DAV:principal. A collection principal should report
> DAV:principal and DAV:collection.
>
> regards Eckehard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: userpath in ACL (original posting in Slide User)
Posted by Dirk Verbeeck <di...@pandora.be>.
Hi
Protecting the server configuration is needed, a misconfigured
domain.xml can do a lot of damage.
The more flexible configuration is one of the features of slide.
http://jakarta.apache.org/slide/namespace.html
I never used it myself and it is quite possible that there are problems
with it.
It also adds a lot of complexity to the slide engine (multiple
serverces, transactions,...) maybe it is not worth it or maybe we should
delegate this functionality to a higher (servlet container) or lower
(backend store) level.
Testing these configurations is not a priority for me, I only use one
scope for each domain.
It is a good way to start digging into the lower levels of slide if you
have the time.
Dirk
"Hermann, Eckehard" wrote:
>
> Hi Dirk,
>
> o.k., I had a look into the ACL standard and you are right, a principal has
> to be a webdav resource and so in slide we will need the userpath. My
> example/trick with changing the userpath should just demonstrate that it is
> possible to change the access rights without having write-acl permission.
> But however the webdav (slide) admin has to spend special care to the
> Domain.xml file for protecting it against unauthorized userpath
> manipulation.
>
> I had problems with your 'more flexible configuration' example. I didn't get
> it to run. Is it a planned or implemented feature?
>
> I think the standard says something about how to manage groups (principal
> collections) and principals. In case of a principal the DAV:resourcetype
> property should report DAV:principal. A collection principal should report
> DAV:principal and DAV:collection.
>
> regards Eckehard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>