[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka updated JBJCA-1329:
-----------------------------------
Attachment: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Jesper Pedersen
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka moved JBTM-2741 to JBJCA-1329:
----------------------------------------------
Project: IronJacamar (was: JBoss Transaction Manager)
Key: JBJCA-1329 (was: JBTM-2741)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Component/s: Core
(was: JTA)
(was: JTS)
(was: JCA)
Affects Version/s: WildFly/IronJacamar 1.3.4.Final
(was: 5.3.3.Final)
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1726:
------------------------------------------
The/subsystem=logging/log-file=*:read-attribute(name=stream) problem seems like a general one, outside of batches. The --file attribute points to a single file but that op returns multiple streams.
Perhaps that could just be a documented limitation. If an individual 'attachment' operation (by itself or in a batch) returns > 1 stream. we'll just save/display 1. Probably the first one encountered when reading the response for that step. Instead of doing a wildcard requests people can write scripts to read the children names and then iterate over the result to read the files.
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1726:
----------------------------------------------
Yes, the high level command that wraps the operation covers all cases. It seems to offer the best user experience both in interactive and not interactive mode.
The issue I have is related to batch mode. The composite operation aggregates all streams in the headers. We loose the operation<=>streams relationship. So even if we could callback onto each high level command associated to each step, we would be not able to provide it with the right set of streams. Basing the matching on the step index will not work, we can have operation that returns multiple streams e.g: /subsystem=logging/log-file=*:read-attribute(name=stream)
So for now, although the high level approach seems interesting, I am stuck to find a general solution...
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1726:
------------------------------------------
:)
My concern with a high level command based approach is it would lead to a bunch of high level commands, one per use case. But you've identified a neat way to avoid that.
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6999) client authentication not behaving correctly?
by Pascal Knüppel (JIRA)
[ https://issues.jboss.org/browse/WFLY-6999?page=com.atlassian.jira.plugin.... ]
Pascal Knüppel updated WFLY-6999:
---------------------------------
Description:
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>-->
<!--<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.
was:
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.
> 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>-->
> <!--<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)
9 years, 10 months
[JBoss JIRA] (WFLY-6999) client authentication not behaving correctly?
by Pascal Knüppel (JIRA)
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)
9 years, 10 months