You can implement the Security interface to provide your own custom permission logic. An easier way might be to extend SecurityImpl, or even ACLSecurityImpl.
Be aware that the WebDAV ACL specification has specific requirements beyond just how ACLs are evaluated. If all of your security management will happen outside of Slide then it should be enough to remove or disable AclMethod (not sure the best way to do this), since you won't need Slide to implement the ACL spec. -James On Tue, 2004-11-23 at 09:19 -0800, Warwick Burrows wrote: > Great summary James. I'll need to reimplement Slide authorization at some > time so this is good information for me too. If I want to reimplement the > entire ACL implementation is there a nice clean interface layer that I can > implement? Will I be able to remove the user store from the process since > I'm not using Slide ACL implementation? > > Thanks, > Warwick > > > > -----Original Message----- > > From: James Mason [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 22, 2004 9:50 PM > > To: Slide Users Mailing List > > Subject: Re: authentication store > > > > > > Slide delegates all authentication to the app server, so any > > authentication source your app server supports (db, xml file, > > ldap) can be used to authenticate users to Slide. In order to > > expose Slide's internal user's to the app server Slide > > provides a JAAS implementation. > > > > For authorization Slide needs to be able to access principals > > (users and > > roles) according to the webdav ACL specification. Part of > > that specification says all principals need to be accessible > > at a URI. This means that for Slide to do authorization every > > user and role needs to be be a node in Slide. > > > > You have three basic options for custom user management: > > > > 1) Implement a custom authentication mechanism for your app > > server (probably JAAS) and turn on auto-create-users to make > > Slide aware of your users. > > > > 2) Implement a custom Store for Slide to expose your users > > and roles as nodes in Slide. You'll need a "password" > > property in the Slide namespace in order for Slide's app > > server integration to work. > > > > 3) A combination of the first two. The JNDIStore takes this > > approach, taking advantage of most app server's built-in > > ability to authenticate against LDAP. > > > > -James > > > > On Mon, 2004-11-22 at 09:43 -0600, Chris O'Connell wrote: > > > Another newbie question... > > > > > > I need to integrate my content management application with > > an existing > > > suite of applications that all use a single sign-on > > framework. I see > > > lots of references to using a custom authentication mechanism > > > (presumably, instead of creating users in the Domain.xml). > > I really > > > want to do this, since having to modify Domain.xml every > > time I want > > > to add a new user, role etc. is not acceptable. Can anyone > > point me > > > at a link or some resource that provides some steps to > > implement this? > > > How do I tell Slide to use my mechanism? What is the > > interface? etc. > > > etc. > > > > > > Thanks in advance. This group has been a lot of help to me so far. > > > > > > Chris > > > > > > > > --------------------------------------------------------------------- > > > 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]
