posted 15 years ago
I haven't gone over every last possibility, but it looks like your authentication info is correct and you're logging in, but the role information isn't, so anything that runs under a role will be forbidden.
Your problem is that you're attempting to store the roles in the same "directory" as the user account information. Actually, more like "com/mycompany/cn/cn", to express it in disk directory form for simplicity's sake.
Normally you'd store the roles in a separate directory, such as "ou=groups,dc=mycompany,dc=com". Inside that directory, you'd have "cn" entries for the roles, and under those cn entries, you'd have attributes that would list the users who'd participate in those roles. Here's a more complete example, based on the Tomcat samples:
The roleBase is "dc=mycompany,dc=com". That's the root directory of the search (set userSubTree if you want to to search subdirectories).
The roleSearch is on the "uniqueMember" attribute. It's what you're going to match against, and you specified the "{0}" value, so it's going to match against the user's complete directory path.
Finally, the roleName is the "cn" attribute of the roleBase entry. Which is either "clerk", "auditor" or "sysadmin" in this example.
Note that jwelch has both audit and sysadmin capabilities and "fbloggs" is both a clerk and an auditor. The J2EE security system understands the "many hats" concept of business where one person has multiple functions. Especially after the downsizing, but that's another matter.
"Disappointing" and "Utterly Horrible" are not equal.