Re: Question about default subject in tomcat integration

[David Jencks]

On Jan 4, 2006, at 2:49 PM, Jeff Genender wrote:
DJ,

Didn't you write the DefaultSubjectValve? ;-)

That was three months ago! How do you expect me to remember such  
ancient history ??? :-)

So, it looks to me as if GERONIMO-1012 was, as I thought, not  
complete and you shouldn't have closed it :-)

Will continue investigating.  Do you know of any way to install a  
valve AFTER the ones tomcat installs for you, or a way to change what  
those valves are?  I think putting the DefaultSubjectValve after the  
authentication happens would fix the problems.

thanks
david jencks


Jeff

David Jencks wrote:
In GeronimoStandardContext this is the code that sets up the
DefaultSubjectValve:

                //This is definitely a hack, but I don't see a
reasonable way to install the defaultSubject.
                //Obviously this won't work if there are permissions.
Setting the default subject if there are
                //permissions breaks authentication.
                boolean hasPermissions =
securityHolder.getChecked().elements().hasMoreElements() ||

securityHolder.getExcluded().elements().hasMoreElements();
                Valve defaultSubjectValve;
                if (!hasPermissions && defaultSubject != null) {
                    defaultSubjectValve = new
DefaultSubjectValve(defaultSubject);
                } else {
                    //this will clear the thread of any read subject
added by some other web app
                    defaultSubjectValve = new DefaultSubjectValve 
(null);
                }
                addValve(defaultSubjectValve);


In DefaultSubjectValve, the operative code is:

    public void invoke(Request request, Response response) throws
IOException, ServletException {
        boolean setSubject = ContextManager.getCurrentCaller() ==  
null;
        if (setSubject) {
            ContextManager.setCurrentCaller(defaultSubject);
            ContextManager.setNextCaller(defaultSubject);
            try {
                getNext().invoke(request, response);
            } finally {
                ContextManager.setCurrentCaller(null);
                ContextManager.setNextCaller(null);
            }
        } else {
            getNext().invoke(request, response);
        }
    }


This doesn't make any sense to me.  If
DefaultSubjectValve.defaultSubject is null, then DefaultSubjectValve
will clear nextCaller if currentCaller is null, otherwise do  
nothing.  I
doubt this is critical functionality.  However, it appears to me that
the code in GeronimoStandardContext that sets
DefaultSubjectValve.defaultSubject to null if the web app has checked
constraints appears to me to prevent the default subject from  
being set
for that portion of the app that is unsecured, which is where I  
thought
it was important.

Could someone explain just how always using the actual defaultSubject
breaks authentication?

thanks
david jencks