Re: Question about default subject in tomcat integration

[Jeff Genender]

DJ,

Didn't you write the DefaultSubjectValve? ;-)

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

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

Re: Question about default subject in tomcat integration

[Jeff Genender]

David Jencks wrote:
 
 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 :-)

Well it worked!  That was good enough for me ;-)

 
 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.

When an addValve() is done, it goes to the end of the pipeline.  So its
already after authenticating valves.

Can you explain a little more in detail of the issue regarding when the
defaultSubject needs to be there (or doesn't), then I can probably help
with a solution here.

Jeff

 
 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