When in doubt, start by reading the Security 2.3 documentation, if that fails you try asking here

If you are using JSPWiki 2.4.7 and higher, check out the diagnostic page admin/SecurityConfig.jsp. It runs a short series of tests and verifies that the security configuration is sound.

This page needs refactoring;
It shouldn't be used to debug environment specific problems with forum-style discussions.

Table of Contents


Could not configure Install.jsp and Could not save profile#

I have installed JSPWiki in JBoss and use MS SQL Server 2000 Database. I configured all the properties for jdbc provider also. When I run the Install.jsp file and click configure it is showing no admin account. My database is getting initialized and the connection is getting closed by the CachedConnectionManager. Also i get that the connection handle has been closed and is unusable when i try to save a profile. Please help me out at the earliest.

--yesesnono, 19-Jul-2007


Problem creating user profile after install. #

You may get the problem that "Create User Profile" fails with the error: Could not save profile: You must log in before creating a profile. Login name cannot be null. (At least with default install of JSPWiki-2.4.15-beta under default install of apache-tomcat-5.5.17 under linux).

It seems this is caused by the default value of the line jspwiki.security in <tomcat>/webapps/JSPWiki/WEB-INF/jspwiki.properties being set to "container". Changing "jspwiki.security = container" to "jspwiki.security = jaas" and restarting Tomcat fixes this and lets you create the user profile. The solution was pointed out by Alex Reid in BugSecurity

- Karsten Breivik


What bearing does the material on Authorization And Authentication HOWTO have on the 2.3.x branch auth?#

Not much. Some of the concepts are still respected, but the implementation in 2.3 is rather different. The material on that page is relevent only to the 2.2.x branch. The documentation on the Security 2.3 page is much more up-to-date and comprehensive.

That said, the key differences between 2.2 and 2.3 include:

  • Persistent user profiles: more than just "user name" cookies. JSPWiki 2.3 allows users to self-register and save personal profiles with their name, password and wiki name. An XML-based user database is provided by default, but JSPWiki also ships with a JDBC-based user database. Earlier versions of JSPWiki supported user cookies only for authentication, and did not support password-based authentication.
  • Customized security policies. Out of the box, JSPWiki allows anonymous users to create and edit wiki pages. But the security policy can be locked down to be much more restrictive. In versions prior to 2.3, security assumptions were hard-coded into the JSPs. Now, they are fully configurable.
  • Out-of-the-box support for container-managed authentication and authorization. It isn't on by default, but can be enabled by just uncommenting a few security constraints in web.xml. Either method of authentication (JSPWiki's own custom method, or container-managed) is supported interchangeably.

How do you designate one or more users to be Administrators?#

anyone? Is this via jspwiki.properties, or vial web.xml or something else? I'm guessing web.xml?

See the Security 2.3 Howto page for details on how to do this.


What are the primary bits and pieces that I a Wiki admin will need to know and love?#

Hmm not including your container managed bits you have: jspwiki.properties of course, jspwiki.policy and maybe web.xml (which is sorta containerish), anything else?


Where is the default UserDatabase when running JSPWiki out of the box ?#

According to Security 2.3 the default user database is an XML file in the /WEB-INF directory. This seems to be ok and gets updated when I register new users. However, the jspwiki.properties has a line
jspwiki.xmlUserDatabaseFile = /etc/tomcat/userdatabase.xml
Which one to believe ? (running v2.3.39) --DF

You should believe the one containing the most up-to-date user information. :) The jspwiki.properties line you mentioned is a "suggested" default setting for a typical deployment. But if you are using JSPWiki out of the box, it will still work fine because JSPWiki will try to find /etc/tomcat/userdatabase.xml, and having failed to do so, will initialize the one in WEB-INF. You can see messages to this effect in the jspwiki log file. In the future, we should probably comment out the jspwiki.properties line so that it is clear that it's a suggested setting, not one that's actually active. --Andrew Jaquith

Indeed, the ~xmlUserDatabaseFile seems now to be read properly (v2.3.41) FYI - do not remove the jspwiki.xmlUserDatabasefile =... line from your properties file - it makes your JSPWiki crash. --DF

This has been fixed in 2.3.48. --Andrew Jaquith

