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
