I have a situation in which my web service client (running in a jsp) needs to be able to dynamically change authentication parameters for accessing a partical service based off of some administrative settings. (I need help with B)
Scenario A: HTTP Basic username/password
Status: It works great, all I need to do is to pass along the username and password from the form login via the context provider object
Scenario B: Multihop with HTTPS with client certificates
User's Browser (with a user cert) to Jboss web client (in a jsp. server has it's own server cert) which then calls the web service, using the server cert as a client-cert.
Status: doesn't work and I'm not sure what I'm missing.
The overal goal is to provide some level of impresonation from the end user, through the web interface, to the web service. I'm doing this by passing along some custom headers (not that's beyond the point right now). So the question really is, what do I need to specify programmatically to setup the web service client in the jsp, in order to setup the SSL connection with client certs.
Ideally, I'd like to just steal the settings from the container, that way configuration is similified.
I've pretty sure I've done this in the past with a console app and jbossws. All I did was specificy the location of the key store via the environment properties (javax.net.ssl ...). Which leaves me a bit puzzled why it wouldn't be picked up from the stack.
Edit: After looking through the Netty Client source, I found an SSLContextFactory which does look for the default settings. Since it doesn't appear to find them, I'm assuming that jboss, when defining the keystore paths and passwords in server.xml, does not make these settings available to the container as a whole. Can anyone confirm this?
I just confirmed that when setting things like keystore and truststores via jboss's server.xml connectors, those parameters/settings are NOT available to applications (web service clients) running in the jboss container. bummer.
Is there perhaps another way to find out this info? I'm trying to avoid packaging additional certificates with my war. Moreover, when loading the javax.ssl settings to the system properties, it has the potential to affect everything in the container, also not good.
In addition, I've discovered that the jbossws native stack does not actually do anything when inserting javax.ssl settings into the context provider. Too bad, it looks like it would have been a nice place to be able to have application specific ssl settings.