Note that it is a bad idea to keep a user database or any data that changes over time in WEB-INF: This will likely be deleted when the webapplication is updated (e.g. when a newer .war-file is deployed. --OlafKock


How a can I have users logged in for 1 month ie users to remain logged in for 1 month (from the same machine) even after they’ve closed the window or turned off their machine?#

No, not exactly. But there is something in the 2.3 branches that is essentially a 'username' cookie, which is is set in your browser. Because it is a cookie, it will survive system restarts. It works sort of like a login in the sense that it gives users a name that they can use to write web pages and so forth. On 2.2 builds, and on 2.3.48 and higher, you set the user name via UserPreferences.jsp.

There are two caveats to this, though, and you need to be aware of them.

First, the cookie-setting algorithm is ridiculously simple-minded, and contains no obfuscation of any type. It just puts the user name string into a cookie. I haven't bothered trying to do anything tricker than that, because frankly doesn't matter what algorithm we use to generate the cookie -- it's always going to be insecure. Thus, it is offers no protection against identity spoofing. Somebody could easily set the cookie name to "John Doe" and become him, as far as the website is concerned.

Second, setting the user cookie as described (which makes the user "asserted") is considered to be a type of authentication that is different from, and weaker than, a password-style login ("authenticated"). There's a slightly different security policy for each case. If you haven't already, you should read the Security 2.3 wiki page on jspwiki.org, particularly the "Customizing the Security Policy" section. That should give you an idea of how to customize the policy so that asserted users have the same rights as authenticated users.

If you're fine with these two caveats -- because you've got a simple departmental wiki, for example -- then using cookies would be the way to do what you're asking for. But if you are using the wiki company-wide, or on an Internet-facing website, the best way to preserve the integrity of user sessions is via a standard password login. --Andrew Jaquith


Is it easy and maintainable to plug in your own authorization module?#

On our site we run several services using different software. It is essential to have a single-sign-on. We can not use the Tomcat realms, because they seem to be able to manage only page access, but not differentiated content access (users have different rights to records, similar to ACL for wiki pages).

Currently we have modified JSPWiki 2.2 to use our authentication system, but it is rather difficult and makes it very laborious to follow the version updates.

My wish: make it really easy to plugin your own authentication interface, preferable in a form that does not require a recompile of the JSPWiki code. Make sure that a stable interface is defined. Do not rely on a JDBC connection that is able to read the password - even admins can not read users passwords on our system (otherwise we would need to warn users NOT to use a password they may have used anywhere else... - JSPWiki 2.3 should consider doing this, else the system is rather dangerous!).

Maybe all this is already there, I cannot test it. Can you verify/comment this for us? Many thanks! -- Gregor Hagedorn

Gregor --- please read the 2.3 docs first to see if it does that will do what you want. It should, since the authentication system is totally pluggable, and is based on a Java-standard API --- JAAS. However, I don't think you will really need to even customize the authentication scheme. You should be able to use container-managed authentication to establish who the user is by plugging Tomcat in to an LDAP server or JDBC database... just use their realm support, and turn on the single sign-on (SSO) feature to share cookies between webapps.

Now, as to the subject of what the user can do after authentication, if you are using container-managed authentication you can also use externally defined groups (such as those in LDAP or a database) to establish group membership (accounting, IT, sales, etc.) Then, you simply add access control lists (ACLs) to each page that specify which of those groups can access the page. If you want to set a default security policy for *all* pages or ranges of pages, too, that's also possible. The policy file is a standard Java policy file, so that should be pretty straightforward to customize. But that's it. A few config files to fiddle with, but no code to write --- and it should hook into your web container security and enterprise realms without any difficulty at all.

I think the 2.3 release will answer all of your questions. Like you, I'd rather configure the security from a policy point of view, rather than have to write code. I'm an enterprise guy myself, and while writing the security system for 2.3 I wanted to make sure that it integrated cleanly and elegantly into coporate settings. Personally, I think it's been an astounding triumph from a design point of view. After you get your head around it I think you'll really like it. --Andrew Jaquith


What happened to strictLogins? #

It used to be defined in the jspwiki.properties file. What I want to do is restrict access to all pages. If I include a link in an email for example, I want the user to login and then redirect back to the page in the link. For example http://my.wiki.com/wiki/FooBar

In Wiki.jsp, if strictLogins is true, then

response.sendRedirect( wikiContext.getURL( WikiContext.LOGIN, pageurl ) );

Which leads to requests for /wiki/FooBar redirecting to Login.jsp?page=FooBar. When the user logins, they will be redirected by to /wiki/FooBar.

Without strictLogins, Wiki.jsp just redirects to /wiki/LoginError, which currently is not created. I can create that page, but the user is not redirected back to the original link from the emai.

Please tell me where to define strictLogins = true. Thanks

-- MikeWall

Mike, the default security policy in JSPWiki 2.3 is to allow read and edit access to all pages and to all users. That's done so that folks can get JSPWiki working quickly. But clearly, most production instances will need something stricter. Thus, we've made is possible for adminstrators to define a custom security policy that makes page access as tight (or as loose) as you need. The default policy is /WEB-INF/jspwiki.policy. It's just a standard J2SE policy file with some special permissions for JSPWiki. See the Security 2.3 page, specifically the "Modifying the Default Security Policy" section for details. That page, and the comments in the policy file, should give you all the information you need.

Here are some sample policy blocks from jspwiki.properties that force users to log in for any pages other than the front page (Main):

grant signedBy "jspwiki" 
  principal com.ecyrd.jspwiki.auth.authorize.Role "Anonymous" {
    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Main", "view";
};

grant signedBy "jspwiki"
  principal com.ecyrd.jspwiki.auth.authorize.Role "Asserted" {
	permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Main", "view";
};

Thanks to Mike Wall for asking the question (and posting his sample policy). --Andrew Jaquith


When users try to access a page directly that they don't have rights to, I want them to be redirected to the login page, then back again after login. How do I do this?#

All my permission and authentication is working as I want. Only users who login can access or edit pages. My problem is the redirect when a user goes to directly to a page, they are redirected to LoginError. In order for the redirect to work, instead of going to LoginError, they should be redirected to Login.jsp, then (after login) to the correct page. For example, If I type in http://my.wiki.com/wiki/Login.jsp?page=FooBar, the login redirects back to the right page. This is the functionality I want. -- MikeWall

I agree, this is what should happen. JSPWiki 2.3 alpha builds 2.3.56 and higher now exhibit the behavior you describe. Thanks! --Andrew Jaquith


How do I make authentication work when using JSPWiki 2.3 with JBoss? #

What's happening is that I'm getting an error at the point where wiki is trying to validate me as a user, even just as an asserted user. (i.e. using cookies). Consequence is I can't even get asserted user status.

Here is a clip from the log:

2005-12-16 11:42:36,713 INFO  [com.ecyrd.jspwiki.WikiEngine] WikiEngine
configured.
2005-12-16 11:42:36,713 INFO  [com.ecyrd.jspwiki.WikiEngine] Root path
for this Wiki is:
'C:\Tools\Java\jboss-4.0.3SP1\server\test\.\deploy\wiki.war\'
2005-12-16 11:42:36,873 DEBUG [com.ecyrd.jspwiki.WikiEngine] Servlet
path is: /Wiki.jsp
2005-12-16 11:42:36,873 DEBUG [com.ecyrd.jspwiki.WikiEngine] Mapped to null
2005-12-16 11:42:36,873 DEBUG [com.ecyrd.jspwiki.WikiSession] Looking up
WikiSession for session ID=34294E40F8AB25A7E5A4019DC0995D1F... not
found. Creating guestSession()
2005-12-16 11:42:36,873 DEBUG [com.ecyrd.jspwiki.WikiContext] Creating
WikiContext for session ID=34294E40F8AB25A7E5A4019DC0995D1F; page=Main
2005-12-16 11:42:36,873 DEBUG [com.ecyrd.jspwiki.WikiContext] Do we need
to log the user in? true
2005-12-16 11:42:36,883 DEBUG [com.ecyrd.jspwiki.WikiSession] Looking up
WikiSession for session ID=34294E40F8AB25A7E5A4019DC0995D1F... found it
2005-12-16 11:42:36,993 ERROR
[com.ecyrd.jspwiki.auth.AuthenticationManager] Couldn't log in.
Message=CallbackHandler does not support:
javax.security.auth.callback.NameCallback@731e90
Any clues why I'm getting this error?

Milt -- JSPWiki uses a JAAS-based login scheme to manage user identities. This is true regardless of whether you use the standard "custom" authentication or container-managed. The way it does this is by loading a JAAS login configuration at startup time.

JBoss does something like this, too, and based on my look at their code base it's preventing JSPWiki from loading its own login configuration. This is confirmed by the message from the log, which is telling you JSPWiki's JAAS login process isn't able to find a suitable 'CallbackHandler', which in turn suggests that it doesn't know how to find the application config entry.

Fortunately, there's a pretty easy solution to this: you just need to provide JBoss with a JAAS configuration that JBoss can load and make available for JSPWiki to use. This is made slightly more complicated by the fact that JBoss uses its own custom, XML-based configuration format... but only slightly more so. (It also *completely* re-implements JAAS, but that's another story entirely.)

Here's what you need to do. The JBoss JAAS configuration file is in server/*/conf/, and is called login-config.xml. You need to transform the "normal" J2SE JAAS login-config format into JBoss own format, and add this into the file. Here's what the relevant config bits from jspwiki.jaas look like:

JSPWiki-container {
  com.ecyrd.jspwiki.auth.login.WebContainerLoginModule    SUFFICIENT;
  com.ecyrd.jspwiki.auth.login.CookieAssertionLoginModule SUFFICIENT;
  com.ecyrd.jspwiki.auth.login.AnonymousLoginModule       SUFFICIENT;
};

JSPWiki-custom {
  com.ecyrd.jspwiki.auth.login.UserDatabaseLoginModule    REQUIRED;
};

The equivalent in JBoss' syntax is this:

    <application-policy name="JSPWiki-container">
      <authentication>
        <login-module code="com.ecyrd.jspwiki.auth.login.WebContainerLoginModule"
          flag="sufficient"/>
        <login-module code="com.ecyrd.jspwiki.auth.login.CookieAssertionLoginModule"
          flag="sufficient"/>
        <login-module code="com.ecyrd.jspwiki.auth.login.AnonymousLoginModule"
          flag="sufficient"/>
      </authentication>
    </application-policy>

    <application-policy name="JSPWiki-custom">
      <authentication>
        <login-module code="com.ecyrd.jspwiki.auth.login.UserDatabaseLoginModule"
          flag="required"/>
      </authentication>
    </application-policy>

Add this to your server/default/conf/login-config.xml file. It will work on 4.0.3SP1, and it should work on everything later than 3.2 also.

Unfortunately this means that JBoss will always be a bit of a special case. That kind of stinks, but it's inevitable seeing how it uses a very non-standard JAAS implementation. Fortunately, the fix is very simple. --Andrew Jaquith

Will there be a way to specify files like jspwiki.jaas, jspwiki.policy, and userdatabase.xml as context parameters like there is for jspwiki.properties currently?#

Using the multiple-wikis-on-one-war-file method, you'd need this ability in order to support multiple wikis with independent security configurations. Post or e-mail me: {gmishkin}{at}{bu}{dot}{edu}

