11:10 a.m.
Pascal Knüppel created WFLY-6999:
------------------------------------
Summary: client authentication not behaving correctly?
Key: WFLY-6999
URL: https://issues.jboss.org/browse/WFLY-6999
Project: WildFly
Issue Type: Bug
Affects Versions: 9.0.2.Final
Environment: Windows 7 with Java 8_91 and Wildfly 9.0.2
Reporter: Pascal Knüppel
Assignee: Jason Greene
I am currently reading the wildfly 9 documentation and I started to test some things and I
began with client certificate authentication since I am going to need this feature in
short future.
I found a way to realize mutual authentication but this one is rather a workaround than
anything else.
For starters it is my intention to deploy a web application on an https-port that requires
client authentication. Additionally I want other applications under the same port that do
not require client authentication. This is a feature that does not seem to be possible
eventhough the documentation uses references to the security-domain section here.
Now I will provide my configuration how I configured my application and my wildfly server
to activate client cert authentication. Note that I had to configure a second virtual host
with a new port to accomplish this.
*web.xml*
{code:xml}
<security-constraint>
<display-name>secure</display-name>
<web-resource-collection>
<web-resource-name>test</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<description>Die Kommunikation soll ausschließlich über HTTPS
stattfinden.</description>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<!--<login-config>-->
<!--<!– Es wird erwartet, dass der Client sich mittels
X509-Zertifikat dem Server gegenüber authentifiziert. –>-->
<!--<auth-method>CLIENT-CERT</auth-method>-->
<!--<!–<realm-name>secured-app-domain</realm-name>–>-->
<!--</login-config>-->
{code}
*jboss-web.xml*
{code:xml}
<jboss-web>
<server-instance>client-auth-server</server-instance>
<virtual-host>client-auth-host</virtual-host>
<!--<security-domain>secured-app-domain</security-domain>-->
</jboss-web>
{code}
*standalone.xml*
{code:xml}
...
<security-realm name="SSLRealm">
<server-identities>
<ssl>
<keystore path="gfi.jks"
relative-to="jboss.server.config.dir" keystore-password="pw" />
</ssl>
</server-identities>
<authentication>
<truststore path="gfi.jks"
relative-to="jboss.server.config.dir" keystore-password="gfi"/>
</authentication>
</security-realm>
...
<server name="default-server">
<http-listener name="default" socket-binding="http"
redirect-socket="https"/>
<https-listener name="tls" socket-binding="https"
security-realm="SSLRealm"/>
<host name="default-host" alias="localhost">
<location name="/"
handler="welcome-content"/>
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
</server>
<server name="client-auth-server">
<https-listener name="secured-https"
socket-binding="client-auth-https" security-realm="SSLRealm"
verify-client="REQUIRED"/>
<host name="client-auth-host"
alias="localhost">
<location name="/"
handler="welcome-content"/>
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
</server>
...
<socket-binding name="client-auth-https"
port="${jboss.https.port:8444}"/>
{code}
This is everything needed for client-authentication if roles are not necessary. In case of
using roles I had to add the uncommented security-domain not listed in the above code.
Now to the point:
this configuration seems undesirable to me and I am not sure if this is really wanted like
this... as you can see in *web.xml* the tag <login-config> is uncommented. This
configuration is completely ignored if set. The tag <realm-name> seems to have no
effect either. I can write in this field what I want it changes nothing. So I did some
more research and figured that the actual correct settings should be set like this:
*web.xml*
{code:xml}
<security-constraint>
<display-name>secure</display-name>
<web-resource-collection>
<web-resource-name>test</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<description>Die Kommunikation soll ausschließlich über HTTPS
stattfinden.</description>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<!-- Es wird erwartet, dass der Client sich mittels X509-Zertifikat dem Server
gegenüber authentifiziert. -->
<auth-method>CLIENT-CERT</auth-method>
<!--<realm-name>secured-app-domain</realm-name> NO IDEA WHAT THIS
SHOULD ACCOMPLISH -->
</login-config>
{code}
*jboss-web.xml*
{code:xml}
<jboss-web>
<security-domain>secured-app-domain</security-domain>
</jboss-web>
{code}
*standalone.xml*
{code:xml}
...
<security-realm name="SSLRealm">
<server-identities>
<ssl>
<keystore path="gfi.jks"
relative-to="jboss.server.config.dir" keystore-password="pw"/>
</ssl>
</server-identities>
</security-realm>
...
<security-domain name="trust-domain">
<jsse truststore-password="pw"
truststore-url="file:${jboss.server.config.dir}/gfi.jks"
client-auth="true"/>
</security-domain>
<security-domain name="secured-app-domain">
<authentication>
<login-module code="Certificate"
flag="required">
<module-option name="securityDomain"
value="trust-domain"/>
</login-module>
</authentication>
</security-domain>
...
<server name="default-server">
<http-listener name="default" socket-binding="http"
redirect-socket="https"/>
<https-listener name="tls" socket-binding="https"
security-realm="SSLRealm"/>
<host name="default-host" alias="localhost">
<location name="/"
handler="welcome-content"/>
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
</server>
...
{code}
This configuration should work based on this article
[https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Applicatio...]
but the configuration is completely ignored and I have access to my application without
any certificates imported to my browser. Can anyone explain this behaviour it just does
not seem correct to me.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)