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 <[email protected]> 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 >
