Bug 1313133 - EJB/remoting certificate propagation uses the old certificate API but should be using the new API instead
EJB/remoting certificate propagation uses the old certificate API but should ...
Status: CLOSED WONTFIX
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: EJB, Security (Show other bugs)
6.4.0
All All
unspecified Severity medium
: ---
: ---
Assigned To: Ivo Studensky
Jan Martiska
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-29 22:26 EST by claudianus
Modified: 2016-03-01 07:16 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-01 07:00:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description claudianus 2016-02-29 22:26:01 EST
Description of problem:
Bug # 953200 (and equivalent wildfly bug WFLY-3580) added a certificate propagation to EJB remoting so that the X509 of the authenticated user can be passed on to downstream calls needing security context. However the certificate being used is based on the older/deprecated java API for x509 namely javax.security.cert.X509Certificate but should use the newer API java.security.cert.X509Certificate. 

We ran into issues when we tried to leverage the fix provided by WFLY-3580 via EAP 6.4 to stack the remoting login module with a custom login module uses 2 ways SSL. 
We had to add a custom method to convert the certificate being added to the request headers via the javax.security.auth.login.password and convert that to the newer API, which is more prevalent than the one deprecated. 

Version-Release number of selected component (if applicable):
EAP 6.4 (jboss-as-security7.5.0.Final included in EAP 6.4 and equivalent version in wildfly)

How reproducible:
Always reproducible if you are using a newer JAAS login module that uses 2 ways SSL that expects an X509 in the request header.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

I have created a workaround that is named extended login module that add a utility method to convert the deprecated X509 to the newer API based x509. The code is located here https://github.com/djcldns/extended-remoting-login-module/blob/master/src/main/java/org/jboss/as/security/remoting/ExtendedRemotingLoginModule.java
I also have fork of the SSL remoting quickstart to test the fix provided. That quickstart is located here https://github.com/djcldns/jboss-secured-ejb-remote-over-ssl.

Basically the ideal fix would be to use an X509 based on the newer API as default certificate and have a utility similar to the I have so that if one is still relying on the deprecated API they can easily convert the certificate by overriding the default to match they use case.
Comment 3 Ivo Studensky 2016-03-01 07:00:16 EST
Any questions pertaining EAP need to go via the Customer Support Portal. [1]
If you currently do not hold an entitlement for the product, then please contact sales. [2]

[1] ​https://access.redhat.com/products/red-hat-jboss-enterprise-application-platform/support-information
[2] ​http://www.redhat.com/en/about/contact/sales

Note You need to log in before you can comment on or make changes to this bug.