Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-3016

Expose principal-decoder as principal-transformer and support conversion to X500Principal

    XMLWordPrintable

Details

    • Hide
      1. Unzip EAP and start ./bin/standalone.sh
      2. Configure Two-way SSL as described here: 
        in shell:
# keytool -genkeypair -alias localhost -keyalg RSA -keysize 1024 -validity 365 -keystore server.keystore.jks -dname "CN=localhost" -keypass secret -storepass secret
# keytool -genkeypair -alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname "CN=client" -keypass secret -storepass secret
# keytool -exportcert  -keystore server.keystore.jks -alias localhost -keypass secret -storepass secret -file server.cer
# keytool -exportcert  -keystore client.keystore.jks -alias client -keypass secret -storepass secret -file client.cer   #<--- alias is 'client' which matches CN
# keytool -importcert -keystore server.truststore.jks -storepass secret -alias client -trustcacerts -file client.cer
# keytool -importcert -keystore client.truststore.jks -storepass secret -alias localhost -trustcacerts -file server.cer
# keytool -importkeystore -srckeystore client.keystore.jks -destkeystore client.p12 -srcstoretype JKS -deststoretype PKCS12 -deststorepass secret -destkeypass secret -srcalias client -destalias client -srcstorepass secret

in EAP CLI:
/subsystem=elytron/key-store=twoWayKS:add(path=server.keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-store=twoWayTS:add(path=server.truststore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS,algorithm="SunX509",credential-reference={clear-text=secret})
/subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS,algorithm="SunX509")
/subsystem=elytron/server-ssl-context=twoWaySSC:add(key-manager=twoWayKM,protocols=["TLSv1.2"],trust-manager=twoWayTM,need-client-auth=true)
/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=twoWaySSC)
      3. Now when we configure private key in our client, we are able to access EAP welcome-content.
      4. Configure CLIENT_CERT authentication as described here: 
        /subsystem=elytron/key-store-realm=ksRealm:add(key-store=twoWayTS)
/subsystem=elytron/x500-attribute-principal-decoder=CNDecoder:add(oid="2.5.4.3",maximum-segments=1)
/subsystem=elytron/constant-role-mapper=constantClientCertRole:add(roles=[gooduser])  #<--- we use 'gooduser' role as it is defined in our application web.xml file
/subsystem=elytron/security-domain=cert-test:add(realms=[{realm=ksRealm}],default-realm=ksRealm,permission-mapper=default-permission-mapper,principal-decoder=CNDecoder,role-mapper=constantClientCertRole)
/subsystem=elytron/http-authentication-factory=cert-test-auth-factory:add(http-server-mechanism-factory=global,security-domain=cert-test,mechanism-configurations=[{mechanism-name=CLIENT_CERT,mechanism-realm-configurations=[{realm-name=cert-test}]}])
/subsystem=undertow/application-security-domain=cert-test:add(http-authentication-factory=cert-test-auth-factory)
/subsystem=elytron/server-ssl-context=twoWaySSC:write-attribute(name=security-domain,value=cert-test)

