jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <br...@PingToo.com>
Subject Re: LDAP Authentication?
Date Mon, 25 Apr 2011 10:31:39 GMT
On 25/04/11 01:58, Andrew Jaquith wrote:
> Brian, Jim and all:
>
> Good summary. Thought I'd add a few more details.
>
> JSPWiki tries to be smart about using container authentication. I designed it so that
if you used the container to authenticate via LDAP or any other realm your container might
be able to use, JSPWiki will be able to work with it. As described by a previous commenter,
container-managed authentication and authorization is assumed whenever at least one URL restriction
exists in web.xml. Uncommenting the protection on Wiki.jsp, for example, will trigger this
behavior.
>
> Authentication with the container (for example, with LDAP) is handled by checking for
the presence of a non-null value for HttpServletRequest.getRemoteUser() or getUserPrincipal().
If either of these are non-null, JSPWiki assumes the user is authenticated, and that value
is used as the JSPWiki login name. The user database, then, is used to store the rest of the
JSPWiki account details like "full name."
>
> For authorization, JSPWiki checks permissions as required by a page ACL or by jspwiki.policy
by checking whether a user:
> - belongs to a "built-in" role such as ALL, ASSSERTED, AUTHENTICATED
> - belongs to a container-managed role, such as a container-managed LDAP realm might define
> - belongs to a named wiki group, as defined by the JSPWiki GroupManager
> - is a named person, as defined in the JSPWiki UserManager
>
> Container-managed checks for role permissions (other than the built-in ALL, ASSSERTED,
AUTHENTICATED roles) is done by delegating to HttpServletRequest.isUserInRole(). There is
one caveat, though: the roles must be explicitly named in web.xml so that JSPWiki "knows"
about them. If you observe that simple practice, though, JSPWiki will happily delegate to
the container for role checks. JSPWiki groups, of course, are managed separately from container
roles, so these can also be used for permissions.
>
> These capabilities, taken together, allow for quite a bit of flexibility. They can occasionally
seem confusing, but the idea is to allow deployers to mix and match built-in and container-managed
authentication and authorization.
>
> -- Andrew

Thanks very much, Andrew. I haven't been motivated enough to look at 
that area of code and your explanation is very clear. It sounds as if my 
choice of role names, along with my empty jspwiki auth files, has NOT 
triggered the sort of hybrid environment I had feared.

That means my earlier comment about having to fine-tune the web.xml 
<web-resource-collection> url-patterns still seems to be valid. If 
anyone gets far enough with ldap container authentication/authorisation 
to need help, just ask and I'll publish what I am currently using. It is 
probably far from complete or generalised, but it works for me.

Brian

Mime
View raw message