Ricky's Hodgepodge

Sometimes I get surprised with the lack of information and/or documentation around wildfly and JBoss. If you search over the security documentation for wildfly, it supports several authentication mechanisms, by default BASIC, FORM, SPNEGO and CLIENT-CERT. There is no mention to bearer tokens or JWT but, surprise, surprise, the support is there and it can be used out of the box. There is very scarce documentation but you can find some examples and a quickstart about this feature.

A JSON Web Token (JWT) is an access token than contains three parts: a header, a payload and a signature. The header is just a JSON with some fixed fields (like type -jwt in this case-, algorithm of the signature or the id of the key used). The payload is the interesting part and is just any JSON with the information that the token is going to interchange, it can be any information, but things like username, roles, groups, name and surname are common. Among those fields there are two typical keys: iss or issuer and aud or audience. The issuer is who is issuing the token. The audience is for what endpoint the token was created. Wildfly implementation can be configured to check these two fields. Finally a signature of the header and payload is added to ensure that the token is valid and has not been modified (non-repudiation and integrity). In current days these tokens are ubiquitous to authenticate and authorize web services applications.

I had no idea about this feature (even more, I thought that there was no bearer authentication by default in wildfly) and I had recommended custom developments several times for this use-case. That was a wrong advise or, at least, an incomplete one. So, once I have heard about this mechanism I thouhgt that it was fair to test it and know more about how it works. This entry is going to test the new BEARER_TOKEN mechanism introduced by elytron in a wildfly 13. The JWT token is going to be provided by the keycloak project but the server is going to consume it just using elytron (no agent provided by keycloak is going to be used, just plain wildfly BEARER_TOKEN mechanism).

The steps to setup the demo are the following.

1. First download and install wildfly 13.

   
   unzip wildfly-13.0.0.Final.zip
   cd wildfly-13.0.0.Final/bin/
   ./add-user.sh -u admin -p XXXXX
   ./standalone.sh
   

   Configure with offset 10000 (keycloak will be running at default ports):

   
   ./jboss-cli.sh --connect
   /socket-binding-group=standard-sockets:write-attribute(name=port-offset, value="${jboss.socket.binding.port-offset:10000}")
   reload
   

2. Now just do the same for keycloak.

   
   unzip keycloak-4.1.0.Final.zip
   cd keycloak-4.1.0.Final/bin/
   ./add-user.sh -u admin -p XXXXX
   ./add-user-keycloak.sh -r master -u admin -p XXXXX
   ./standalone.sh
   

3. Using the keycloak administration several objects are created. First a role that will be assigned to our users. In Roles click Add Role and create a user role.

   

   Then create the user to be used with that role. Go to Users and Add user.

   

   Assign a password in the Credentials tab (non-temporary) and finally assign the user role to it.

   

   In Clients click Create and fill the wildlfy client information. This client will be used to get the token for the application (using direct login or direct grants) and with that token the wildfly endpoint will be called.

   

   When you configure a client as confidential in the second tab, Credentials, you can set a secret for the client. This password will be needed for some operations later on (for login using client credentials and to configure introspection).

   

   In the Scope tab full scope is removed and only the role user is assigned. This way the JWT token is restricted to contain only this role (if the user has it) and not all the user information.

   

   Finally a mapper is going to be configured. This part is the only tricky point of the demo. The wildfly authenticator expects the roles in a top-level field in the JWT token, but keycloak uses the claim realm_access.roles (two levels). For that reason the role list is going to be moved to a Roles field (in elytron this is the default attribute is for roles, although any another attribute can be configured using a role-decoder). Create protocol mapper in the Mappers tab.

   

4. Now that keycloak is configured, we need the certificate that is going to be used to sign the token. We can get it from keycloak in Realm Settings → Keys → RSA type → Click Certificate. Create a keystore with it. The base64 data should be enclosed with -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines to be in a PEM format (the file keycloak.pem was generated).

   
   cd ${WILDFLY_HOME}/standalone/configuration
   keytool -importcert -keystore keycloak.jks -storepass changeit -file keycloak.pem -alias keycloak -trustcacerts 
   

