[EMAIL PROTECTED] wrote:
Hi,
I think it will be better if I summarize what I am trying to do:
-Thousands of users and roles/groups are already defined at ldap.
-There is an application using slide as backend, it accesses slide
using webdav. Users can't access slide directly. Users are
authenticated in this application, and we don't want to authenticate
them again for slide.
- We want to pass current user info from our application to slide, and
this user info must be used for acl mechanisms etc.
I'm faced with a similiar problem. We have different applications
(servlets) which need
authentication and authorisation. The Slide webdav repository is one of
them.
We don't want to duplicate authentication and authorisation information
for all the users,
we want a centralized user store which contains all needed information.
What I want to do is to create a centralized store which contains
usernames, passwords
and roles. These should be used (among other things) to access the slide
repository.
I guess I have to keep track of which user/role is allowed to do which
action on which
repository resource also?
First of all, is this possible?
Second, what's the best way to do it?
1) Write my own JAAS login module: I've read the mails about the problems
configuring
a simple JAAS authentication login module since I had the same kind of
problems...
It can only be used when you want to replace authentication, but not
authorisation, right?
2) Write my own security store, like the JNDIPrincipalStore. If this is
the best choice,
which interfaces are important? The are a lot of interfaces implemented,
but the
implementations of all the interface's methods are empty.
3) Write my own implementation of the storing system (with use of WCK).
This seems overkill,
since I only want to replace the authentication and authorisation.
And since we're heavily making use of versioning, WCK is not the way to
go, right?
4) Other?
Thanks in advance!
David.
--------------------------------------------------
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
Somewhere between #3 and #4 : You might also want to take a look at:
http://acegisecurity.sourceforge.net/ From what I've seen it looks
pretty complete, and might offer some interesting features.
--
Robert r. Sanders
Chief Technologist
iPOV
www.ipov.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]