I am trying to the same thing: integrate my content management application
with
webDav with a single sign on.

Reading WCK, it seems that implementing
slide.simple.authentication.SessionAuthenticationManager plus change some
configuration files will do.  I am starting too...

Jane
----- Original Message ----- 
From: "Warwick Burrows" <[EMAIL PROTECTED]>
To: "'Slide Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Tuesday, November 23, 2004 9:16 PM
Subject: RE: authentication store


>
> My goal would be that when Slide calls to the security implementation to
> make an access check that I would replace the authorization piece here
with
> my own ACL implementation that identifies the incoming user by a username
> set in the HTTP request headers by our external security service which
will
> have already authenticated the user. I would also like to be able to
define
> my own access permissions and store them outside of Slide. Ie. replace the
> security store implementation if that's where permissions are defined.
>
> Ideally, I'd like to replace the ACL implementation so that the form and
> storage of permissions, the form and identification of users and the
actual
> authorization decision itself is defined by me but that it would be
> transparent to Slide so that the AclMethod would continue to work. We'll
see
> whether that's actually possible :-)
>
> Warwick
>
>
> > -----Original Message-----
> > From: James Mason [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, November 23, 2004 8:01 PM
> > To: Slide Users Mailing List
> > Subject: RE: authentication store
> >
> >
> > 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]
> >
>
> ---------------------------------------------------------------------
> 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]

Reply via email to