5. Going back to wildfly, elytron should be configured now to create a new domain using a token-realm. In a first step the realm is going to be configured to check a jwt token.

   
   /subsystem=elytron/key-store=jwt-key-store:add(type="JKS", relative-to=jboss.server.config.dir, path="keycloak.jks", credential-reference={clear-text="changeit"})
   /subsystem=elytron/token-realm=jwt-realm:add(jwt={issuer=["http://localhost:8080/auth/realms/master"], audience=["wildfly"], key-store=jwt-key-store, certificate="keycloak"}, principal-claim="preferred_username")
   /subsystem=elytron/security-domain=jwt-domain:add(realms=[{realm=jwt-realm}], permission-mapper=default-permission-mapper, default-realm=jwt-realm)
   /subsystem=elytron/http-authentication-factory=jwt-http-authentication:add(security-domain=jwt-domain, http-server-mechanism-factory=global, mechanism-configurations=[{mechanism-name="BEARER_TOKEN", mechanism-realm-configurations=[{realm-name="jwt-realm"}]}])
   /subsystem=undertow/application-security-domain=jwt-domain:add(http-authentication-factory=jwt-http-authentication)
   

   As commented before the jwt is configured to only admit access tokens that are emitted by a set of issuers and to a specific audience (it seems those two fields are optional and can be omitted). The key-store is used to reference the certificate that keycloak is going to use to sign the tokens. This way elytron will validate that the signature is valid, being sure that the token was generated by keycloak and not modified by someone else. The attribute to identify the user will be preferred_username and nothing is specified for roles, so the default Roles attribute will be used.

   Finally some debug levels are configured to check that everything is working.

   
   /subsystem=logging/logger=org.wildfly.security:add(level=ALL)
   /subsystem=logging/logger=org.wildfly.elytron:add(level=ALL)
   

