incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
Subject Re: LDAP Authentication?
Date Mon, 25 Apr 2011 00:58:39 GMT
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

On Apr 24, 2011, at 3:19 PM, Brian Burch <brian@PingToo.com> wrote:

> On 24/04/11 17:50, Brian Bowling wrote:
>> Hi Brian,
>> I have been looking at adding LDAP authentication to my jspwiki implementation also,
so this was very helpful.  Would it be possible for you to post a sample LDIF entry for a
user or two?
> 
> I should start by saying that I use the apacheds project for my ldap server. I used to
use the iPlanet/Sun/Fedora directory server and it has taken me a while to come to terms with
the more modern (standards conformant) schema and access control mechanisms in apacheds. (I'm
not at the bleeding edge - I've been using 1.5.4 in production for nearly 2 years). The last
time I looked, most of the alternatives are incompatible in these important areas, but I'll
offer mine and you'll have to convert if necessary (you'll get the general idea).
> 
> I have a lot of SIP mods in my directory, so I "stole" some "spare" oid's from the SIP
space...
> 
> dn: cn=schema
> changetype: modify
> add: attributetypes
> attributetypes: ( 0.0.8.350.1.1.6.1.20
>     NAME 'tomcatRole'
>     DESC ' the name of a tomcat security role'
>     EQUALITY caseIgnoreMatch
>     SUBSTR caseIgnoreSubstringsMatch
>     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
> 
> dn: cn=schema
> changetype: modify
> add: objectclasses
> objectclasses: ( 0.0.8.350.1.1.6.2.80
>     NAME 'tomcatRoleAllowed'
>     DESC 'tomcatRoleAllowed aux object'
>     SUP top AUXILIARY
>     MAY tomcatRole
>   )
> 
> I'll leave it to you to define an authenticator user entry and suitable ACI's (because
they are not critical to getting something working). I have a group called ldapAuths and define
ACI's to say what they can and can't do. My tomcat container authenticator is a member of
that group, so it can read a wider range of sensitive attributes than it actually needs, but
it can't change anything.
> 
> Here is how I give a typical user permission to access jspwiki:
> 
> dn: uid=testUser1,ou=People,o=PingToo.com
> changetype: modify
> replace: objectclass
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectclass: tomcatRoleAllowed
> -
> replace: tomcatRole
> tomcatRole: tomcat
> tomcatRole: family
> tomcatRole: photoview
> tomcatRole: wikiuser
> -
> replace: userpassword
> # tomcat is setup for SHA digests but can't handle multiple hashes
> userPassword: {SHA}nvRBAtZQFzdRld1vS1TWlBb6kuQ=
> 
> Don't be afraid - the best way to eat an elephant is one bite at a time!
> 
> Regards,
> 
> Brian
> 

Mime
View raw message