deploy web-secure-client-cert.war
      5. Access secured content with http2 eligible client: 
        https://localhost:8443/web-secure-client-cert/secured/
        • when HTTP2 is utilized, 403 is returned from the server, in case HTTP/1.1 is utilized, servlet's content is returned successfully with 200 OK return code.
      Show
      Unzip EAP and start ./bin/standalone.sh Configure Two-way SSL as described here : in shell: # keytool -genkeypair -alias localhost -keyalg RSA -keysize 1024 -validity 365 -keystore server.keystore.jks -dname "CN=localhost" -keypass secret -storepass secret # keytool -genkeypair -alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname "CN=client" -keypass secret -storepass secret # keytool -exportcert -keystore server.keystore.jks -alias localhost -keypass secret -storepass secret -file server.cer # keytool -exportcert -keystore client.keystore.jks -alias client -keypass secret -storepass secret -file client.cer #<--- alias is 'client' which matches CN # keytool -importcert -keystore server.truststore.jks -storepass secret -alias client -trustcacerts -file client.cer # keytool -importcert -keystore client.truststore.jks -storepass secret -alias localhost -trustcacerts -file server.cer # keytool -importkeystore -srckeystore client.keystore.jks -destkeystore client.p12 -srcstoretype JKS -deststoretype PKCS12 -deststorepass secret -destkeypass secret -srcalias client -destalias client -srcstorepass secret in EAP CLI: /subsystem=elytron/key-store=twoWayKS:add(path=server.keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS) /subsystem=elytron/key-store=twoWayTS:add(path=server.truststore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS) /subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS,algorithm= "SunX509" ,credential-reference={clear-text=secret}) /subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS,algorithm= "SunX509" ) /subsystem=elytron/server-ssl-context=twoWaySSC:add(key-manager=twoWayKM,protocols=[ "TLSv1.2" ],trust-manager=twoWayTM,need-client-auth= true ) /subsystem=undertow/server= default -server/https-listener=https:undefine-attribute(name=security-realm) /subsystem=undertow/server= default -server/https-listener=https:write-attribute(name=ssl-context,value=twoWaySSC) Now when we configure private key in our client, we are able to access EAP welcome-content. Configure CLIENT_CERT authentication as described here : /subsystem=elytron/key-store-realm=ksRealm:add(key-store=twoWayTS) /subsystem=elytron/x500-attribute-principal-decoder=CNDecoder:add(oid= "2.5.4.3" ,maximum-segments=1) /subsystem=elytron/constant-role-mapper=constantClientCertRole:add(roles=[gooduser]) #<--- we use 'gooduser' role as it is defined in our application web.xml file /subsystem=elytron/security-domain=cert-test:add(realms=[{realm=ksRealm}], default -realm=ksRealm,permission-mapper= default -permission-mapper,principal-decoder=CNDecoder,role-mapper=constantClientCertRole) /subsystem=elytron/http-authentication-factory=cert-test-auth-factory:add(http-server-mechanism-factory=global,security-domain=cert-test,mechanism-configurations=[{mechanism-name=CLIENT_CERT,mechanism-realm-configurations=[{realm-name=cert-test}]}]) /subsystem=undertow/application-security-domain=cert-test:add(http-authentication-factory=cert-test-auth-factory) /subsystem=elytron/server-ssl-context=twoWaySSC:write-attribute(name=security-domain,value=cert-test) deploy web-secure-client-cert.war Access secured content with http2 eligible client: https: //localhost:8443/web-secure-client-cert/secured/ when HTTP2 is utilized, 403 is returned from the server, in case HTTP/1.1 is utilized, servlet's content is returned successfully with 200 OK return code.

    Description

      When I setup CLIENT_CERT authentication for an application (see Steps to Reproduce) and utilize HTTP/2 protocol, I get always 403 Forbidden even in case I use correct client certificate that should allow me access to a secured content.

      I can see following TRACE messages in server.log:

      2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) X500 principal [CN=client] decoded as name [client] (attribute values: [client])
2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Principal assigning: [CN=client], pre-realm rewritten: [client], realm name: [ksRealm], post-realm rewritten: [client], realm rewritten: [client]
2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Role mapping: principal [client] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [gooduser]
2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing principal client.
2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing against the following attributes: [] => []
2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Permission mapping: identity [client] with roles [gooduser] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authorization succeed
2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authentication succeed for principal [CN=client]
2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) Handling MechanismInformationCallback type='HTTP' name='CLIENT_CERT' host-name='localhost' protocol='https'
2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) CLIENT-CERT no SSL session

      Authentication seems that it succeed just fine. But notice the last line - CLIENT-CERT no SSL session.

      When I disable 'http2' in https-listener:

      /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enable-http2,value=false)
reload

      I can now access secured content as expected. Also trace log contains different (more healthy) messages now.

      This happens both when I utilize HTTP/2 with EAP 'alpn-hack' mechanism and also with ALPN provided by OpenSSL library.

      Attachments

        Issue Links

          causes

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-13688 Elytron, wrong capabilities registered

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified
          clones

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-11084 Undertow CLIENT_CERT via Elytron and HTTP/2 does not work

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Verified
          relates to

          Bug - A problem that impairs or prevents the functions of the product. WFCORE-3398 Elytron, wrong capabilities registered

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Activity

            People

              darran.lofthouse@redhat.com Darran Lofthouse
              darran.lofthouse@redhat.com Darran Lofthouse
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: