LDAP Authentication?

[jlist9]

I found this page in my searching for a way to authenticate against OpenDS
LDAP
server. This is the page I found:
http://www.jspwiki.org/wiki/LDAPAuthentication?version=25

However I'm still confused after reading it. I'm using the latest version of
jspwiki.
Is there an official or semi-official way of authenticating against a LDAP
server?

Thanks,
Jack

[Jim Willeke]

We are using Container Authentication and Authorization with JspWiki and
LDAP.
http://ldapwiki.willeke.com/wiki/TomcatAndLDAP

-jim
Jim Willeke


On Sat, Apr 23, 2011 at 8:20 PM, jlist9 <jlist9@...> wrote:

> I found this page in my searching for a way to authenticate against OpenDS
> LDAP
> server. This is the page I found:
> http://www.jspwiki.org/wiki/LDAPAuthentication?version=25
>
> However I'm still confused after reading it. I'm using the latest version
> of
> jspwiki.
> Is there an official or semi-official way of authenticating against a LDAP
> server?
>
> Thanks,
> Jack
>

[Brian Burch]

On 24/04/11 08:50, Jim Willeke wrote:

> We are using Container Authentication and Authorization with JspWiki and
> LDAP.
> http://ldapwiki.willeke.com/wiki/TomcatAndLDAP
>
> -jim
> Jim Willeke
>
>
> On Sat, Apr 23, 2011 at 8:20 PM, jlist9<jlist9@...>  wrote:
>
>> I found this page in my searching for a way to authenticate against OpenDS
>> LDAP
>> server. This is the page I found:
>> http://www.jspwiki.org/wiki/LDAPAuthentication?version=25
>>
>> However I'm still confused after reading it. I'm using the latest version
>> of
>> jspwiki.
>> Is there an official or semi-official way of authenticating against a LDAP
>> server?
>>
>> Thanks,
>> Jack

I can confirm that all the documentation exists, yet it can be hard to
follow and integrate, even if you believe you understand ldap AND
container security! What I have works well and scales, but might not be
perfect.

1. You need to set up your ldap directory for webapp users:
1.1. Define an attribute to hold the various container security classes
that you want. I couldn't find anything pre-defined that suited me, so I
created a new attribute called "tomcatRole" in a "spare" section of the
schema oid space.
1.2. I then defined a new objectClass that would permit user entries to
have tomcatRole attributes, in my case called "tomcatRoleAllowed".
1.3. I then modified my user entries to add the tomcatRoleAllowed
objectclass and appropriate tomcatRole attributes (e.e. wikiUser,
webMailUser, manager, etc).

At this point, you have a Authentication/Authorisation dataset in the
ldap directory, but nothing is using it.

2. You need to set up your ldap directory so that your web server can
authenticate users against the ldap directory:
2.1. If you don't have one already, set up ACI's and a group that has
permission to read "secure" attributes, such as password hashes and the
new container role.
2.2. define a new authenticator user entry for tomcat and put it into
the group.

At this point, you should be able to test the new authenticator
credentials by searching for a user entry and retrieving the password
hash and the associated web container authorisations.

3. Turn on tomcat container security:
3.1. Modify the tomcat conf/server.xml inside the <engine> to define a
JNDIRealm which specifies the ldap directory server and your
authenticator's credentials, how to search for user entries and which
(protected) attributes to retrieve.
3.2. Within the Host entry, define the SingleSignOn Valve so that
someone authenticating with any webapp will not need to signon again
when going to a different webapp container.

At this point, tomcat will force users that wish to access a protected
webapp to signon (if they haven't already done so), authenticating them
against your ldap directory and discovering the roles they have been
assigned. The webapps only know the names of the roles - not how they
are stored or assigned.

4. Configure jspwiki to use container security:
4.1. turn on the commented-out section in wiki/WEB-INF/web.xml and
modify it to suit your requirements. My jspwiki has several security
constraints: the entire container is protected; guests can only read;
some users can create new entries; managers can delete. It is tricky to
define exactly which resources need to be protected at the different
levels, but it isn't too confusing because you are only working with a
few abstract role names. I had to do a lot of testing to fine tune my
web-resource-collections before I was satisfied.

At this point, your other webapps would not be protected. My own system
has only the home and standard error pages unprotected, so I had to
setup a single signon and menu webapp that forces all users to
authenticate. I also had to modify each of my other webapps to enforce
container security.

It is a lot to do, but it will work in the end. If you follow the
sequence of tasks above, you should have confidence that each step is
correct and so need only worry about one thing at a time!

Good luck,

Brian

[jlist9]

Thanks! Did you have to modify jspwiki to implement container security?

On Sun, Apr 24, 2011 at 12:50 AM, Jim Willeke <jim@...> wrote:

> We are using Container Authentication and Authorization with JspWiki and
> LDAP.
> http://ldapwiki.willeke.com/wiki/TomcatAndLDAP
>
> -jim
> Jim Willeke
>
>
> On Sat, Apr 23, 2011 at 8:20 PM, jlist9 <jlist9@...> wrote:
>
> > I found this page in my searching for a way to authenticate against
> OpenDS
> > LDAP
> > server. This is the page I found:
> > http://www.jspwiki.org/wiki/LDAPAuthentication?version=25
> >
> > However I'm still confused after reading it. I'm using the latest version
> > of
> > jspwiki.
> > Is there an official or semi-official way of authenticating against a
> LDAP
> > server?
> >
> > Thanks,
> > Jack
> >
>

[jlist9]

Brian,

Thanks a lot for the instructions! I'm not familiar with container
security so the list looks somewhat daunting to me :-)

