When I first looked at slide I assumed it would use servlet container security (I wasn't familiar with the webdav spec). Clearly it can't use j2ee security and conform to the webdav spec.It is possible to assign different stores to different scopes (like mount points), so you don't need the proxy thing. So the main task would be to write a LDAP-store. To have such a store would be really a great thing so that users and roles are stored only in one physical store.
The ideal solution for me would be to have slide authenticate using LDAP and the servlet container use slide for authentication. I'm using Weblogic 8.1 and it is already configured to use LDAP for security so the route of least resistence to get authentication working is to automatically add users authenticated by the serlet container. Unfortunately - like Daniel says - this means the slide user database is out of sync with the LDAP database.
To get the LDAP users and roles into slide wouldn't it be slightly more complicated than just writing a store for LDAP (even tough it sounds like this is pretty complicated). I would only want to use the LDAP store for the users and roles directories not the rest of the directories. I would have thought I would need a proxy store that would use the correct underlying store for different directories - LDAP for users and roles and JDBC for the rest, in my case.
If LDAP provides some notification mechanism for informing slide about user/role updates additional user/role caching would be possible to achieve better performance.
Regards,
Daniel
Another approach might be to import LDAP users and roles into slide and listen for updates on LDAP to keep the two in sync.
Could you not make a store read-only by simply making sure no user had any write permissions?
-----Original Message----- From: Martin Holz [mailto:[EMAIL PROTECTED] Sent: 26 April 2004 13:49 To: [EMAIL PROTECTED] Subject: Re: patch for auto-create-users
Daniel Florey <[EMAIL PROTECTED]> writes:
Hi,
I'd propose to add the methods regarding the user/role stuff to the
Security-Interface and the SecurityImpl-class. There already are some
methods regarding user/role management (hasRole()...)
This is not possible, since the methods need access to ContentImpl et. al. which are not available. Adding those helpers would create cyclic dependencies.
In general I think it would be better to have only one place
(e.g. LDAP) where users are managed and give slide the ability to
access the LDAP-user/roles.
This is definitely one way. It can be done right now, if you implement
a LDAP store. However mapping LDAP groups to slide groups can be a real pain. As a side note slide has currently no concept
of a read only store, which would be really useful here.
What if you add a user and auto-create it in slide. After that you grant a permission to this user and delete the user lateron? The user will not be deleted in slide as no auto-delete can be done. So you have an inconsistent user database where some users in slide exist that don't exist in your primary user store anymore.
Adding your propsed methods is a good thing anyway as many users might
need some simple methods to create users and add roles at slide api
level.
--------------------------------------------------------------------- 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]