Hi -- at the moment multiple wikis are partially supported. The JAAS and J2SE policy files (jspwiki.jaas and jspwiki.policy) are applied JVM-wide: thus, if you are using multiple wikis, you will need to make sure the settings in these files contain everything you'd need for all wiki contexts in your container. That is less difficult than you might imagine. For jspwiki.jaas, the configurations apply equally across all wiki contexts; thus, you can't customize the login settings on a per-wiki basis. If that's a showstopper, create a Bug Report and we will address it in an upcoming release. For the policy files, the policy grammar for the various permissions accept a "wiki" parameter that specifies what wikis the permission applies to. For example, PagePermission "MyWiki:*" "edit" grants edit rights to all pages, but only for the "MyWiki" wiki. The wiki parameter corresponds precisely to the jspwiki.applicationName property in jspwiki.properties. The default user database implementation (userdatabase.xml), of course, can be shared between wikis if desired, or maintained separately. The location of the XML database is a standard setting in jspwiki.properties. -- Andrew Jaquith

If the files are applied JVM-wide, why do they live in WEB-INF? Wouldn't that make them only apply to that wiki (or rather, any context that points to that war file)? -- Geoff

Ease of deployment. We provide some sample JAAS and J2SE policy files as part of the stock JSPWiki distribution. Our default strategy is to try to install a JAAS configuration and supplemental J2SE policy if we detect that the user hasn't set them up already. We do this so that the administrator doesn't have to fool around with config files, and that it runs out of the box. On a multi-wiki system or one that's used in production, of course, we recommend setting the location of the JAAS and J2SE files manually so that they run JVM-wide. -- Andrew Jaquith

How do I create wiki groups?#

Wow Security2.3 is mouthful. Could someone digest this and create a howto for the following... I'm sorry but I've been using 2.2.33 all along and it's first experience with. Want to create some users and give the ability to do everything they wish unless explicity denied as part of an wiki tag on a page. The rest are anonymous and can only browse around. GWP

See the Security 2.3 Howto for an example of how to create wiki groups.

Do we need JAR signing?#

Hi, I'm digging further into getting up JSPWiki's container managed security. I stumbled over the grant signedBy "jspwiki" entries in jspwiki.policy. What good is the signedby grant for?

From Security 2.3:

Note: the signedBy "jspwiki" section of the "grant" block ensures
that calling code is signed and trusted. If you customize the default
policy, we highly recommend that you include this statement in all
"grant" blocks.

I think the grant is unnessary. JSPWiki is installed by the sysadmin in control of the web container and by no-one else, and he knows that the code is safe. At least, signing code is as easy as re-building JSPWiki. If you want to be sure that the download hasn't been tampered with, the way to go is signing the download-jar alltogether and you can check the download once, but it is not necessary to continually check at runtime. It only makes the build process harder and the code run slower. -- Jürgen Weber

Hi Jürgen -- while I agree with you that for purposes of trust we need not sign the jars, that is not why we are doing it. It turns out that Java requires a signed jar when the jar contains non-standard Permission types that are specified in a Java security policy.

In JSPWiki, we have defined two custom Permission types: PagePermission and WikiPermission. These are specified in the policy, and in order for Java to load them it needs these classes to be signed. Otherwise, it will treat the permission grants as being of type UnresolvedPermission, whose implies() method always returns false. That would cause JSPWiki to "fail closed" -- good from a security point of view, but bad for users because it would mean no access for anyone!

This requirement is not documented as far as I can tell -- I found it only by inspecting Sun's source code.

From a performance perspective, jar signing doesn't really hurt us too much -- there is the initial signature check done by the Java classloader when the jar contents are first loaded, but after that it's business as usual.

Also, I'd like to think that we've automated the build process pretty well, and have made the keystore generation and signing processes fairly painless. If you've got suggestions on how to improve it further, I'm all ears. -- Andrew Jaquith

How Do I Restrict Anonymous Users from Accessing Pages?#

We would need to be able to disallow access for any not authorized user per default. and also need control about the users wanting to create a new account. --Domi, 16-Jan-2006

Please read the Security 2.3 page. You can restrict access to all pages, or just some of them, by modifying the default security policy. In addition, you can prevent users from creating accounts. These are standard features of the 2.3 builds. -- Andrew Jaquith

Downloaded 2.3.72, installed, but every page demands I login, even to view pages!#

I thought by default access was open, like in 2.2. e.g. I go to localhost:8080/wiki, and it says:

Could not log in: You don't have access to 'Main'. Log in first.

Why would that be? The Security 2.3 page says otherwise

Logs say:

2006-03-22 12:51:40,421 [resin-tcp-connection-*:8080-1] INFO com.ecyrd.jspwiki.auth.AuthenticationManager  - JAAS not configured. Installing default configuration: file:/D:/resin/webapps/wiki/WEB-INF/jspwiki.jaas. You can set the java.security.auth.login.config system property to point to your jspwiki.jaas file, or add the entries from jspwiki.jaas to your own JAAS configuration file.
2006-03-22 12:51:40,468 [resin-tcp-connection-*:8080-1] INFO com.ecyrd.jspwiki.auth.AuthenticationManager  - Security policy not configured. Installing default policy: file:/D:/resin/webapps/wiki/WEB-INF/jspwiki.policy. Please set the java.security.policy system property, if you're not happy with the default.
2006-03-22 12:51:40,468 [resin-tcp-connection-*:8080-1] ERROR com.ecyrd.jspwiki.auth.AuthenticationManager  - Could not install security policy: Policy implementation must be of type sun.security.provider.PolicyFile.

Maybe that last error was the cause?

I'm just dropping the war in resin/webapps, renaming it to wiki.war, and plopping the sample .txt pages where they belong. Not exactly a custom install.

Hmmmm, just tried on Tomcat 5.5.15, works fine. Looks like there is something with Resin 3.x that makes it ill.

That's annoying, as we use Resin, not Tomcat.

--DinoFancellu

Yep, the last error message is the root cause. We've got some assumptions in the code about the availability of certain Sun classes. I'm betting you aren't using the Sun JDK, right? Or does Resin substitute its own Policy implementation? We will need to fix this--could you file a bug report, if you haven't already? Thanks. --Andrew Jaquith, 28 March 2005

Has been logged with Caucho, they have seen it and marked as high. http://bugs.caucho.com/view.php?id=1008 --DinoFancellu

Dino -- 2.3.91 is checked in. I've removed all of the dependencies on PolicyFile. So there is a decent chance the current nightly build will work on Resin. Please test this version, if you can. -- Andrew Jaquith, 29 March 2005

Tried 2.3.91, no difference.

Download Resin 3.x yourself, its very easy, just download, stick war under resin/webapps, startup, access localhost:8080/JSPWiki.

--DinoFancellu

Please file a bug report so we can track this. Based on my examination of the Resin source, it looks like they are doing something naughty by resetting the security policy, regardless of what our settings are. We're going to have to coordinate a fix with the Resin folks. --Andrew Jaquith


Is there a way to hide LeftMenu?#

Navigation LeftMenu on the side is shown regardless of page authorization settings that are described in Security 2.3. Is there a way to hide it? Or, in general, is there a simple and quick way redirecting user to the dedicated login page and not one showing all the my prefs, search and other stuff?