I was also looking at JForum's code - it does LDAP authentication.
I suppose its security mechanism isn't implemented the same way
as it uses some internal simple classes to verify user information
via JNDI. Is it possible to implement something like this in jspwiki
without having to do a lot of modifications?

Jack

On Sun, Apr 24, 2011 at 2:50 AM, Brian Burch <brian@...> wrote:

> I can confirm that all the documentation exists, yet it can be hard to
> follow and integrate, even if you believe you understand ldap AND container
> security! What I have works well and scales, but might not be perfect.
>
> 1. You need to set up your ldap directory for webapp users:
> 1.1. Define an attribute to hold the various container security classes
> that you want. I couldn't find anything pre-defined that suited me, so I
> created a new attribute called "tomcatRole" in a "spare" section of the
> schema oid space.
> 1.2. I then defined a new objectClass that would permit user entries to
> have tomcatRole attributes, in my case called "tomcatRoleAllowed".
> 1.3. I then modified my user entries to add the tomcatRoleAllowed
> objectclass and appropriate tomcatRole attributes (e.e. wikiUser,
> webMailUser, manager, etc).
>
> At this point, you have a Authentication/Authorisation dataset in the ldap
> directory, but nothing is using it.
>
> 2. You need to set up your ldap directory so that your web server can
> authenticate users against the ldap directory:
> 2.1. If you don't have one already, set up ACI's and a group that has
> permission to read "secure" attributes, such as password hashes and the new
> container role.
> 2.2. define a new authenticator user entry for tomcat and put it into the
> group.
>
> At this point, you should be able to test the new authenticator credentials
> by searching for a user entry and retrieving the password hash and the
> associated web container authorisations.
>
> 3. Turn on tomcat container security:
> 3.1. Modify the tomcat conf/server.xml inside the <engine> to define a
> JNDIRealm which specifies the ldap directory server and your authenticator's
> credentials, how to search for user entries and which (protected) attributes
> to retrieve.
> 3.2. Within the Host entry, define the SingleSignOn Valve so that someone
> authenticating with any webapp will not need to signon again when going to a
> different webapp container.
>
> At this point, tomcat will force users that wish to access a protected
> webapp to signon (if they haven't already done so), authenticating them
> against your ldap directory and discovering the roles they have been
> assigned. The webapps only know the names of the roles - not how they are
> stored or assigned.
>
> 4. Configure jspwiki to use container security:
> 4.1. turn on the commented-out section in wiki/WEB-INF/web.xml and modify
> it to suit your requirements. My jspwiki has several security constraints:
> the entire container is protected; guests can only read; some users can
> create new entries; managers can delete. It is tricky to define exactly
> which resources need to be protected at the different levels, but it isn't
> too confusing because you are only working with a few abstract role names. I
> had to do a lot of testing to fine tune my web-resource-collections before I
> was satisfied.
>
> At this point, your other webapps would not be protected. My own system has
> only the home and standard error pages unprotected, so I had to setup a
> single signon and menu webapp that forces all users to authenticate. I also
> had to modify each of my other webapps to enforce container security.
>
> It is a lot to do, but it will work in the end. If you follow the sequence
> of tasks above, you should have confidence that each step is correct and so
> need only worry about one thing at a time!
>
> Good luck,
>
> Brian
>
>

[Brian Bowling]

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?

Thanks.

Brian



On Apr 24, 2011, at 5:50 AM, Brian Burch <brian@...> wrote:

> On 24/04/11 08:50, Jim Willeke wrote:
>> We are using Container Authentication and Authorization with JspWiki and
>> LDAP.
>> http://ldapwiki.willeke.com/wiki/TomcatAndLDAP
>>
>> -jim
>> Jim Willeke
>>
>>
>> On Sat, Apr 23, 2011 at 8:20 PM, jlist9<jlist9@...>  wrote:
>>
>>> I found this page in my searching for a way to authenticate against OpenDS
>>> LDAP
>>> server. This is the page I found:
>>> http://www.jspwiki.org/wiki/LDAPAuthentication?version=25
>>>
>>> However I'm still confused after reading it. I'm using the latest version
>>> of
>>> jspwiki.
>>> Is there an official or semi-official way of authenticating against a LDAP
>>> server?
>>>
>>> Thanks,
>>> Jack
>
> I can confirm that all the documentation exists, yet it can be hard to follow and integrate, even if you believe you understand ldap AND container security! What I have works well and scales, but might not be perfect.
>
> 1. You need to set up your ldap directory for webapp users:
> 1.1. Define an attribute to hold the various container security classes that you want. I couldn't find anything pre-defined that suited me, so I created a new attribute called "tomcatRole" in a "spare" section of the schema oid space.
> 1.2. I then defined a new objectClass that would permit user entries to have tomcatRole attributes, in my case called "tomcatRoleAllowed".
> 1.3. I then modified my user entries to add the tomcatRoleAllowed objectclass and appropriate tomcatRole attributes (e.e. wikiUser, webMailUser, manager, etc).
>
> At this point, you have a Authentication/Authorisation dataset in the ldap directory, but nothing is using it.
>
> 2. You need to set up your ldap directory so that your web server can authenticate users against the ldap directory:
> 2.1. If you don't have one already, set up ACI's and a group that has permission to read "secure" attributes, such as password hashes and the new container role.
> 2.2. define a new authenticator user entry for tomcat and put it into the group.
>
> At this point, you should be able to test the new authenticator credentials by searching for a user entry and retrieving the password hash and the associated web container authorisations.
>
> 3. Turn on tomcat container security:
> 3.1. Modify the tomcat conf/server.xml inside the <engine> to define a JNDIRealm which specifies the ldap directory server and your authenticator's credentials, how to search for user entries and which (protected) attributes to retrieve.
> 3.2. Within the Host entry, define the SingleSignOn Valve so that someone authenticating with any webapp will not need to signon again when going to a different webapp container.
>
> At this point, tomcat will force users that wish to access a protected webapp to signon (if they haven't already done so), authenticating them against your ldap directory and discovering the roles they have been assigned. The webapps only know the names of the roles - not how they are stored or assigned.
>
> 4. Configure jspwiki to use container security:
> 4.1. turn on the commented-out section in wiki/WEB-INF/web.xml and modify it to suit your requirements. My jspwiki has several security constraints: the entire container is protected; guests can only read; some users can create new entries; managers can delete. It is tricky to define exactly which resources need to be protected at the different levels, but it isn't too confusing because you are only working with a few abstract role names. I had to do a lot of testing to fine tune my web-resource-collections before I was satisfied.
>
> At this point, your other webapps would not be protected. My own system has only the home and standard error pages unprotected, so I had to setup a single signon and menu webapp that forces all users to authenticate. I also had to modify each of my other webapps to enforce container security.
>
> It is a lot to do, but it will work in the end. If you follow the sequence of tasks above, you should have confidence that each step is correct and so need only worry about one thing at a time!
>
> Good luck,
>
> Brian
>

[Brian Burch]

On 24/04/11 17:23, jlist9 wrote:

> Brian,
>
> Thanks a lot for the instructions! I'm not familiar with container
> security so the list looks somewhat daunting to me :-)
>
> I was also looking at JForum's code - it does LDAP authentication.
> I suppose its security mechanism isn't implemented the same way
> as it uses some internal simple classes to verify user information
> via JNDI. Is it possible to implement something like this in jspwiki
> without having to do a lot of modifications?

Your question made me wonder... I've just checked my jspwiki.properties
and am surprised to discover that I have left the default custom
authentication definitions active IN ADDITION to my container-managed
security-constraints. I have therefore got two layers of security: the
container layer, and the default empty userdatabase.xml. Perhaps this
goes some way to explaining why I had to do so much work defining the
web-resource-collections for each role??? I'll have to look into that
aspect when I have time to spare.

Anyway, to answer your question, I've written a lot of custom ldap java
authentication and authorisation code over the years, so I have a lot of
experience and useful source available. I decided the best approach was
to use the existing container managed ldap security rather than invent
my own. It is complex to deal with cases you might not care about. It
might not even be an optimal solution. However, I strongly recommend
sticking with the existing standards and reference implementations!

On the other hand, if you don't already have a commitment to use ldap,
you should stick with the simple standalone default jspwiki
implementation of authentication and authorisation.

Brian

[Brian Burch]

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

[Andrew Jaquith-4]

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@...> 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
>

[Brian Burch]

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

[Mark Craig-2]

On Sun, Apr 24, 2011 at 9:19 PM, Brian Burch <brian@...> 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
>   )
>
>

OpenDJ (and I think OpenDS, too) does not recognize "SUBSTR
caseIgnoreSubstringsMatch" in the attribute type definition.

I put the following in a file called
99-tomcat-roles.ldif<http://mcraig.org/ldif/99-tomcat-roles.ldif>,
copied it to OpenDJ/config/schema, and it seemed to work for me. (YMMV
copying LDIF out of email, hence the link.)

dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
attributeTypes: ( 0.0.8.350.1.1.6.1.20 NAME 'tomcatRole' DESC 'the
name of a tomcat security role' EQUALITY caseIgnoreMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
objectClasses: ( 0.0.8.350.1.1.6.2.80 NAME 'tomcatRoleAllowed' DESC
'tomcatRoleAllowed aux object' SUP top AUXILIARY MAY tomcatRole )

Regards,
Mark

> 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
>
>