You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2007/04/20 14:45:34 UTC
AppClient security call back handlers essentially broken in 2.0
I've run into a serious problem with app client security callback
handlers in Geronimo 2.0. These appear to be completely broken, and I'm
not sure I understand how to fix this. Here's the scenario:
In 1.2, a security callback handler class can be specified in the plan.
In the main() method of the AppClientContainer, this was handled thusly:
if (callbackHandlerClass != null) {
//look for a constructor taking the args
CallbackHandler callbackHandler;
try {
Constructor cArgs =
callbackHandlerClass.getConstructor(new Class[] {String[].class});
callbackHandler = (CallbackHandler)
cArgs.newInstance(new Object[] {args});
} catch (NoSuchMethodException e) {
callbackHandler = (CallbackHandler)
callbackHandlerClass.newInstance();
}
loginContext = new LoginContext(realmName, callbackHandler);
try {
loginContext.login();
} catch (LoginException e) {
loginContext = null;
throw e;
}
clientSubject = loginContext.getSubject();
}
The appclient container looked for a constructor on the target callback
handler that took an array of Strings as an argument, and constructed
that callback handler using the string arguments passed to the
AppClientContainer main() method. The callback handler would scan the
application args looking for options that applied to its authentication
technique, and it was passed to the loginContext in an initialized
state, ready to provide addtional information to the login process.
In 2.0, this has changed drastically, breaking any call back handlers
written for 1.2, and I don't even see an obvious method of fixing this.
Here's the new code for managing the callback handler:
if (callbackHandlerClass != null) {
callbackHandler = (CallbackHandler)
holder.newInstance(callbackHandlerClass, classLoader, componentContext);
loginContext = new LoginContext(realmName, callbackHandler);
try {
loginContext.login();
} catch (LoginException e) {
loginContext = null;
throw e;
}
clientSubject = loginContext.getSubject();
}
Same relative point in the AppClientContainer startup, but with two key
differences:
1. The holder.newInstance() call appears to be looking for a
no-argument constructor on the callbackHandlerClass (which likely
fails with the 1.2 classes because they are expecting to have
their void CallbackHandler(String []) constructor called).
2. The new callback handler instance is no longer being given access
to the appclient args to initialize. There appears to be some
injection processing going on in the holder.newInstance() call,
but it's not clear how to specify what information get injected,
or even if the information from the appclient args is available.
So, how is this supposed to work, and if this is currently working
correctly in 2.0, what is the process for converting a handler written
for 1.2 into an equivalent for 2.0?
Rick
Re: AppClient security call back handlers essentially broken in 2.0
Posted by David Jencks <da...@yahoo.com>.
I'm pretty sure the additional issue is due to some ridiculous
restrictions on which classloader certain porting classes need to be
in for the tck. The support in 1.2 for certain callback handlers
without no-arg constructors is another attempt to work around
weirdness in the tck. We've found another way to deal with these
issues with the javaee tck. In other words.... I don't think
anything is broken, and lets discuss this on the tck list.
thanks
david jencks
On Apr 20, 2007, at 6:54 AM, Rick McGuire wrote:
> There appears to be one more issue with this. I created a callback
> handler with a no-arg constructor so I could examine the behavior
> of what's going on, and I've discovered that there appears to be an
> issue with the classloader used to resolve the callback handler.
> My callback handler object is getting NoClassDefFound errors trying
> to access the
> org.apache.geronimo.security.realm.providers.CertificateChainCallback
> class. It's not clear to me why this is a problem, since it
> appears the client config has a dependency on the geronimo-security
> module.
>
> Rick
>
> Rick McGuire wrote:
>> I've run into a serious problem with app client security callback
>> handlers in Geronimo 2.0. These appear to be completely broken,
>> and I'm not sure I understand how to fix this. Here's the scenario:
>>
>> In 1.2, a security callback handler class can be specified in the
>> plan. In the main() method of the AppClientContainer, this was
>> handled thusly:
>>
>> if (callbackHandlerClass != null) {
>> //look for a constructor taking the args
>> CallbackHandler callbackHandler;
>> try {
>> Constructor cArgs =
>> callbackHandlerClass.getConstructor(new Class[] {String[].class});
>> callbackHandler = (CallbackHandler)
>> cArgs.newInstance(new Object[] {args});
>> } catch (NoSuchMethodException e) {
>> callbackHandler = (CallbackHandler)
>> callbackHandlerClass.newInstance();
>> }
>> loginContext = new LoginContext(realmName,
>> callbackHandler);
>> try {
>> loginContext.login();
>> } catch (LoginException e) {
>> loginContext = null;
>> throw e;
>> }
>> clientSubject = loginContext.getSubject();
>> }
>>
>>
>> The appclient container looked for a constructor on the target
>> callback handler that took an array of Strings as an argument, and
>> constructed that callback handler using the string arguments
>> passed to the AppClientContainer main() method. The callback
>> handler would scan the application args looking for options that
>> applied to its authentication technique, and it was passed to the
>> loginContext in an initialized state, ready to provide addtional
>> information to the login process.
>> In 2.0, this has changed drastically, breaking any call back
>> handlers written for 1.2, and I don't even see an obvious method
>> of fixing this. Here's the new code for managing the callback
>> handler:
>>
>> if (callbackHandlerClass != null) {
>> callbackHandler = (CallbackHandler)
>> holder.newInstance(callbackHandlerClass, classLoader,
>> componentContext);
>> loginContext = new LoginContext(realmName,
>> callbackHandler);
>> try {
>> loginContext.login();
>> } catch (LoginException e) {
>> loginContext = null;
>> throw e;
>> }
>> clientSubject = loginContext.getSubject();
>> }
>>
>> Same relative point in the AppClientContainer startup, but with
>> two key differences:
>>
>> 1. The holder.newInstance() call appears to be looking for a
>> no-argument constructor on the callbackHandlerClass (which
>> likely
>> fails with the 1.2 classes because they are expecting to have
>> their void CallbackHandler(String []) constructor called).
>> 2. The new callback handler instance is no longer being given
>> access
>> to the appclient args to initialize. There appears to be some
>> injection processing going on in the holder.newInstance() call,
>> but it's not clear how to specify what information get injected,
>> or even if the information from the appclient args is available.
>>
>> So, how is this supposed to work, and if this is currently working
>> correctly in 2.0, what is the process for converting a handler
>> written for 1.2 into an equivalent for 2.0?
>>
>> Rick
>>
>>
>
Re: AppClient security call back handlers essentially broken in 2.0
Posted by Rick McGuire <ri...@gmail.com>.
There appears to be one more issue with this. I created a callback
handler with a no-arg constructor so I could examine the behavior of
what's going on, and I've discovered that there appears to be an issue
with the classloader used to resolve the callback handler. My callback
handler object is getting NoClassDefFound errors trying to access the
org.apache.geronimo.security.realm.providers.CertificateChainCallback
class. It's not clear to me why this is a problem, since it appears the
client config has a dependency on the geronimo-security module.
Rick
Rick McGuire wrote:
> I've run into a serious problem with app client security callback
> handlers in Geronimo 2.0. These appear to be completely broken, and
> I'm not sure I understand how to fix this. Here's the scenario:
>
> In 1.2, a security callback handler class can be specified in the
> plan. In the main() method of the AppClientContainer, this was
> handled thusly:
>
> if (callbackHandlerClass != null) {
> //look for a constructor taking the args
> CallbackHandler callbackHandler;
> try {
> Constructor cArgs =
> callbackHandlerClass.getConstructor(new Class[] {String[].class});
> callbackHandler = (CallbackHandler)
> cArgs.newInstance(new Object[] {args});
> } catch (NoSuchMethodException e) {
> callbackHandler = (CallbackHandler)
> callbackHandlerClass.newInstance();
> }
> loginContext = new LoginContext(realmName,
> callbackHandler);
> try {
> loginContext.login();
> } catch (LoginException e) {
> loginContext = null;
> throw e;
> }
> clientSubject = loginContext.getSubject();
> }
>
>
> The appclient container looked for a constructor on the target
> callback handler that took an array of Strings as an argument, and
> constructed that callback handler using the string arguments passed to
> the AppClientContainer main() method. The callback handler would scan
> the application args looking for options that applied to its
> authentication technique, and it was passed to the loginContext in an
> initialized state, ready to provide addtional information to the login
> process.
> In 2.0, this has changed drastically, breaking any call back handlers
> written for 1.2, and I don't even see an obvious method of fixing
> this. Here's the new code for managing the callback handler:
>
> if (callbackHandlerClass != null) {
> callbackHandler = (CallbackHandler)
> holder.newInstance(callbackHandlerClass, classLoader, componentContext);
> loginContext = new LoginContext(realmName,
> callbackHandler);
> try {
> loginContext.login();
> } catch (LoginException e) {
> loginContext = null;
> throw e;
> }
> clientSubject = loginContext.getSubject();
> }
>
> Same relative point in the AppClientContainer startup, but with two
> key differences:
>
> 1. The holder.newInstance() call appears to be looking for a
> no-argument constructor on the callbackHandlerClass (which likely
> fails with the 1.2 classes because they are expecting to have
> their void CallbackHandler(String []) constructor called).
> 2. The new callback handler instance is no longer being given access
> to the appclient args to initialize. There appears to be some
> injection processing going on in the holder.newInstance() call,
> but it's not clear how to specify what information get injected,
> or even if the information from the appclient args is available.
>
> So, how is this supposed to work, and if this is currently working
> correctly in 2.0, what is the process for converting a handler written
> for 1.2 into an equivalent for 2.0?
>
> Rick
>
>