Bug 37044 - JAASRealm / RealmBase role checking bug ?
Summary: JAASRealm / RealmBase role checking bug ?
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.12
Hardware: All other
: P2 major with 2 votes (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
: 37518 (view as bug list)
Depends on:
Reported: 2005-10-12 15:51 UTC by Peter Mikula
Modified: 2006-08-08 08:03 UTC (History)
3 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Mikula 2005-10-12 15:51:22 UTC
JAASRealm authenticates the user and creates a GenericPrincipal with 
  userPrincipal set to some principal returned by LoginModule.

  Later RealmBase.hasResourcePermission() calls request.getUserPrincipal()
  to recover authenticated user principal

  Request.getUserPrincipal() checks if the principal is instanceof 
  GenericPrincipal, and if it is, it returns its userPrincipal. 

  RealmBase.hasRole() checks if the principal is instanceof GenericPrincipal 
  and if not it fails immediately.

  Note: previous versions of JAASRealm had their own hasRole() implementation.

  Note: request.isUserInRole() is not getting userPrincipal from 
  GenericPrincipal when calling realm.hasRole() and this one seems to
Comment 1 Brian Gilstrap 2005-10-14 19:07:54 UTC
I have also experienced this bug with a custom JAAS LoginModule.

If Request.getUserPrincipal is changed to this:

    public Principal getUserPrincipal() {
//        if (userPrincipal instanceof GenericPrincipal) {
//            return ((GenericPrincipal) userPrincipal).getUserPrincipal();
//        } else {
            return (userPrincipal);
//        }

Things seem to work fine (though I don't know if this might have negative
impacts elsewhere).
Comment 2 Remy Maucherat 2005-10-17 12:40:36 UTC
RealmBase.hasResourcePermission() indeed needs to get the actual
GenericPrincipal rather than the result of getUserPrincipal().
Comment 3 Remy Maucherat 2005-11-16 01:38:42 UTC
*** Bug 37518 has been marked as a duplicate of this bug. ***
Comment 4 Jack Yu 2005-11-16 01:49:04 UTC
(In reply to comment #3)
> *** Bug 37518 has been marked as a duplicate of this bug. ***

I assume the solution was: 
public Principal getUserPrincipal() {
//        if (userPrincipal instanceof GenericPrincipal) {
//            return ((GenericPrincipal) userPrincipal).getUserPrincipal();
//        } else {
            return (userPrincipal);
//        }

That will force JAASRealm to use GenericPrincipal as the only userClassNames 
and roleClassName in server.xml.

Suggest add back hasRole in JAASRealm, a little redundent, but seems no other 
better way. 

in JAASRealm.java, add roleSet private instance variable, then in 
createPrincipal method, just after roles.add(principal.getName());,
add "roleSet.add(principal);"

then add hasRole method like following:

public boolean hasRole(Principal principal, String role) {
    if (principal == null) {
         return false;
    Iterator it = roleSet.iterator();
    while (it.hasNext()) {
        Principal p = (Principal)it.next();
        if (p.equals(principal)) {
            return true;
    return super.hasRole(principal, role);
Comment 5 Joerg prante 2005-12-22 00:15:39 UTC
This one has not been fixed.

Would you please consider to fix JAASRealm with a correct hasRole() method?

This would make life easier for JAAS realm login module implementors. 
Custom role classes are causing 403 forbidden messages, which drives people
crazy because all parameter settings are correct. 

The 5.5.4 implementation uses a roleMap, which works fine. I don't know why it
has been removed. It broke all custom role classes.
Comment 6 Stephan Markwalder 2006-06-01 09:49:51 UTC
This bug has not been fixed. Source code of class JAASRealm in version 5.5.12 is
identical with source code in current version (5.5.17).
Comment 7 Ralf Hauser 2006-08-08 15:03:20 UTC
There appears to be quite some confusion about how the roles should work

  - Bug 37852 apparently has applied a patch, but even with 5.5.17 (the relevant
classes are still the same in SVN Head), some people (me included) do not get
configurations to work that work previously...

  - Bug 39364 provides a concrete example and Mark says that this is according
to the specs ?