TitleAuthorization to edit
Date18-Aug-2006 16:11:31 EEST
Bug criticalityBadBug
Browser versionMozilla 1.7.13
Bug statusClosedBug
PageProvider used?
Servlet Containertomcat
Operating SystemFedora Core 5
Java version1.5.0-08

I have configured container authentication: at beginning jspwiki.jaas has an extra rule:

tomcat { 
        com.sun.security.auth.module.Krb5LoginModule required debug=true storePass=true;

web.xml has the security constraints enabled (comment "REMOVE ME..." was removed).

I click the Edit tab/link, get "Forbidden...". Removed Edit.jsp, restart tomcat, still get "Forbidden..." (Edit.jsp is not accessed!). I add my principal (kerberos user name mwyser@...) to the allowed roles in web.xml, restart tomcat. Now, I get 404 Edit.jsp not available (it would have been accessed!). Put back Edit.jsp without tomcat restart, now it works (with principal in roles).

Somehow, the "Authenticated" role was not attached when I logged in, or it was not honored.

Did you go through ChecklistForContainerManagedAuthentication?

-- JanneJalkanen

Not yet, I'll read it at once. I have some questions in this context, though:

  • How are the grants in the policy file related to the security constraints in web.xml? Are they redundant?
  • http://doc.jspwiki.org/2.4/wiki/Security says that for container-managed authentication the WebContainerLoginModule first tries to "log in" by sniffing the Principal from the HTTP request. If it's there, we use it and add ... two Role Principals: "All" and "Authenticated". Later it says that <you should keep the WebContainerLoginModule line ... because it will just no-op.. Does it no-op or add? Can I match the added roles in the policy file only, or in web.xml only?
  • It looks like jspwiki only makes the "Edit Page" link when I have the right to edit. But then, when I click it shouldn't it succeed, always?

On the whole, I like the concept very much, especially the fact that authentication can come from the container (I just attach to our AD Kerberos, voila), also the separtion of authentication, authorization (I allow edit to all authenticated users, knowing who it was will keep them from malicious action), and access control delegated to page authors (who can restrict sensitive material).

-- martin dot wyser at inf dot ethz dot ch

I have managed to get it to run, but first some remarks on the checklist:

  • points 1 and 2 insist on http and ssl on ports 80 and 443. This is irrelevant, of course, both the actual port number and the set of protocols.
  • point 4 warns against JAASRealm. But the webapp cannot really tell if JAAS or whatever else is in use. And of course, the author cannot know if the installation default is ok, it is not, in fact for me. This also makes points 7 and 8 invalid.
  • point 6.1 is trivial (the file is created), point 6.2 is wrong (I don't use tomcat-users.xml)
  • point 12 is not needed, the policiy file is loaded by jspwiki from its default location.
  • some other points are trivially established in the default installation of jspwiki, or documented in the jspwiki docs anyway.

On the whole, the checklist was no help.

My problem was that the Authenticated role in the web.xml is not matched by the Authenticated role attached be the WebContainerLoginModule. In fact, those roles never make it to a point where they are matched by a call to isUserInRole.

To get around this, I wrote a JAAS module which attaches such a role, and use it with the KerberosLoginModule in the global JAAS configuration.

I ended up wondering why jspwiki uses a nested JAAS login - everything so added must be already there or it won't work anyway.

-- martin dot wyser at inf dot ethz dot ch

Policy file is used when jspwiki.security=jaas; web.xml is used when jspwiki.security=off.

Let me clarify this: this is the heart of the bug?

My problem was that the Authenticated role in the web.xml is not matched by the Authenticated role attached be the WebContainerLoginModule. In fact, those roles never make it to a point where they are matched by a call to isUserInRole.

AndrewJaquith, can you take a look?

-- JanneJalkanen, 24-Sep-2006


It is going to be hard to help you until we receive a little more information.

First, I do not understand what you mean by this statement: "My problem was that the Authenticated role in the web.xml is not matched by the Authenticated role attached be the WebContainerLoginModule. In fact, those roles never make it to a point where they are matched by a call to isUserInRole."

What are "those roles"? And what do you mean by "matched by a call to isUserInRole"?

Here is what happens during the login process when container-managed authentication is used. By default, the JAAS configuration causes WebContainerLoginModule to execute first, then CookieAssertionLoginModule, then AnonymousLoginModule. The first one to succeed wins.

WebContainerLoginModule works as follows. If the HTTP request returns a non-null result from getUserPrincipal() or getRemoteUser(), the user is considered authenticated. We add the user Principal to the Subject, or create a synthetic Principal and add it. Then, we add Role principals for the roles "All" and "Authenticated." So -- in summary -- successful container authentication will cause three Principals to be added to the Subject.

ALSO -- if the user authenticates *and* the current Authorizer is a WebAuthorizer (by default, JSPWiki uses the WebContainerAuthorizer), we attempt to inject additional Role principals into the user's subject. These correspond to container roles the user belongs to. For example, if a call to request.isUserInRole("Admin") returns true, we inject a Principal of type Role called "Admin." The way we determine which principals to inject is by iterating through the roles listed in web.xml and testing each one for the current user. Thus, when WebContainerAuthorizer finishes the user's Subject will have the three Principals I mentioned earlier, plus Role principals for each container role.

Here's something that might help you troubleshoot. In order for the correct container Roles to be injected, two conditions must hold true:

  1. the container role must be properly declared in web.xml, either as roles named in an <auth-constraint> element or security-role/role-name element
  2. the container must appropriately return true when isUserInRole is called for a particular user and role

What's complicating matters here, I suspect, is the Kerberos login module you're using. I do not think that the Kerberos module, when used with Tomcat, will return any role principals. Which means that no Kerberos-authenticated user would ever possess any of the roles in web.xml. I do not think this is the root cause of the problem, but I wanted to mention in it anyway.

If you want to validate that the authenticated user and role principals are added to the user's Subject, turn on security debugging in jspwiki.properties and set the level to DEBUG.

On a separate note, I was puzzled by this comment:

"I ended up wondering why jspwiki uses a nested JAAS login - everything so added must be already there or it won't work anyway."

I do not understand what you mean by a "nested JAAS login." I also do not see any particular problem with requiring that certain modules, such as WebContainerLoginModule, be present -- if that's what you meant. Is that contributing to your problem or are you simply commenting that you'd prefer we did things differently?

Happy to help you figure this out. At this point it's hard to understand what the root cause is -- the debugging flag should help you pinpoint the problem.

--Andrew Jaquith, 25-Sep-2006

Hi Andrew, sorry for the late reply.

What I mean is that the roles in web.xml are of types described by the realm definition in tomcats server.conf, in my case:

<Realm className="org.apache.catalina.realm.JAASRealm"

The roles attached by JSPWiki are of type com.ecyrd.jspwiki.auth.authorize.Role (or com.ecyrd.jspwiki.auth.GroupPrincipal if defined in a group). These are matched in the policy file, but not in the web.xml. You see that I use a JAAS realm, so tomcat makes a Subject, and the "isUserInRole" is the servlet apis HttpServletRequest.isUserInRole() method which checks against this Subject. This Subject instance, however, is not given to JSPWiki (not by the servlet api, anyway, as far as I can see, but tomcat may offer extra API here, which quite certainly JSPWiki does not use, and I don't run it priviledged anyway).

Given this, JSPWiki must have a Subject instance of its own, and that is not accessed by isUserInRole() by the container, so web.xml asks for Authenticated, the com.ecyrd.jspwiki.auth.authorize.Role "Authenticated" cannot be matched.

I solved these problems by writing a bunch of JAAS modules to attach what I want, and configured them into the containers JAAS conf - that is the reason for the strange package names for user and role objects.

With nested JAAS login, I mean that the container will login the user using JAAS, and only after that will JSPWiki get to use JAAS. In fact, I have turned on single sign on in tomcat, so the user can login outside of JSPWiki (e.g. on a protected html-page in the default servlet), and later visit the wiki, and gets immediately accepted. Obviously, something must now happen because the JAAS modules of JSPWiki have not run yet.

That said, I solved my problems, but I am not so happy with it.

--Martin, 25.01.2007

Although the bug reporter didn't get exactly what he wanted, I think we can consider this "bug" as closed.


Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-14) was last changed on 02-Mar-2007 00:48 by HarryMetske