Bug 901309 (JBPAPP6-1772)

Summary: SubjectCNMapper is not called with CertificatesRoles login-module
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Hisanobu Okuda <hokuda>
Component: Security, WebAssignee: Stefan Guilhen <sguilhen>
Status: CLOSED WONTFIX QA Contact: Josef Cacek <jcacek>
Severity: high Docs Contact:
Priority: high    
Version: 6.0.1CC: akram, bdawidow, bmaxwell, dehort, hokuda, jcacek, ppalaga, rhatlapa, sguilhen, tfonteyn
Target Milestone: ---   
Target Release: EAP 6.4.0   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/JBPAPP6-1772
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-19 09:10:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Hisanobu Okuda 2013-01-09 05:20:05 UTC 
Help Desk Ticket Reference: https://na7.salesforce.com/500A000000CR6th
project_key: JBPAPP6

I'm using the CertRolesLoginModule to perform CLIENT_CERT authentication with EAP 6.0.1. I configured my security-domain to use SubjectCNMapper to map a principal's name to CN as follow:-

{code}
  <security-domain name="mycertauth" cache-type="default">
    <authentication>
      <login-module code="CertificateRoles" flag="required">
        <module-option name="securityDomain" value="mycertauth"/>
        <module-option name="verifier" value="org.jboss.security.auth.certs.AnyCertVerifier"/>
        <module-option name="rolesProperties" value="${project.build.outputDirectory}/config/ws-roles.properties"/>
      </login-module>
    </authentication>
    <mapping>
      <mapping-module code="org.jboss.security.mapping.providers.principal.SubjectCNMapper" type="principal" />
    </mapping>                   
    <jsse truststore-url="${project.build.outputDirectory}/config/ServerTrustStore.jks"
                          truststore-password="password"
                          truststore-type="jks" client-auth="true"
                          keystore-url="${project.build.outputDirectory}/config/ServerKeyStore.jks"
                          keystore-password="password"
                          keystore-type="jks"
                            />
  </security-domain>
{code}

But it does not affect, and HttpServletRequest#getUserPrincipal()#getName() returns DN.
Comment 1 Hisanobu Okuda 2013-06-20 08:49:37 UTC 
Hi Anil,
Can you put it in the block list of 6.1.x?
Comment 2 JBoss JIRA Server 2013-06-21 16:41:49 UTC 
John Doyle <jdoyle> made a comment on jira PRODMGT-431

I just reviewed the GSS ticket.  Is it a correct understanding that the behavior the customer wants worked in 6.0 but does not in 6.1?  Seems like a regression to me if that's the case and not a Feature Request.
Comment 3 JBoss JIRA Server 2013-06-23 22:23:28 UTC 
Hisanobu Okuda <hokuda> made a comment on jira PRODMGT-431

In EAP 6.0.0, request.getUserPrincipal().getName() returns CN. In EAP 6.0.1 and 6.1.0, it returns DN. The behavior is a regression to the customer of the GSS ticket, but other customer would think of it as an enhancement. The problem is that it is not configurable.
Comment 4 JBoss JIRA Server 2013-06-23 22:39:30 UTC 
Hisanobu Okuda <hokuda> made a comment on jira PRODMGT-431

In EAP5, it is configurable. In that sense, it is a regression.
Comment 5 JBoss JIRA Server 2013-09-17 19:16:22 UTC 
Derek Horton <dhorton> made a comment on jira PRODMGT-431

This did work in EAP 6.0.0.  However, I think the changes to fix the JAAS cache issue likely changed the behavior.  As a result, upgrading to 6.0.1 "broke" the customers code.

Like Hisanobu says, the real issue here is that it is not configurable in 6.x.  In 5.x, you could configure the mappers at the JBossWebRealm level.  This is not possible in EAP 6.

I think the best thing to do would be to make it so that the principal mappers get called at the web level.

We have provided the customer with an acceptable workaround.  It is described in this knowledge base article:
https://access.redhat.com/site/solutions/293793

For this particular customer, they needed to implement a custom principal and a custom SSL authenticator.
Comment 6 Stefan Guilhen 2013-10-25 19:42:54 UTC 
A property to allow configuration of the certificate mapper should have been added to the web subsystem since its inception. Adding it now is not trivial (there is no place to configure the WebRealm in the web subsystem). We could look into adding a system property to allow for the config of the mapper or just use the workaround Derek described above.

I'm setting devel_ack to "-". There is a workaround available and I think we need more time to come up with a proper solution. If anybody thinks that adding a system property is a good idea we can probably code something next week.