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

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

XMLWordPrintable

    • 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.

      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.

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

                Created:
                Updated:
                Resolved: