Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 prvs=Joseph.Hobbs=2143288d4@53.com designates 216.82.180.35 as permitted
 sender)
DomainKey-Signature: s=main; d=53.com; c=simple; q=dns;
  h=X-IronPort-AV:Received:Received:Content-class:
   MIME-Version:X-MimeOLE:Subject:Date:Message-ID:
   X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic:
   Thread-Index:From:To:Return-Path:X-OriginalArrivalTime:
   Content-Type:Content-Transfer-Encoding;
  b=E04O7xPvIU43cPB77sEtibNQ5I5aZ57F9DtONWmVvtZlXkx804EvLw9s
   bsIu6UVeAjooeLY+zqVXIA5bmOXWpWOpf3XGuE3xwAgwJcqythu2SWv/w
   1DIPh8N6YEpW4MUNjPSu+rm89wFxQKVRejzOOasEuEJfcJfImF3+4EznZ
   E=;
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: jspwiki.policy and java.policy
Date: Mon, 1 Dec 2008 15:55:33 -0500
Message-ID: 
 <0EC7CBBDCD234541BFC8F3A738F52C26047825A8@s1flokydce2k322.dm0001.info53.com>
Thread-Topic: jspwiki.policy and java.policy
Thread-Index: AclT9A77RjnimdwQQaq1T14fi1Cxyw==
From: "Hobbs, Joseph" <Joseph.Hobbs@53.com>
To: <jspwiki-dev@incubator.apache.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All!  New to the list, but not to JSPWiki.  I've been using it
internally for a few years, and just recently started digging into it
deeper.  Good stuff!  I did run into one issue that confused me, and I
was curious to get some else's take on it.

I'm running IBM's WebSphere Application Server 6.1.0.15 running on AIX
5.3 and JSPWiki 2.6.4.  WebSphere is using an LDAP Registry and I also
have RSA's Cleartrust for Single Sign On configured within WebSphere.
I've been successful in getting everything working (even SSO) with
JSPWiki through Container Managed security.  I was able to do all of
this through modification of some XML (web.xml) and jspwiki.properties.
One note...  I do NOT have Java 2 security enabled (this is critical for
later).

The issue I've run into relates to JSPWiki and how it handles
jspwiki.policy.  Even though I've defined roles and the container is
providing them, I'm still an admin.  No matter what I do, I've got full
privileges.  I can do anything an admin does, even though I don't have
the privileges per jspwiki.policy.  Page ACL's don't seem to apply
either.

After digging into the issue, I discovered that JSPWiki wasn't even
checking the policies defined within the jspwiki.policy file.
Com.ecyrd.jspwiki.auth.AuthorizationManager.checkStaticPermission(WikiSe
ssion,Permission) checks the JVM-wide security policy first, and only
checks the local policy if the JVM-wide policy denies the action.  Since
I don't have Java Security enabled on the JVM, the JVM-wide policy will
not deny ANY actions.

So, all that leads me to my question.  Don't take this as a dig or
challenge.  I've learned in my life that while I can't think of reasons,
there are plenty out there.  Just trying to understand the reasoning.
This is especially true for me currently, as I'm still learning the
JSPWiki codebase and don't have a great deal of background with java
policies!  Sooo....

Question: Why does the JVM-wide policy apply at this point?  If JSPWiki
is loading its own jspwiki.policy file, should we be deferring to the
JVM-wide policy at all?  That policy should be governing what my
application can do to the system/etc, not what my users can do within
the application.  Will anything obvious break if I 'eliminate' the JVM
policy check from AuthorizationManager?

On a side note...  I've tried enabling Java Security and was able to
verify that the policies were being processed as expected.  With that
said, it's caused me some other pain that I'm still working through
(mainly around the SSO component).  I'm not looking for a quick fix
here.  I'm just curious as to why JVM-wide is even taken into account if
JSPWiki is loading a local policy separate.

I appreciate your time, as well as any responses!  Thank you and have a
good holiday!

Joseph Hobbs
Email : Joseph.Hobbs@53.com

This e-mail transmission contains information that is confidential and may =
be privileged.   It is intended only for the addressee(s) named above. If y=
ou receive this e-mail in error, please do not read, copy or disseminate it=
 in any manner. If you are not the intended recipient, any disclosure, copy=
ing, distribution or use of the contents of this information is prohibited.=
 Please reply to the message immediately by informing the sender that the m=
essage was misdirected. After replying, please erase it from your computer =
system. Your assistance in correcting this error is appreciated.