Upd. I replaced "ViewTemplate.jsp" with "LoginContent.jsp" inside LoginForm.jsp in my installation. This works but for sure this is bad way because requires forcing things in LoginContent.jsp and this breaks templating. As well, login pages are special in the sense that if I force /* in container authorization, all referenced stuff is broken. Probably login flow requires more design attention, including V Remember me checkbox and other stuff.
Thanks,

--Fedor Losev, 29-Mar-2006

I too would like to do this. From a usability standpoint I'd like not to present the user with numerous options they can't use.

--Ian Brandt, 3-May-2006

The current system is designed for the case where you are protecting only some of the pages for writing purposes. If you are requiring login to access the entire wiki, then, well... Hm. I always figured people would use web.xml for that kind of protection.

-- JanneJalkanen


Global Group authorization not working#

Sorry, the following is rather lenghty, I promise to strip it down, or to put it somewhere else more relevant, or edit a bug report if relevant, once I get to undertsand what fails exactly...

I couldn't get my Wiki (using jspWiki v2.3.72.alpha) to restrict access to a subset of pages to only to a restricted Group. Indeed as soon as I put a GroupPrincipal type, my Wiki starts behaving strangely (requesting login for all pages, or refusing to serve even authenticated users, let me know if more details are needed).

I used only JSP Wiki security settings, no conyainer stuff there, and I dont want to specify theaccess list in all the target pages subject to these access restrictions. I expected to be able to specify this global policy in jspwiki.policy.

My current jspwiki.policy configuration looks like:

// Guests can only view pages and create a profile
grant signedBy "jspwiki" 
  principal com.ecyrd.jspwiki.auth.authorize.Role "Anonymous" {
    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:*", "view";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "createPages";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "editPreferences";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "editProfile";
};


// Assetrted users can only view pages and create a profile
grant signedBy "jspwiki"
  principal com.ecyrd.jspwiki.auth.authorize.Role "Asserted" {
    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:*", "view";
    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Group*", "view";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "createPages";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "editPreferences";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "editProfile";
};


// Authenticated users can do most things: view, create, edit and 
// comment on all pages; upload files to existing ones; create and edit
// wiki groups; and rename existing pages. Authenticated users can register
// with the wiki, and edit their own profiles.

grant signedBy "jspwiki" 
  principal com.ecyrd.jspwiki.auth.authorize.Role "Authenticated" {
//    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:*", "edit,rename";
    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Group*", "edit";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "createPages,createGroups";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "editPreferences";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "editProfile";
};

// Only the Project group (members of GroupProject) can edit page TestAccessA
grant signedBy "jspwiki" 
  principal com.ecyrd.jspwiki.auth.GroupPrincipal "Project" {
    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:TestAccessA", "edit,rename";
    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Group*", "edit";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "createPages,createGroups";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "editPreferences";
    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "editProfile";
};

If I remove the last block, my Wiki works as expected (only registered users can edit pages, but anyone can create a profile and become a registered user...).

How to lock the list of registered users#

(JspWiki v2.3.72-alpha within Tomcat5.5, on Windows)

I want to set up my access policy such that anyone can read all pages of my wiki, but only authenticated users can edit them. Furthermore, I don't want anyone to set up a profile and become an autheticated user, outside of a list I manually administer. Also, I don't want to have to specify an ACL in all pages.

As I couldn't get GroupPrincipal security policy to work (see question above), I thought about simply allowing read rights to Anonymous role, and all other rights to Authenticated role, and I then tried a couple of ways to lock the list of registered users:

  • Set file userdatabase.xml to read-only. Doesn't work, JSPWiki creates a backup copy, remove the original, and creates a new one. Even if it worked, it would prevent users from changing their password.
  • Remove UserPreference.jsp. Works somehow, anonymous users cannot create a profile, and pre-entered users can still login, but they can't edit their preferences and profile (e.g. change password).

Any idea?

-- JDuprez 19.05.2006 Eventually I edited out the JSP: in the default template, it was in templates/default/PreferencesContent.jsp. I replaced the free text fields for fixed menus (html's <select><option.../>). This is not bullet proof (one can always send a URL edited by hand), but with hardly more work it is probably easy to check the list in UserPreference.jsp (N.B.: see WhyHavingLogicInJSPWikiJspsIsNotSoEvil)//

Eventually, I'd like to have this user list management built into some SecurityAdministration future functionality. There are a bunch of related questions already on this site.


Installed v2.4.0-beta, but every page requires that I login.#

I'm using Java 1.5.0_06 and Tomcat 5.0.27, and when I try to access the Main page, I get the error:

Error: You don't have access to 'Main'. Please log in first.

The jspwiki.log says:

2006-04-27 14:20:24,076 [http-30081-Processor4] INFO SecurityLog JSPWiki:http://localhost:30081/SFAWiki/ - WikiSecurityEvent.ACCESS_DENIED [source=com.ecyrd.jspwiki.auth.AuthorizationManager@9875d1, princpal=[WikiPrincipal (unspecified): 127.0.0.1], target=("com.ecyrd.jspwiki.auth.permissions.PagePermission","JSPWiki:Main","view")]
2006-04-27 14:20:24,076 [http-30081-Processor4] INFO com.ecyrd.jspwiki.WikiContext JSPWiki:http://localhost:30081/SFAWiki/ - User 127.0.0.1 has no access - redirecting (permission=("com.ecyrd.jspwiki.auth.permissions.PagePermission","JSPWiki:Main","view"))
2006-04-27 14:20:25,157 [http-30081-Processor4] INFO SecurityLog JSPWiki:http://localhost:30081/SFAWiki/Login.jsp - WikiSecurityEvent.ACCESS_DENIED [source=com.ecyrd.jspwiki.auth.AuthorizationManager@9875d1, princpal=[WikiPrincipal (unspecified): 127.0.0.1], target=("com.ecyrd.jspwiki.auth.permissions.WikiPermission","JSPWiki","creategroups")]
2006-04-27 14:20:28,041 [http-30081-Processor4] INFO SecurityLog JSPWiki:http://localhost:30081/SFAWiki/Login.jsp - WikiSecurityEvent.ACCESS_DENIED [source=com.ecyrd.jspwiki.auth.AuthorizationManager@9875d1, princpal=[WikiPrincipal (unspecified): 127.0.0.1], target=("com.ecyrd.jspwiki.auth.permissions.WikiPermission","JSPWiki","creategroups")]
2006-04-27 14:20:28,802 [http-30081-Processor4] INFO SecurityLog JSPWiki:http://localhost:30081/SFAWiki/Login.jsp - WikiSecurityEvent.ACCESS_DENIED [source=com.ecyrd.jspwiki.auth.AuthorizationManager@9875d1, princpal=[WikiPrincipal (unspecified): 127.0.0.1], target=("com.ecyrd.jspwiki.auth.permissions.WikiPermission","JSPWiki","creategroups")]

Any help would be greatly appreciated.

cheers!
matt

--JDuprez Is it a vanilla installation or did you modify the WEB-INF/jspwiki.policy file? Sorry to ask such obvious stuff but I once had similar problems with 2.3.72, when I unwantingly edited out the block which grants access to Anonymous users, which was a wrong setting on my part, but also when I tried to set up a GroupPrincipal-based permission (which I haven't found out yet whether I did something wrong or if it's a bug). Earlier this week I installed a 2.4 with Tomcat 5.5/Java1.5.0_06 on Windows and the vanilla install worked fine, that is, until I ruined my jspwiki.policy...

Thanks for the quick reply. It's a plain vanilla installation - no modifications to the jspwiki.policy file.
matt

--One of the things I've experienced is that you need to make sure there is no other older JSPWiki version running, as a second app, in you TOMCAT server. This seems to make the security system confused. I got similar log file messages as the one you've mentioned so you may want to check. --DF

Nope. No older version of JSPWiki is running, although I did have an older version running a few days ago. I removed the older version completely. I even deleted everything under the Tomcat temp and work directories. Any other ideas? I would really like to use JSPWiki...
matt

Can you please check the messages you get right after the startup? If the jspwiki.jks file is not found in the same directory as your jspwiki.policy, things just won't work. JSPWiki will try to detect some of these problem cases and log them in your log file...

-- JanneJalkanen

I'm having the same problem, upgrading an old wiki to 2.4.6-beta on Tomcat 5.5, Java 5 on Windows. I tried purging my old wiki, no joy.

-Jason

We need a bit more information... There might be quite a few things wrong with it. However, you can still use the new wiki, if you specify "jspwiki.security=container" in your jspwiki.properties. That'll revert back to the 2.2 behaviour.

-- JanneJalkanen

Just to confirm, I've done a vanilla installation of the latest JSPWiki on a Tomcat 5.5 install that's never seen it, and I got this error. The only change I made to the config file after installation was removing the "containter" security line. This is using JDK 1.5.0_05. -- Jason

Believe I've found the problem. On the Security Verifier, I have the message: Error: Certificate with alias 'jspwiki" principal com.ecyrd.jspwiki.auth.GroupPrincipal "Admin' not found in keystore C:\Program Files\Apache Software Foundation\TomcatBuild\webapps\wiki\WEB-INF\jspwiki.jks
When the policy file defines admin and authenticated levels in the same place, and admin fails, they both get DENY permissions for everything (in fact, the table was showing exactly that). If you remove the line that defines Admin above Authenticated, then Authenticated works. -- Jason

Jason, you are actually describing two bugs! There was a bug in the helper class that SecurityVerifier uses to parse the security policy, which resulted in the error you noted. That's fixed in the 2.4.8 build in CVS. The second bug related to the default policy file; there should NOT have been two Principal entries in the grant block (just as you described). As it happens, when Java parses security policy files, any grant blocks that contain more than one principal entry mean "the user must have ALL of these Principals in their Subject" -- rather than ANY of them. That was my mistake, and is also fixed in the latest build. Thanks for helping with this. --Andrew Jaquith

My problem was a bit different. I have a few other applications running in my Tomcat container, so I ended up merging the jspwiki.policy file with my existing catalina.policy file. Then, I moved the jspwiki.jks file to the same directory as my catalina.policy file. It's working well now. Thanks for your ideas and help.
cheers!
matt

Matt -- nice work. That is the right solution. -- Andrew Jaquith


Is there a way of integrating JSPWiki with existing Tomcat Realms (in shared Tomcat instance)?#

I have installed JSPWiki 2.4.0 and I have no problem running it on my own machine (Tomcat 5.5 Java 1.5). I have implemented my own version of the jspwiki.userdatabase (this is working well).

My Hosting Service implements Tomcat Realms with an adminstration module for adding users and roles. When I try to run JSPWiki on their instance of Tomcat I am getting the following error:

java.security.AccessControlException: access denied (java.io.FilePermission =d:\theServersPathTo\jakarta\conf\catalina.policy read);

This occurs after a call to com.ecyrd.jspwiki.auth.PolicyLoader isSecurityPolicyConfigured() which throws SecurityException due to the line:

System.getProperty("java.security.policy"); (returning the path to the server's catalina.policy).

in com.ecyrd.jspwiki.auth.AuthenticationManager the following line:
if (! PolicyLoader.isSecurityPolicyConfigured() ) has no graceful Exception handling, hence b0rked code?:

FATAL com.ecyrd.jspwiki.WikiEngine - Failed to start managers.

Thanks Joe


Problem Customizing Identity Management#

Hi,

  • I am trying to customize the Identity Management by using the JDBCUserDatabase.
  • I am deploying 2.4.6-beat on tomcat 5.5.9
  • I am using container based authentication (see log) --> default jspwiki.jaas file
  • I am using container based authorization (see log) --> default policy file
  • I get the following exception in the JSPWiki log:
2006-05-19 10:56:16,796 [main] INFO com.ecyrd.jspwiki.auth.AuthenticationManager  - Checking JAAS configuration...
2006-05-19 10:56:16,796 [main] INFO com.ecyrd.jspwiki.auth.AuthenticationManager  - JAAS not configured. Installing default configuration: file:/D:/java/tomcat/webapps/JSPWiki/WEB-INF/jspwiki.jaas. You can set the java.security.auth.login.config system property to point to your jspwiki.jaas file, or add the entries from jspwiki.jaas to your own JAAS configuration file.
2006-05-19 10:56:16,812 [main] INFO com.ecyrd.jspwiki.auth.AuthenticationManager  - Checking security policy configuration...
2006-05-19 10:56:16,812 [main] INFO com.ecyrd.jspwiki.auth.AuthenticationManager  - Security policy not configured. Installing default policy: file:/D:/java/tomcat/webapps/JSPWiki/WEB-INF/jspwiki.policy. Please set the java.security.policy system property, if you're not happy with the default.
2006-05-19 10:56:16,859 [main] INFO com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer  - Examining jndi:/localhost/JSPWiki/WEB-INF/web.xml
2006-05-19 10:56:16,859 [main] DEBUG com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer  - Processing web.xml at jndi:/localhost/JSPWiki/WEB-INF/web.xml
2006-05-19 10:56:16,890 [main] DEBUG com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer  - Resolved systemID=http://java.sun.com/dtd/web-app_2_3.dtd using local file jndi:/localhost/JSPWiki/WEB-INF/dtd/web-app_2_3.dtd
2006-05-19 10:56:17,015 [main] INFO com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer  - JSPWiki is using container-managed authentication.
2006-05-19 10:56:17,015 [main] INFO com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer  -  JSPWiki determined the web container manages these roles: [com.ecyrd.jspwiki.auth.authorize.Role: Admin] [com.ecyrd.jspwiki.auth.authorize.Role: Authenticated] 
2006-05-19 10:56:17,015 [main] INFO com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer  - Authorizer WebContainerAuthorizer initialized successfully.

... (cut irrelevant logs) ...

2006-05-19 10:56:17,156 [main] INFO com.ecyrd.jspwiki.auth.UserManager  - Attempting to load user database class com.ecyrd.jspwiki.auth.user.JDBCUserDatabase
2006-05-19 10:56:17,171 [main] ERROR com.ecyrd.jspwiki.auth.user.AbstractUserDatabase  - JDBCUserDatabase initialization error: Cannot create JDBC driver of class '' for connect URL 'null'
2006-05-19 10:56:17,171 [main] ERROR com.ecyrd.jspwiki.auth.UserManager  - You have not set the 'jspwiki.userdatabase'. You need to do this if you want to enable user management by JSPWiki.
  • This is the relevant configuration in jspwiki.properties:

jspwiki.authorizer          = com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer
jspwiki.groupManager        = com.ecyrd.jspwiki.auth.authorize.DefaultGroupManager
jspwiki.userdatabase = com.ecyrd.jspwiki.auth.user.JDBCUserDatabase
jspwiki.userdatabase.isSharedWithContainer = true
jspwiki.aclManager          = com.ecyrd.jspwiki.auth.acl.DefaultAclManager

jspwiki.userdatabase.datasource=jdbc/UserDatabase
jspwiki.userdatabase.table=user_tb
jspwiki.userdatabase.email=user_email
jspwiki.userdatabase.fullName=user_fullname
jspwiki.userdatabase.loginName=user_name
jspwiki.userdatabase.password=user_password
jspwiki.userdatabase.wikiName=user_wikiname
jspwiki.userdatabase.created=created
jspwiki.userdatabase.modified=modified
jspwiki.userdatabase.roleTable=user_role_tb
jspwiki.userdatabase.role=user_role

This is the web.xml configuration:

 <resource-ref>
       <description>
           Resource reference to JNDI factory for the JDBCUserDatabase.
       </description>
       <res-ref-name>
           jdbc/UserDatabase
       </res-ref-name>
       <res-type>
           javax.sql.DataSource
       </res-type>
       <res-auth>
           Container
       </res-auth>
   </resource-ref>


   <security-constraint>
       <web-resource-collection>
           <web-resource-name>Administrative Area</web-resource-name>
           <url-pattern>/admin/SecurityConfig.jsp</url-pattern>
           <url-pattern>/Delete.jsp</url-pattern>
       </web-resource-collection>
       <auth-constraint>
           <role-name>Admin</role-name>
       </auth-constraint>
   
   </security-constraint>
      
   <security-constraint>
       <web-resource-collection>
           <web-resource-name>Authenticated area</web-resource-name>
           <url-pattern>/Edit.jsp</url-pattern>
           <url-pattern>/Comment.jsp</url-pattern>
           <url-pattern>/Login.jsp</url-pattern>
           
           <url-pattern>/NewGroup.jsp</url-pattern>
           <url-pattern>/Rename.jsp</url-pattern>
           <url-pattern>/Upload.jsp</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>GET</http-method>
           <http-method>HEAD</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <web-resource-collection>
           <web-resource-name>Read-only Area</web-resource-name>
           <url-pattern>/attach</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <auth-constraint>
           <role-name>Admin</role-name>
           <role-name>Authenticated</role-name>
       </auth-constraint>

   </security-constraint>

   <login-config>
       <auth-method>FORM</auth-method>
       <form-login-config>
           <form-login-page>/LoginForm.jsp</form-login-page>
           <form-error-page>/LoginForm.jsp</form-error-page>
       </form-login-config>
   </login-config>

   <security-role>
       <description>
           This logical role includes all authenticated users
       </description>
       <role-name>Authenticated</role-name>
   </security-role>

   <security-role>
       <description>
           This logical role includes all administrative users
       </description>
       <role-name>Admin</role-name>
   </security-role>

  • Finally, this is the server.xml configuration of my tomcat:

<GlobalNamingResources>
         <Resource name="jdbc/UserDatabase" auth="Container"
            type="javax.sql.DataSource" username="empuly" password="xxxxxx"
            driverClassName="org.gjt.mm.mysql.Driver" url="jdbc:mysql://localhost/empulyDb"
         />
</GlobalNamingResources>

....

<Engine name="Catalina" defaultHost="localhost">
   <Realm className="org.apache.catalina.realm.DataSourceRealm" debug="99"
          dataSourceName="jdbc/UserDatabase"
          userTable="user_tb" userNameCol="user_name" userCredCol="user_password"
          userRoleTable="user_role_tb" roleNameCol="user_role" />
</Engine>

public void initialize( WikiEngine engine, Properties props ) throws NoRequiredPropertyException
    {
        String jndiName = props.getProperty( PROP_DB_DATASOURCE, DEFAULT_DB_JNDI_NAME );
        try
        {
            Context initCtx = new InitialContext();
            Context ctx = (Context) initCtx.lookup("java:comp/env");
            m_ds = (DataSource) ctx.lookup( jndiName );
            
            // Prepare the SQL selectors
            m_userTable = props.getProperty( PROP_DB_TABLE, DEFAULT_DB_TABLE );
            m_email     = props.getProperty( PROP_DB_EMAIL, DEFAULT_DB_EMAIL );
            m_fullName  = props.getProperty( PROP_DB_FULL_NAME, DEFAULT_DB_FULL_NAME );
            m_hashPrefix = Boolean.valueOf( props.getProperty( PROP_DB_HASH_PREFIX, DEFAULT_DB_HASH_PREFIX ) ).booleanValue();
            m_loginName = props.getProperty( PROP_DB_LOGIN_NAME, DEFAULT_DB_LOGIN_NAME );
            m_password  = props.getProperty( PROP_DB_PASSWORD, DEFAULT_DB_PASSWORD );
            m_wikiName  = props.getProperty( PROP_DB_WIKI_NAME, DEFAULT_DB_WIKI_NAME );
            m_created   = props.getProperty( PROP_DB_CREATED, DEFAULT_DB_CREATED );
            m_modified  = props.getProperty( PROP_DB_MODIFIED, DEFAULT_DB_MODIFIED );

            m_findAll         = "SELECT * FROM " + m_userTable;
            m_findByEmail     = "SELECT * FROM " + m_userTable + " WHERE " + m_email + "=?";
            m_findByFullName  = "SELECT * FROM " + m_userTable + " WHERE " + m_fullName + "=?";
            m_findByLoginName = "SELECT * FROM " + m_userTable + " WHERE " + m_loginName + "=?";
            m_findByWikiName  = "SELECT * FROM " + m_userTable + " WHERE " + m_wikiName + "=?";
            
            // Prepare the user isert/update SQL
            m_insertProfile   = "INSERT INTO " + m_userTable + " ("
                              + m_email + "," 
                              + m_fullName + ","
                              + m_password + ","
                              + m_wikiName + ","
                              + m_modified + ","
                              + m_loginName + ","
                              + m_created
                              + ") VALUES (?,?,?,?,?,?,?)";
            m_updateProfile   = "UPDATE " + m_userTable + " SET "
                              + m_email + "=?,"
                              + m_fullName + "=?,"
                              + m_password + "=?,"
                              + m_wikiName + "=?,"
                              + m_modified + "=? WHERE " + m_loginName + "=?";
            
            // Prepare the role insert SQL
            m_roleTable = props.getProperty( PROP_DB_ROLE_TABLE, DEFAULT_DB_ROLE_TABLE );
            m_role = props.getProperty( PROP_DB_ROLE, DEFAULT_DB_ROLE );
            m_insertRole      = "INSERT INTO " + m_roleTable + " ("
                              + m_loginName + ","
                              + m_role
                              + ") VALUES (?,?)";
            m_findRoles       = "SELECT * FROM " + m_roleTable + " WHERE " + m_loginName + "=?";
            
            // Set the "share users with container flag"
            m_sharedWithContainer = TextUtil.isPositive( props.getProperty( PROP_SHARED_WITH_CONTAINER, "false" ) );
        }
        catch( NamingException e )
        {
            log.error( "JDBCUserDatabase initialization error: " + e.getMessage() );
            throw new NoRequiredPropertyException( PROP_DB_DATASOURCE, "JDBCUserDatabase initialization error: " + e.getMessage() );
        }
        
        // Test connection by doing a quickie select
        try
        {
            Connection conn = m_ds.getConnection();
            PreparedStatement ps = conn.prepareStatement( m_findAll );
            ps.executeQuery();
            conn.close();
        }
        catch ( SQLException e )
        {
            log.error( "JDBCUserDatabase initialization error: " + e.getMessage() );
            throw new NoRequiredPropertyException( PROP_DB_DATASOURCE, "JDBCUserDatabase initialization error: " + e.getMessage() );
        }
        log.info( "JDBCUserDatabase initialized from JNDI DataSource: " + jndiName );
    }

When I change the name of jspwiki.userdatabase.datasource to a non existing resource name, I get another error. This indicates that jspWiki is able to find the datasource via the resource name "jdbc/UserDatabase". I assume "m_ds = (DataSource) ctx.lookup( jndiName );" does not throw an exception. This implies that the exception is thrown when testing the connection. The log line indicates that the driver and url are not filled in. Why is this the case? The datasource works, since authorization and authentication work both via this datasource defined in the container. Anyone any thoughts?

Tnx in advance

Empie


Hi Empie

Your config looks right to me. I'd guess that Tomcat can't find the JAR file. If you haven't done so, put your JDBC driver in $CATALINA_HOME/common/lib. You *might* have to put it in server/lib.

If this doesn't help, try declaring a local JNDI resource inside of your <context> element, and put the JDBC driver in common/lib. It's revealing to me that the container auth seems to work ok, but the UserDatabase doesn't.

If neither of these suggestions work, could you try attaching a debugger to a running Tomcat instance and seeing where the error is generated? If we need to break that (rather long) try/catch block into smaller chunks, we will.

--AnonymousCoward, 23-May-2006


Tnx for the reply. I tried most of the things you suggested. I placed the MySql Connector in all lib directories I could find :-) But nothing helped.

I tried to declare the JNDI resource. Is it enough to place the declaration in the engine section of the server.xml like below? Or is there a way to associate it with the context itself?


<Engine name="Catalina" defaultHost="localhost">
  
 <Resource name="jdbc/UserDatabase" auth="Container"
            type="javax.sql.DataSource" username="empuly" password="xxxxxx"
            driverClassName="org.gjt.mm.mysql.Driver" url="jdbc:mysql://localhost/empulyDb"
         />

 <Realm className="org.apache.catalina.realm.DataSourceRealm" debug="99"
          dataSourceName="jdbc/UserDatabase"
          userTable="user_tb" userNameCol="user_name" userCredCol="user_password"
          userRoleTable="user_role_tb" roleNameCol="user_role" />
</Engine>

In all cases, i get the same error message as before:

2006-05-19 10:56:17,171 [main] ERROR com.ecyrd.jspwiki.auth.user.AbstractUserDatabase  - JDBCUserDatabase initialization error: Cannot create JDBC driver of class '' for connect URL 'null'

Can someone reproduce this problem?

You also suggested to plug in a debugger in tomcat. How can you do this? Is it enough to start tomcat from eclipse for example and use the debugger from eclipse? Any resource on that? Tnx for the help

Empie


I plugged in the debugger in tomcat, loaded the JSPWiki source in eclipse and reloaded the application. I placed a breakpoint in the JDBCUserDatabase Initialize method (code is dsplayed in previous post). The lookup of the datasource in JNDI is where the problem is situated. The lookup itself does not throw an exception however, but the datasource that is returned (of type BasicDataSource --> commons dbcp) is not correctly initialized. In the debugger all the properties like the url, the user, the driver... They are all null. At the end of the Initialize method, when the connection is tested, the sql exception is thrown.

I find it weird that the lookup is not throwing a naming exception or something. It means, I guess, that a datasource is found, but not correctly configured. However, the container managed authorization works. I don't understand it :-(

All help appreciated

Empie


Hi Empie -- your config looks right to me. I'd guess that Tomcat can't find the JAR file. If you haven't done so, put your JDBC driver in $CATALINA_HOME/common/lib. You *might* have to put it in server/lib.

If this doesn't help, try declaring a local JNDI resource inside of your <context> element, and put the JDBC driver in common/lib. It's revealing to me that the container auth seems to work ok, but the UserDatabase doesn't.

If neither of these suggestions work, could you try attaching a debugger to a running Tomcat instance and seeing where the error is generated? If we need to break that (rather long) try/catch block into smaller chunks, we will.

--AnonymousCoward, 23-May-2006


Hi Empie,

I can reproduce your problem with your configuration and figure out the solution.

WRT your resource configuration, you should put it into <Context ...> </Context> instead of $TOMCATHOME/conf/server.xml, and you don't have to define Realm. Then the JNDI lookup in current context can find the resource.

Have a try and good luck!

Bruce Dong @ June 5th, 2006


Empie --

Here is a context file (a config file for a Tomcat webapp) that you can deploy instead of hacking the server.xml file. I recommend you use separate context files instead of editing server.xml. This is a generated file from running ant-webtests from the source build, by the way. It has been tested with Tomcat 5.5.

<Context path="/test-container-jdbc" 
  docBase="tests/build/test-container-jdbc/test-container-jdbc.war">
  <Resource name="jdbc/UserDatabase" auth="Container"
      type="javax.sql.DataSource" 
      driverClassName="org.hsqldb.jdbcDriver"
      url="jdbc:hsqldb:hsql://localhost/jspwiki"
      username="jspwiki" 
      password="password"
      maxActive="20" maxIdle="10" maxWait="-1" />
  <Realm className="org.apache.catalina.realm.DataSourceRealm"
      dataSourceName="jdbc/UserDatabase"
      localDataSource="true"
      digest="SHA" 
      userTable="users"
      userNameCol="login_name"
      userCredCol="password"
      userRoleTable="roles"
      roleNameCol="role" />
</Context>

You should copy this file to your Tomcat conf/Catalina/localhost directory. Notice how both the realm and datasource are configured in the same file. It uses a Hypersonic database, but you can specify whatever you want... just make sure your JDBC jar is in Tomcat's common/lib directory so that Tomcat's connection pooling classes can find the jar.

Hope this helps.

--Andrew Jaquith, 04-Jun-2006


Can I use an Apache Proxy for authentication?#

Tested with JSPWiki 2.4.11
Yes! This setup is common in some corporate intranets. A web server controlled by the IT deparment provides a proxy for your JSPWiki installation, and also takes care of authentication. But this is not a typical installation, so you will have to tweak your configuration. One of the ways to do that is by doing the following:
Enable an AJP connection between your Apache proxy and your Tomcat
On the Tomcat /conf/server.xml file, add:
   <!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector port="8009" 
               enableLookups="false" 
               redirectPort="8443" 
               protocol="AJP/1.3" 
               tomcatAuthentication="false" 
    />
The tomcatAuthentication="false" line is needed to allow Apache to pass the credentials to JSPWiki in the HTTP request. You might also want to comment out the SSL connector - AJP doesn't seem to work correctly with it.
Do NOT use container-managed security
the authentication is not being done by Tomcat, but by Apache, so don't confuse the two.
Adding extra permissions
To add permissions other then the ones associated with "Authenticated" you can add entries to your jspwiki.policy file. For example:
grant signedBy "jspwiki"
  principal "naabou" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "InvOptWiki";
};
Adding extra roles
To add extra roles to your principal, use WikiGroups.

how can i use container managed using jspwiki.policy/catalina.policy#

information: my wikiengive 2.4.15 and tomcat is 5.5.17, jdk 1.5.0. container managed authentication (uncommented xml.web) using jspwiki.policy information. i have copied jspwiki.policy to conf/catalina.policy. i am using mysql for authorizing users.

how can i force every user for login first.#

i am using BASIC login module for in Web.xml

thanks in advance. Muhammod


why cannot i force a user not to view a page? unable to restrict on pageview permission.#

  • i have written in a page (pagename: About): [{ALLOW view Authenticated}], in next line [{ALLOW edit Authenticated}]
  • i have set a user roles as Asserted, Authenticated, Anonymous, Admin. i am retrieving users role from mysql and
  • i am using container managed Authentication and Authorization. using security policy for tomcat and JAAS for tomcat
by adding jspwiki.policy to catalina.policy
  • this is the information in catalina.policy grant signedBy "jspwiki", principal com.ecyrd.jspwiki.auth.authorize.Role "Anonymous" { permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:*", "view"; permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "login";
}; grant signedBy "jspwiki", principal com.ecyrd.jspwiki.auth.authorize.Role "Asserted" { permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:*", "edit"; permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Group*", "view"; permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "createPages"; permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "editProfile"; permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "login"; };
  • this is an example of web.xml of my wiki for container AA and Asserted role who's user in mysql is user11
<security-constraint>
<web-resource-collection>
<web-resource-name>Asserted Area</web-resource-name>
<url-pattern>/attach</url-pattern>
<url-pattern>/Comment.jsp</url-pattern>
<url-pattern>/Login.jsp</url-pattern>
<url-pattern>/Upload.jsp</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>Asserted</role-name>
</auth-constraint>
</security-constraint>
  • _NOW THE PROBLEM IS_ if i try to see the page "About" where is I had forced "ALLOW view Authenticated" not to view this page from a user of role Asserted
    but the user from that role Asserted can see that page. As i know this is not possible.
  • do i have any problem in my configuration? how can I solve this. i am stuck for one week. please help.

Thanks Muhammod

How do I configure when using JCIFS (NTLM authentication)?#

In previous versions of jspwiki I have used JCIFS servlet filter to authenticate users, that worked very well. In 2.4 (and I guess 2.3) this seems to be very complicated, can anyone tell me how I shall configure to get the previous behaviour. All become 'Anonymous Guest' even when they are authenticated OK.

- Alf Thunberg


CategoryDocumentation


Wildcards in ACLs?#

Is there a way to define the page ACLs using wildcards? For example, I've got two groups: XXXProject.Functional and XXXProject.Developer.

Say I want a page to be editable for both groups, could this be defined by something like:

[{ALLOW edit XXXProject.*}]

I've been looking around and it seems like this feature isn't supported (please correct me if I'm wrong). Are there any plans to do something like this in a future release?

--David Tan, 13-Nov-2006


Permissions for spaces#

I hav a situation in which i have 3 projects and 3 user groups, each group is assigned to a project and must not see other projects. I need to construct the wiki in a way that users of a group only view edit and create pages for their projects and cannot be seen by other users from other groups.
I know this could be done by the ACL, but then every user adding a page must add and ACL, and if he didn't his page will be accessible to evryone.
is there a way for pages to inherit default permissions from parent page, or even an implementation to spaces, where we can assign pages to a space that is not viewed by any user out of the group?

--Samer, 12-Dec-2006

Is it possible to set a page up so a Guest can be allowed to view it#

- something like [{ALLOW View Guest}]. If so what does that imply? If not how can it be done without opening up the whole Wiki? --Bill Robfogel (BillR) Feb. 8, 2007

Problems with jspwiki.policy with more WikiEngines#

Hi Folks, Iam totally new in the "JSPWiki"-World and iam german. So please apologise for my bad english... Iam hoping you can even help me and understand my problem! I need to set up three or four JSPWiki-Engines in ONE Tomcat-Environment. So i created a single .xml-File for each wiki inlcuding the "Context"-Informations like this:
<Context path="/Wiki3" docBase="/opt/web/apps/testwiki_2.4.100/Wiki3" debug="1" reloadable="true" crossContext="true">
<Parameter name="jspwiki.propertyfile" value="/opt/web/apps/testwiki_2.4.100/Wiki3/WEB-INF/jspwiki.properties" override="false"/>
</Context>

If i look at /Wiki3/admin/SecurityConfig.jsp it displays:

The system property 'java.security.policy' is set to: file:/opt/web/apps/testwiki/WEB-INF/jspwiki.policy.

... and i think thats the reason for my "Login-Problems" ...

Why uses the Engine the policy in the "testwiki"-File and not in the "testwiki_2.4.100" where my JSP-Files and my Webroot are? ... Is this a Bug in the New Version (2.4.100) ... The Engine which is loading before THIS Engine loads got the "testwiki"-Path... i think here is the bug!?

Thanks for Help...!!! --Matty / March 7th 2007

Hmm... I Think here is still talking about my Problem... okay.. so i understand why the police is the same for every wiki-Engine.. but why my "Login" is broken?!

I got this Message in my jspwiki.log

2007-03-07 09:37:10,249 [http-15984-Processor22] INFO SecurityLog Wiki3:/Wiki3/Login.jsp Wiki3:http://websune1.bk.datev.de:15984/Wiki3/Login.jsp - WikiSecurityEvent.LOGIN_AUTHENTICATED [source=com.ecyrd.jspwiki.auth.AuthenticationManager@1486b51, princpal=com.ecyrd.jspwiki.auth.WikiPrincipal Matty, target=com.ecyrd.jspwiki.WikiSession@1389244]
2007-03-07 09:37:10,254 [http-15984-Processor22] INFO JSPWiki Wiki3:/Wiki3/Login.jsp Wiki3:http://websune1.bk.datev.de:15984/Wiki3/Login.jsp - Successfully authenticated user Matty (custom auth)
2007-03-07 09:37:10,256 [http-15984-Processor22] INFO JSPWiki Wiki3:/Wiki3/Login.jsp Wiki3:http://websune1.bk.datev.de:15984/Wiki3/Login.jsp - Redirecting user to http://websune1.bk.datev.de:15984/Wiki3/Wiki.jsp?page=Main
2007-03-07 09:37:10,280 [http-15984-Processor22] INFO com.ecyrd.jspwiki.WikiContext Wiki3:/Wiki3/Wiki.jsp Wiki3:http://websune1.bk.datev.de:15984/Wiki3/Wiki.jsp - User Martin Ufer has no access - forbidden (permission=("com.ecyrd.jspwiki.auth.permissions.PagePermission","Wiki3:Main","view"))

and this in the security.log

2007-03-07 09:37:10,249 INFO - WikiSecurityEvent.LOGIN_AUTHENTICATED [source=com.ecyrd.jspwiki.auth.AuthenticationManager@1486b51, princpal=com.ecyrd.jspwiki.auth.WikiPrincipal Matty, target=com.ecyrd.jspwiki.WikiSession@1389244]

Hmm dont understand it... Why iam AUTHENTICATED but no Permisson!?

PLEASE Help me!

-- Matty / 7th March 2007

I tried it more and more, and now iam realised, that all works fine if i disable all other WikiEngines... I tried to deploy my "Wiki3"-Engine for its own in a Tomcat-Environment and the SecurityConfig.jsp shows me "green fields" in the Restrictions.. if i deploy more Engines in one Tomcat with the SAME policy in another path ("testwiki" instead "testwiki_2.4.100") than all fields on SecurityConfig.jsp of Wiki3 are read :(

Bug in Security of JSPWiki or iam to stupid?!

Thanks for help!

-- Matty / 7th March 2007 - 12 o' Clock GMT I have some questions:
1) If I use Install.jsp to install the wiki and change the wiki name to some other names (not JSPWiki), it seems the policy file is not changed accordingly, is it a bug?

grant signedBy "jspwiki",
principal com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
permission com.ecyrd.jspwiki.auth.permissions.AllPermission "JSPWiki";
};

2) If a user in a group has logged in, how the authorization is performed against this user? that is, this user is identified as either a "Authenticated" or a "Group" member. If we have granted rights to both "Authenticated" built-in role and the user's Group, which one takes precedence?

--AnonymousCoward, 08-Mar-2007

AD-Groups in groupdatabase.xml?#

Hi,

is there any possibility to use the Principals(AD-Groups) which i get from my AD in the groupdatabase.xml?

I have to offer the possiblity for an intern costumer, to manage the Groups in the wiki and adding ther LDAP-Groups (i've implemented an AJAX-Frontend for this) to Wiki-"pseudo"-Groups ... i dont want or need a second organisation of groups and right and so on ...

Any Ideas? ... Thanks!

And Please AnswerMe!

- MartinU


Hi there,

I try to get JSPWiki (2.4.102) working on Websphere 6.0. Everything works fine for me, but ACL's have no effect.

When I use something like: [{ALLOW edit username1}] and save the page, every other user (lets say username2, he has not the Admin-Role) can edit the page as well. I debugged, and saw that every user has the AllPermission. In the Method checkPermission( WikiSession session, Permission permission ) in the AuthorizationManager the hasAllPermission is being set to true.

I didn't change many things to the default-installation, I use Container-Managed Authentication (by uncommenting the security constraints in the web.xml), I didn't change the policy-file.

I believe it's not really a difficult problem, perhaps just a little configuration-problem. But i can't find it. Any comments are welcome, I don't know how to go on.

Best regards, albert

--albert, 12-Oct-2007

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-160) was last changed on 08-Jun-2009 20:19 by Harry Metske