DO NOT REPLY [Bug 31826] New: - Possibility execute requests within access control context with custom domain combiner associated to it

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31826>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31826

Possibility execute requests within access control context with custom domain combiner associated to it

           Summary: Possibility execute requests within access control
                    context with custom domain combiner associated to it
           Product: Tomcat 5
           Version: Nightly Build
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: jukka.junnila@uta.fi


Hello,

Would it be possible to create some sort of mechanism to catalina, that allows
(http)requests to be executed inside an AccessControlContext that would have
custom DomainCombiner associated to it. At the moment (when security manager is
turned on) servlets (and jsp pages), filters, requestdispacthers, etc. are
executed within AccessControlContext with instance of
javax.security.auth.SubjectDomainCombiner. It seems that at the moment there is
no "single point" where one could say that use instance of this domain combiner
when SecurityUtils.execute(...) performs Subject.doAsPrivileged(....) call.

If I have understood java security correctly there is at least two extension
point. One extension point is java.security.Policy and second is subclassing
(Subject)DomainCombiner. Running catalina with custom Policy is peace of cake
but this domain combiner stuff seems need some adjustments to catalina codebase
(I attach a proposal / example patch to this RFE).

In the proposal / example SecurityUtil.execute(..) has been modified so that if
current webapplication's (whose HttpServletRequest is being processed)
WebappClassLoader (at some level in the classloader hierarcy) contains a
reference to AccessControlContextFactory then SecurityUtil request a instance of
AccessControlContext from that particular factory and instead of calling
Subject.doAsPrivileged(...) it calls AccessController.doPrivileged(pea,
customAccessControlContext). It is up to AccessControlContextFactory provider
how it creates an AccessControlContext. Only requirement would be that context
contains a instance (or subclass) of SubjectDomainCombiner.
Just a brief summary of modifications that this proposal patch contains:

* jakarta-tomcat-catalina/catalina/build.xml:
exclude org.apache.catalina.security.spi.AccessControlContextFactory from
catalina.jar and copy it to common/classes so that Webappclassloader sees it, so
that webapplication specific accesscontrolcontextfactory implementation can
reside in that particular webapp's /WEB-INF/[lib|classes] repository.

* StandardContext.java:
setter and getter methods for accessControlContextFactoryName parameter
(<Context ...accessControlContextFactoryName="fully.qualified.classname" ..../>

* webapploader.java:
few lines of code to create an instance of AccessControlContextFactory (if
current StandardContext has accessControlContextFactoryName attribute set) and
associate it to web applications WebappClassLoader.

As I mentioned this is just a proposal / example and I do realize that this
patch contains some nasty cross package references (between catalina.security
catalina.loader and catalina.core).

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org