Client/Server Key Aliases at JBoss Security Domain Level
Keystores may contain more than one server or client key. JSSE uses the concept of key alias to differentiate among multiple keys in the same keystore. Such a multiple-key keystore may be potentially used as the underlying key provider by a JBoss security domain. Currently (as per 4.3.0.GA_CP04) there is no way of declaratively specifying at security domain configuration level a preferred server or client key alias. JSSE exposes the API that allows a caller to specify a preferred server or client key (see javax.net.ssl.X509KeyManager), but the actual JBoss code does not take advantage of this feature. The suggested improvements are intended to change this situation.
The possibility of specifying a preferred client or server key alias should be exposed at org.jboss.security.plugins.JaasSecurityDomain/org.jboss.security.plugins.JaasSecurityDomainMBean level:
void setServerAlias(String s);
void setClientAlias(String s);
so preferred key aliases could be configured in the JaasSecurityDomain's configuration file.
This information then needs to be propagated from the JaasSecurityDomain level to the underlying javax.net.ssl.SSLContext instances. The least invasive way of doing this with the current code base is to modify org.jboss.security.ssl.Context.forDomain() so during the SSLContext creation, "alias aware" KeyManager instances are created, "wrapped" around the KeyManager instances provided by the security domain's key manager factory and used to initialize the newly created SSLContext.
On a side note, it would have been more elegant to factor out the wrapping code and move it away from org.jboss.security.ssl.Context, by subclassing javax.net.ssl.KeyManagerFactory and overriding KeyManagerFactory.getKeyManagers(). Unfortunately, that is not possible, JSSE declares getKeyManagers() as final.
org.jboss.security.ssl.Context's forDomain() receives a org.jboss.security.SecurityDomain, not a org.jboss.security.plugins.JaasSecurityDomain, so the choice of preferred key aliases has also to be exposed at org.jboss.security.SecurityDomain level. Accessors are sufficient.
A patch has been written and tested and it will be attached to the JIRA issue as soon as it is created. Please note that this change adds functionality and does not change or removes existing functionality, so most likely will not interfere with current code building it top of org.jboss.security; full test suite run is required, of course.