Loading...

Type: Bug
Resolution: Done
Priority: Blocker
Fix Version/s: 1.1.0.Beta48
Affects Version/s: None
Component/s: None
Labels:
None

Steps to Reproduce:
Hide

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 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.
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 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.
Git Pull Request:
https://github.com/wildfly-security/wildfly-elytron/pull/832

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.

As described in ~~JBEAP-9803~~, Undertow needs to write into ssl-context when HTTP/2 with ALPN is utilized. Maybe this might be the source of this problem?

clones

JBEAP-11084 Undertow CLIENT_CERT via Elytron and HTTP/2 does not work

Closed

Details

Description

Attachments

Issue Links

Easy Agile Planning Poker

Activity

People

Dates