6. A hello-world application is developed to use jaxrs and return the name of the logged user. The endpoint is as simple as this one.

   
   package es.rickyepoderi.sample;
   
   import javax.servlet.http.HttpServletRequest;
   import javax.ws.rs.GET;
   import javax.ws.rs.Path;
   import javax.ws.rs.Produces;
   import javax.ws.rs.core.Context;
   import javax.ws.rs.core.MediaType;
   
   @Path("hello")
   public class HelloWorld {
       
       @Context
       private HttpServletRequest request;
       
       @GET
       @Produces(MediaType.TEXT_PLAIN)
       public String world() {
           return "Hello " + (request.getRemoteUser() != null? request.getRemoteUser() : "world") + "!!!";
       }
   }
   

   In order to use the previous configuration the web.xml should use a security-constraint and the authentication method should be set to BEARER_TOKEN. Besides the user role is configured to give access to the application (this way the application is ensuring that token roles are parsed correctly).

   
   <?xml version="1.0" encoding="UTF-8"?>
   <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
            version="3.1">
       <security-constraint>
           <web-resource-collection>
               <web-resource-name>Protect all application</web-resource-name>
               <url-pattern>/*</url-pattern>
           </web-resource-collection>
           <auth-constraint>
               <role-name>user</role-name>
           </auth-constraint>
       </security-constraint>
       <login-config>
           <auth-method>BEARER_TOKEN>/auth-method>
           <realm-name>jwt-domain</realm-name>
       </login-config>
       <security-role>
           <description>Role required to log in to the Application>/description>
           <role-name>user</role-name>
       </security-role>
       <session-config>
           <session-timeout>30</session-timeout>
       </session-config>
   </web-app>
   

   In the jboss-web.xml just the domain added to undertow is configured.

   
   <?xml version="1.0" encoding="UTF-8"?>
   <jboss-web>
      <security-domain>jwt-domain</security-domain>
   </jboss-web>
   

7. Now a little test.sh is created in order to test the endpoint (you can find it inside the maven project). A curl command is executed to login and get a token using direct grants over the keycloak client. That token is sent inside the Authorization header to call the wildfly endpoint. The script is very simple but it works.

   
   bash test.sh 
   Hello ricky!!!
   

   The hello endpoint is returning my username so the token is being correctly validated and the username and roles are obtained.

8. Now let's try the introspection. The introspect is an endpoint that an OAuth 2.0 server gives to validate access tokens. This way, instead of using wildfly internal code, the container will call this endpoint to validate the access token. This has some advantages, for example, that the token is not restricted to be a JWT one.

   So now the configuration of the jwt-realm should be modified from jwt to oauth2-introspect. The elytron configuration just offers to use a username/password configuration using BASIC authentication, but, as I commented previously, this is the default authentication for a confidential keycloak client, so it should work. The username is the client name, wildfly, and the password the one generated in the Credentials tab when the client was configured.

   
   /subsystem=elytron/token-realm=jwt-realm:undefine-attribute(name=jwt)
   /subsystem=elytron/token-realm=jwt-realm:write-attribute(name=oauth2-introspection, value={introspection-url=http://localhost:8080/auth/realms/master/protocol/openid-connect/token/introspect, client-id=wildfly, client-secret=39917c0f-139a-42d2-af03-2b4207758242})
   

   And my little script continues returning the same output, therefore the introspection endpoint is validating the ticket as expected.

So, it is working. Wildfly and the new elytron subsystem has a poor documented mechanism called BEARER_TOKEN, which lets you authenticate using JWT tokens (and, developing a custom realm, can be extended to more tokens, in general, to any token sent in the Authorization header with the BEARER prefix). In this entry the keycloak single sign-on product was installed to obtain the JWT token and then a token realm was configured inside elytron to validate it. First an internal validation was done (the wildfly code checks issuer, audience and signature) and then an OAuth introspection endpoint was configured to do the same (the server just calls the endpoint to validate the token). Both configuration work. Remember that the only trick was moving the roles to first level claim (Roles in this case), that is needed because wildfly just considers attributes at first level (and keycloak adds roles by default in a more complex JSON document). After my warning some documentation is starting to come to the project.

Tokenized regards!

This is the second entry about the interoperability between wildlfy and .NET using the WS-AT (Web Service Atomic Transactions). In the previous post I explained that there was an issue between both platforms which has been addressed in wildfly during the past months (mainly a different interpretation of the standard in which both sides think they are right and the other part is wrong). The wildfly XTS setup was also done using the new asynchronous implementation. In this new entry the windows side is going to be configured. I don't like to take screenshots so I will try to minimize the use of them but, this is windows, some images are going to be necessary.

As I commented before, I am not a specialist in Microsoft (better said, I am a complete disaster with it), so please take this information as a starting point or example. The steps to configure the WS-AT in windows 2016 are the following.

1. In the previous entry some certificates were created (ca, wildfly and win2016). Now those certs are going to be installed in the windows system. Copy the ca.crt, wildfly.crt and the win2016.p12 to the windows machine. And install them using the Certificate snap-in (follow this blog post to start the application). Import the three certificates in the following locations:

   • Select Trusted Root Certification Authorities → Certificates. Right click → All Tasks → Import... And select the ca.crt.
   • Select Personal → Certificates. Right click → All Tasks → Import... And select the wildfly.crt
   • Select Personal → Certificates. Right click → All Tasks → Import... And select the win2016.p12 (the password is requested).

   Once the certificates are installed the thumbprints for the last two will be needed (the certificates for each server). So please select the certificate and double click on it. In the second tab details you have the property Thumbprint with the number for each one (in my case wildfly cert is 8DA33E3DCD937777F1D307B58A3E6E103B8F31BB and win2016 is 1c54bd1932207b4e183e732a7e42ea757b471335).

   

2. The next step is installing the visual studio 2017 community edition. I selected the option .NET desktop development (Build WPF, Windows Forms and console applications using C#, Visual Basic and F#.)

3. With visual studio installed (which contains the developer framework) WS-AT transactions are available. For that the Microsoft Distributed Transaction Coordinator (MSDTC) should be configured.

   • Execute dcomcnfg and in Componment Services → Computers → My Computer → Distributed Transactions → Local DTC, click on the right Local → more actions and select Properties.

   • In the Security tab, tick Network DTC Access, Allow Remote Clients, All Inbound, Allow Outbound, No Authentication Required, and Enable XA Transactions.

   

4. Now it's the time to configure the WS-AT endpoint. This is done with the wsatconfig utility. Start the Developer Command Prompt for VS 2017 console (the wsatconfig is not exposed in a normal cmd console). And execute the following command:

   
   wsatconfig -network:enable -port:443 -accounts: -endpointcert:1c54bd1932207b4e183e732a7e42ea757b471335 -accountsCerts:1c54bd1932207b4e183e732a7e42ea757b471335,8DA33E3DCD937777F1D307B58A3E6E103B8F31BB -traceLevel:ALL -restart
   

   This command enables network access for WS-AT on port 443 and configures the previous certificates (remember the thumbprints) to be used and admitted to communicate with the endpoint. In my case the final configuration is the following.

   

5. Finally a console application is needed to use the wildfly endpoint and the transactions. Open Visual Studio 2017 and File → New Project → Select Console App (.NET Framework). My application name is wsat-simple-client and can be download from here.

   Add a reference to System.Transactions (to be able to use WS-AT in the application).

   

   Then import the wsdl using the add service reference and selecting the WSDL of the wsat-simple application deployed in wildfly. This will create the artifacts to call the remote endpoint.

   

   Now there are two tricky steps needed (both are required to start a WS-AT transaction when calling the wildfly endpoint). The App.config should be modified to add the following stanza inside the imported binding RestaurantServiceATServiceSoapBinding (meaning that this binding requires WS-AT):

   
      <transactionFlow transactionProtocol="WSAtomicTransaction11"/>
   

   

   And the auto-generated Reference.cs of the service should also be modified, to add that the makeBooking() method needs transaction level as a mandatory requirement:

   
      [TransactionFlow(TransactionFlowOption.Mandatory)]
      void makeBooking();
   

   

   Finally the application Program.cs developed is as simple as the following.

   
   using System;
   using System.Collections.Generic;
   using System.Linq;
   using System.Text;
   using System.Threading.Tasks;
   using System.Net;
   using System.Transactions;
   
   namespace wsat_simple_client
   {
       class Program
       {
           static void Main(string[] args)
           {
               ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls |
                   SecurityProtocolType.Tls11 |
                   SecurityProtocolType.Tls12;
   
               using (ServiceReference1.RestaurantServiceATClient client = new ServiceReference1.RestaurantServiceATClient())
               {
                   using (TransactionScope scope = new TransactionScope())
                   {
                       Console.WriteLine("[Client] Invoking makeBooking() on WS");
                       client.makeBooking();
                       scope.Complete();
                   }
               }
   
               Console.WriteLine("[Client] Transaction completed OK. Click any key to finish...");
               Console.ReadKey();
           }
       }
   }
   

And everything is ready. This is the video executing the application. It calls to the wildfly endpoint but, before that, the program knows that a transaction is needed for that method and it starts a WS-AT transaction. When wildfly receives the request it registers (now asynchronously) to the transaction as a new parted and the full flow is completed. Everything works as expected and the full transaction is completed successfully performing all the calls between both sides without any issues.

Your browser doesn't support the video tag. See this entry for more information about how to see the videos in this blog. You can download the file instead.

The summary is that now there is a initial support for interaction between wildfly and .NET using WS-AT. Previously any try to execute a transaction starting it at the windows side (wildfly needed to register to the MSDTC endpoint) failed because one side executed the registration synchronously and the other part expected an asynchronous call. Now wildfly has added the asynchronous endpoints to receive the windows responses and implemented a simple logic to handle the flow. All of this will be on the next release of wildfly 14. I do not think that a lot of people is using or wanting this but I know that it was a headache for a few people in the last year. Let's see if now it starts working.

Asynchronous regards!

During the last year I have been involved in a very strange problem using Web Service Atomic Transaction (WS-AT) between Microsoft and Wildlfy. The WS-AT is an old OASIS standard to provide atomic transactions in the web between different services. The issue happened when the windows client started the transaction and a wildfly endpoint was called, in that moment the endpoint should register in the transaction and that operation failed. There was a lot of investigation and the final analysis was that the call was executed synchronously by wildfly but the Microsoft endpoint wanted it asynchronously. The standard is not very specific in this point and windows asynchronous requirement is, at least, controversial, an enhancement for wildfly was filed anyway.

In the last days the needed modifications have been included in the not yet released wildfly 14 and I decided to test it with a nightly snapshot. This entry is the wildfly setup and a continuation post will detail the windows side (much more complicated in my humble opinion). The steps to configure current snapshot are the following.

1. Download wildfly 14 (remember that now you can just download a nightly build). In my case I used the snapshot from Jun 30th 2018.

2. Install the bundle; copy the standalone-xts.xml configuration from the examples to the configuration folder; add an administrator user and, finally, start it using the xts configuration.

   
   unzip wildfly-14.0.0.Beta1-SNAPSHOT.zip
   cd wildfly-14.0.0.Beta1-SNAPSHOT
   cp docs/examples/configs/standalone-xts.xml standalone/configuration/
   cd bin
   ./add-user.sh -u admin -p XXXXX
   ./standalone.sh -c standalone-xts.xml
   

3. Configure the asynchronous registration for XTS. There is a new attribute in the XTS subsystem async-registration that should be changed to true (there is also going to be a system property to do the same in the future, mainly thinking for older versions). At the same time the server is configured to listen in all the interfaces of my laptop (the windows virtual machine should contact the server using the internal network).

   
   ./jboss-cli.sh --connect
   /interface=public:write-attribute(name=inet-address, value=0.0.0.0)
   /subsystem=xts:write-attribute(name=async-registration, value=true)
   reload
   

   This property enables two new endpoints in the XTS subsystem to receive the Microsoft responses for the registration call. Those endpoints are registered at the following locations:

   • http://localhost:8080/ws-c11/RegistrationResponseService?wsdl
   • http://localhost:8080/ws-c11/CoordinationFaultService?wsdl

4. The windows implementation requires mutual TLS authentication for the web services so it is important to create two certificates for each partner (windows and wildfly). In my environment the wildfly machine is my laptop (daredevil.sample.com/192.168.100.1) and the windows host is a 2016 essentials VM (remoteserver2.sample2.com/192.168.100.14). A CA is used to sign the two certificates for each server.

   • Generate CA cert and export it to a file.

     
     keytool -genkeypair -keystore ca.jks -storepass changeit -dname "CN=CA,O=sample,C=com" -alias ca -keyalg rsa -keysize 2048 -validity 1000 -ext BasicConstraints:critical=ca:true
     keytool -exportcert -keystore ca.jks -alias ca -file ca.crt
     

   • Generate and sign the certificate for windows. The key is generated, then a request, the request is signed with the CA and finally the CA and the signed certificate are imported into the store:

     
     keytool -genkey -keyalg RSA -alias win2016 -keystore win2016.p12 -storetype pkcs12 -storepass changeit -dname "CN=remoteserver2.sample2.com,O=sample,C=com" -validity 1000 -keysize 2048 -ext KU=digitalSignature,keyEncipherment,dataEncipherment -ext san=dns:remoteserver2.sample2.com,ip:192.168.100.14
     keytool -certreq -keystore win2016.p12 -storetype pkcs12 -alias win2016 -keyalg rsa -file win2016.csr
     keytool -gencert -infile win2016.csr -outfile win2016.crt -keystore ca.jks -alias ca -validity 1000 -keysize 2048 -ext KU=digitalSignature,keyEncipherment,dataEncipherment -ext san=dns:remoteserver2.sample2.com,ip:192.168.100.14
     keytool -import -keystore win2016.p12 -storetype pkcs12 -file ca.crt -alias ca -trustcacerts
     keytool -import -keystore win2016.p12 -storetype pkcs12 -file win2016.crt -alias win2016
     

   • Same steps for the wildfly machine.

     
     keytool -genkey -keyalg RSA -alias wildfly -keystore wildfly.jks -storepass changeit -dname "CN=daredevil.sample.com,O=sample,C=com" -validity 1000 -keysize 2048 -ext KU=digitalSignature,keyEncipherment,dataEncipherment -ext san=dns:daredevil.sample.com,ip:192.168.100.1
     keytool -certreq -keystore wildfly.jks -alias wildfly -keyalg rsa -file wildfly.csr
     keytool -gencert -infile wildfly.csr -outfile wildfly.crt -keystore ca.jks -alias ca -validity 1000 -keysize 2048 -ext KU=digitalSignature,keyEncipherment,dataEncipherment -ext san=dns:daredevil.sample.com,ip:192.168.100.1
     keytool -import -keystore wildfly.jks -file ca.crt -alias ca -trustcacerts
     keytool -import -keystore wildfly.jks -file wildfly.crt -alias wildfly
     

   • Finally copy the wildfly stores to the configuration directory:

     
     cp ca.jks wildfly.jks ${JBOSS_HOME}/standalone/configuration/
     

5. Now the certificates for wildfly are going to be installed. For that elytron is going to be configured to use HTTPS with the previously created certificates (the procedure is identical to the one followed in this previous entry).

   
   ./jboss-cli.sh --connect
   /subsystem=elytron/key-store=wildfly:add(type=jks, relative-to=jboss.server.config.dir, path=wildfly.jks, credential-reference={clear-text=changeit})
   /subsystem=elytron/key-store=ca:add(type=jks, relative-to=jboss.server.config.dir, path=ca.jks, credential-reference={clear-text=changeit})
   
   /subsystem=elytron/key-manager=wildfly-manager:add(key-store=wildfly, alias-filter=wildfly, credential-reference={clear-text=changeit})
   /subsystem=elytron/trust-manager=ca-manager:add(key-store=ca)
   
   /subsystem=elytron/server-ssl-context=wildfly-context:add(key-manager=wildfly-manager, protocols=["TLSv1", "TLSv1.1", "TLSv1.2"], trust-manager=ca-manager, want-client-auth=true)
   
   batch
   /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=wildfly-context)
   run-batch
   

   The default ssl options are also configured to use those stores when using a common WS client:

   
   /system-property=javax.net.ssl.keyStore:add(value="${jboss.server.config.dir}/wildfly.jks")
   /system-property=javax.net.ssl.keyStorePassword:add(value=changeit)
   /system-property=javax.net.ssl.trustStore:add(value="${jboss.server.config.dir}/ca.jks")
   

6. Although the asynchronous endpoints are available and running after adding the XTS property, they are not used by default. Think that two parts are needed, one is having the endpoints deployed and the other is modifying the register call to send those endpoints, transforming the call from synchronous to asynchronous. This last part is managed using the xts-properties.xml configuration file for XTS.

   Extract the default configuration xts-properties.xml from the library (jbossxts-X.X.X.jar, inside the modules folder of the wildfly installation), it's at first level inside the jar. Modify the file adding the property org.jboss.jbossts.xts.useAsynchronousRequest to SECURE (there is an example of the property but commented inside the file).

   
   <entry key="org.jboss.jbossts.xts.useAsynchronousRequest">SECURE</entry>
   

   This way the XTS implementation will use the secure endpoints (https) in the registration call and the windows counterpart will call them with the response or the fault. Move the xts-properties.xml to the configuration folder (${JBOSS_HOME}/standalone/configuration/). The following CLI commands configure it to be used (there is a java option for that) besides some logging is also added to debug the calls during the process and web services are configured to use https scheme and the correct server name by default.

   
   /system-property=org.jboss.jbossts.xts.propertiesFile:add(value="${jboss.server.config.dir}/xts-properties.xml")
   /subsystem=logging/logger=com.arjuna.wsc:add(category=com.arjuna.wsc, level=ALL)
   /system-property=org.apache.cxf.logging.enabled:add(value=true)
   /subsystem=webservices:write-attribute(name=wsdl-uri-scheme, value=https)
   /subsystem=webservices:write-attribute(name=wsdl-host, value="${jboss.bind.address:daredevil.sample.com}")
   
   

7. The sample WS-AT application that is integrated in the wildfly quickstarts is going to be used for testing. Some minor changes are needed to accommodate the code to windows. First clone the quickstart repository.

   
   git clone https://github.com/wildfly/quickstart
   cd quickstart/wsat-simple
   

   Then three modifications are done: windows prefers DOCUMENT style instead of RPC; by default Microsoft uses SOAP12, so the endpoint is tagged to be SOAP12HTTP_BINDING; finally the test client is configured to use the https endpoint in my wildfly machine (forcing https communication). Here it is my patch for the application.

   
   diff --git a/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/RestaurantServiceATImpl.java b/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/RestaurantServiceATImpl.java
   index 7f5f2f80..62afa1ab 100644
   --- a/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/RestaurantServiceATImpl.java
   +++ b/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/RestaurantServiceATImpl.java
   @@ -28,6 +28,8 @@ import javax.jws.WebService;
    import javax.jws.soap.SOAPBinding;
    import javax.servlet.annotation.WebServlet;
    import java.util.UUID;
   +import javax.xml.ws.BindingType;
    
    /**
     * An adapter class that exposes the RestaurantManager business API as a transactional Web Service.
   @@ -38,7 +40,8 @@ import java.util.UUID;
    @WebService(serviceName = "RestaurantServiceATService", portName = "RestaurantServiceAT", name = "RestaurantServiceAT",
        targetNamespace = "http://www.jboss.org/jboss-jdf/jboss-as-quickstart/wsat/simple/Restaurant")
    @HandlerChain(file = "/context-handlers.xml", name = "Context Handlers")
   -@SOAPBinding(style = SOAPBinding.Style.RPC)
   +@SOAPBinding(style = SOAPBinding.Style.DOCUMENT)
   +@BindingType(value = javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_BINDING)
    @WebServlet("/RestaurantServiceAT")
    public class RestaurantServiceATImpl implements RestaurantServiceAT {
    
   diff --git a/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/jaxws/RestaurantServiceAT.java b/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/jaxws/RestaurantServiceAT.java
   index c2bc4bb2..39d3bda2 100644
   --- a/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/jaxws/RestaurantServiceAT.java
   +++ b/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/jaxws/RestaurantServiceAT.java
   @@ -20,6 +20,7 @@ import org.jboss.as.quickstarts.wsat.simple.RestaurantException;
    import javax.jws.WebMethod;
    import javax.jws.WebService;
    import javax.jws.soap.SOAPBinding;
   +import javax.xml.ws.BindingType;
    
    /**
     * Interface to a simple Restaurant. Provides simple methods to manipulate bookings.
   @@ -27,7 +28,8 @@ import javax.jws.soap.SOAPBinding;
     * @author paul.robinson@redhat.com, 2012-01-04
     */
    @WebService(name = "RestaurantServiceAT", targetNamespace = "http://www.jboss.org/jboss-jdf/jboss-as-quickstart/wsat/simple/Restaurant")
   -@SOAPBinding(style = SOAPBinding.Style.RPC)
   +@SOAPBinding(style = SOAPBinding.Style.DOCUMENT)
   +@BindingType(value = javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_BINDING)
    public interface RestaurantServiceAT {
    
        /**
   diff --git a/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/servlet/WSATSimpleServletClient.java b/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/servlet/WSATSimpleServletClient.java
   index 015885ce..58ff26d7 100644
   --- a/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/servlet/WSATSimpleServletClient.java
   +++ b/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/servlet/WSATSimpleServletClient.java
   @@ -55,7 +55,7 @@ public class WSATSimpleServletClient extends HttpServlet {
    
        private static final long serialVersionUID = -8314035702649252239L;
    
   -    @WebServiceRef(value = RestaurantServiceATService.class)
   +    @WebServiceRef(value = RestaurantServiceATService.class, wsdlLocation = "https://daredevil.sample.com:8443/RestaurantServiceAT?wsdl")
        private RestaurantServiceAT client;
    
        @Override
   

   Finally just package the application and deploy the resulting wsat-simple.war file in the wildfly server.

   
   mvn clean package
   

And that is all. The wildfly application should work locally in the server. The video shows how you can go to the https port (application is deployed in / by default) and the local client is used to start a WS-AT call to the same server (both client and server are inside the wildfly server). The client starts the transaction and the ws endpoint registers asynchronously against the coordination endpoints inside the same server. The successful page is shown saying the transaction was completed with no issue. You can check the logs to see that the registration call was made contacting to the new asynchronous endpoints (the ReplyTo is filled with the new async URL and the response is received to that endpoint).

Your browser doesn't support the video tag. See this entry for more information about how to see the videos in this blog. You can download the file instead.

The most interesting part is left for the next entry. A .NET application will be integrated to call the WS-AT endpoint in the wsat-simple application. In turn the wildfly web service will call the windows coordination endpoint (which require asynchronous calling) to be registered as a partner in the transaction. The configuration of both sides is not trivial so I prefer to divide the entry in two parts. I have the demo working but I need to collect some screenshots for the windows configuration (I am sorry in advance about the Microsoft part, please consider I never use windows and every time I have to work with it the results are a big mess).

Asynchronous regards!