Skip navigation
All Places > Alfresco Process Services & Activiti (BPM) > Blog > 2018 > July

Last week we manage to finish and polish the second round on the APIs refactoring and we attended an AWS 2 days training for cloud deployments. We already started a third iteration around the Java Runtime APIs related to security, security policies and further refinements on usability. This week we will be moving forward this work to close Beta1 release. We are also doing some testing on Pivotal PKS to validate that our HELM charts are supported across different cloud providers.


@igdianovworked on a PoC for Activiti Cloud

@almericoWorking on running latest runtime-bundle and Activiti cloud infrastructure with latest JenkinsX release.

@daisuke-yoshimotoworked on

@miguelruizdevworked on activiti-cloud-acceptance-tests, adding a new security policies module and refactoring default process definitions and users to specific ones. Attended AWS training.

@balsarorihelped with some extensions to the engine APIs to support Owner queries for tasks.

@mteodorifixed Batik vulnerability

@constantin-ciobotaru- holidays -

@ryandawsonukAdded a connector process to the example-runtime-bundle and a connector chart to activiti-cloud-charts then tested the example connector image. Started working with @miguelruizdevto improve the acceptance-tests with some refactoring to support adding tests for security-policies and for the example connector scenario. Attended AWS + EKS training.

@erdemedeirosworked with @salaboy on the next iteration for the Java API. Added Activiti Spring Boot starter to Activiti/Activiti. Attended AWS + EKS training.

@salaboyworked on the 3rd round of refactorings for the API, now focused on security and security policies. Attended AWS + EKS training.


Get in touch if you want to contribute:

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request ;)

Last week we merged the initial refactoring of the Java Runtime APIs into our develop branches of our projects. We also merged updates on our example projects, quickstart and acceptance tests. The BluePrint TTC project is still due to be migrated to use the latest versions. Now, the Activiti Cloud HELM charts are consuming these images published in Docker Hub and we recommend people to try them out and get in touch via Gitter in case of issues. We will be working on stabilizing all surrounding projects for the Beta release and updating documentation accordingly.


@igdianovworked on improving connectors and async tasks for internal PoC.

@almericocluster infrastructure configuration and helm updates

@daisuke-yoshimotoworked on internal issues and Audit Mongo DB API upgrade.

@miguelruizdevimplemented awaitility features in the contexts within the acceptance test that need time orchestration; kept testing Activiti services, running the acceptance tests in a Jenkins X environment.

@constantin-ciobotarufinished and pushed the code in organization for repository abstraction and the api, updated the modeling acceptance tests to use only interfaces from api

@ryandawsonukAdded tests to activiti-cloud-audit-service to cover different security policies scenarios and fixed a bug related to hyphens when setting security policies using environment variables. Worked with @miguelruizdev to run the acceptance tests and introduce awaitility to wait for test conditions to be met. Changed the charts in activiti-cloud-charts to provide a way to switch between h2 and postgres.

@erdemedeiros- holidays -

@salaboyworked on upgrading the Acceptance Tests to support the new APIs and on deployments to Kubernetes using our new Activiti Cloud HELM Charts.


This week we will be working hard on stabilizing examples and doing final refactorings at the API level. A blog post about the new API is being created, but it will probably see the light next week.


Get in touch if you want to contribute:

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request ;)

Last week we moved forward the new APIs refactoring to all of our services and extensions. We started validating the new data types and exposed endpoints against our existing acceptance tests and we are a couple of tests away to finalize the first round of refactorings which will enable us to merge all the changes into the develop branch. Our Docker Compose Quickstart was updated and simplified for people that wants to start testing our building blocks.


@igdianovworked on GraphQL upgrade modules to use new API data types and introduced a new graphQL query spring boot starter

@almericocluster configurations and charts improvements.

Worked on https configuration support in jx environment.

@daisuke-yoshimotoworking on MongoDB upgrade to use new APIs data types

@miguelruizdevtested Activiti services following the docker-compose approach as well as the Jenkins X one; updated the Postman Collection with admin endpoints and use case sub-collections.

@constantin-ciobotaruworked on modeling organization: moved abstract repository layer to a separate module, add an api module with Application and Module abstract interfaces for entities, force rest layer to use json deserializer for Application and Module interface, remove connection from rest and jpa modules and use from rest layer only api and repository modules, update acceptance tests

@ryandawsonuk- holidays -

@erdemedeirosmoved commands (StartProcess, ClaimTask, CompleteTask, etc) to the Java API level. Made sure that acceptance tests are using the customized ObjectMapper which contains all the interface mappings.

@salaboyworked on acceptance tests for the new API refactorings and deployed all new refactored services to a Kubernetes Cluster to validate new behaviour.


This week we will finish the missing acceptance tests and work on the complete automation of the execution of these tests including Security Policies scenario checking and new assertions to verify eventual consistency.


Get in touch if you want to contribute:

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request ;)

Last week we started a new testing round for our Kubernetes Deployments after the initial refactoring to use the new APIs. We are getting better and better into testing large refactorings for distributed deployments and we are looking forward to release Beta1 after this round of testing is finished. We will start by releasing only the Java artifacts to maven central, then we will continue with updating documentation and releasing our example docker images so they can be consumed from our HELM charts. Acceptance tests will be also part of our released artifacts, so you can run or modify them to test different scenarios. A warm welcome to our community to @almericowho is working hard to reduce the configuration points for our deployments.


@igdianov- on holidays -

@almericoWorking on configuration of helm charts and possibility to run everything on one ingresses with exposecontroller to reduce manual configuration.  

@daisuke-yoshimotoworking on updating the MongoDB implementation to support new APIs

@MiguelRuizDevtesting new API refactoring in Jenkins X

@constantin-ciobotaruworked on organization: removed group concept and refactored projects to applications concept, updated acceptance tests for modeling accordingly, added acceptance tests for updating application name, deleting application.

@ryandawsonukProduced helm charts published at activiti chart repoand configured JX example to use the charts for application and infrastructure components so that the user doesn’t need to build them. We’re refining this setup for a new quickstart.

@erdemedeirosmoved integration related interfaces to the API level. Cleaned up unused classes from the runtime-bundle after the introduction of the new API.

@salaboyworked on updating new example services to consume the new APIs and troubleshoot new issues and missing bits.

This week we will merge the API refactoring to our Develop branch and finalize the testing round to proceed to release early next week. Right after the release, we will update our roadmap and provide more insights about what it is coming before the end of the year. 

Get in touch if you want to contribute:

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request ;)

Alfresco Process Services v1.9 released a few weeks ago introduced a new authentication module which is based on an open source IAM project called Keycloak which provides a wide range of authentication options! Since Keycloak supports X.509 Client Certificate User Authentication natively, the moment APS 1.9 was announced, I purchased a smart card called Yubikey which supports Personal Identity Verification (PIV) (FIPS 201, a US government standard) to test the X.509 support of Keycloak. This blog is to help Alfresco customers and/or partners looking to implement PIV authentication on Alfresco platform. The steps involved in getting this to work end-end are:

Please note that the steps in this blog is based on my experiments on my macOS. If you are not a macOS user you may want to adjust some of the config steps to match your OS

Generate SSL Certificates

The first step is to create the following certificates:

  • Server certificate issued and signed by an “Intermediate CA” which will be used to secure both Keycloak and APS apps.
  • Client certificate which can be used to authenticate the user. This client certificate will be loaded into the PIV smart card

In production scenarios, it is recommended to use internationally trusted CAs (eg: VeriSign) to sign your server and client certificates. Every organization will have best practices in place around certificate issuing and usage, so if you need SSL certificates to secure your apps, check with your security team first! For the purpose of this blog, I’ll be creating root & intermediate CAs by myself. The intermediate CA will be used to sign both the client and server certificates on behalf of the root CA.


Please follow the instructions in my GitHub repo to generate the following certificates which will be required for the subsequent sections of this blog:

  • Root CA pair
    • Root CA certificate - openssl-cert-gen-template/certs/ca.cert.pem
    • Intermediate CA key -  openssl-cert-gen-template/private/ca.key.pem
  • Intermediate CA pair
    • Intermediate CA certificate - openssl-cert-gen-template/intermediate/certs/intermediate.cert.pem
    • Intermediate CA key - openssl-cert-gen-template/intermediate/private/intermediate.key.pem
  • Client & server certificate
    • Client certificate - openssl-cert-gen-template/intermediate/certs/admin.cert.pem
    • Client key - openssl-cert-gen-template/intermediate/private/admin.key.pem
    • Server certificate - openssl-cert-gen-template/intermediate/certs/localhost.cert.pem
    • Server key - openssl-cert-gen-template/intermediate/private/localhost.key.pem
  • Certificate keystore - openssl-cert-gen-template/keystore/keystore.jks
  • CA truststore - openssl-cert-gen-template/truststore/truststore.jks

Configure Alfresco Process Services

Configure APS for SSL

Enable the HTTPS Connector in tomcat/conf/server.xml using the keystore created in the above mentioned “Generate SSL Certificates” section. My connector config on tomcat version 8.5.11 looks like below:


           port="8443" maxThreads="200"
           scheme="https" secure="true" SSLEnabled="true"
           clientAuth="false" sslProtocol="TLS"/>


Configure APS for Keycloak Authentication

APS version 1.9 added a new way of authentication based on Keycloak 3.4.3. I’m not going to go through the configuration details here, so please refer APS identity service documentation & APS 1.9 blog for more details on this configuration. Once APS is configured with Keycloak, the authentication flow will be driven by the configurations you make on the Keycloak server. My configuration file in APS is shown below:


# --------------------------
# --------------------------

# set to false to fully disable keycloak


Configure Yubikey (PIV/Smart Card)

I’m using a Yubikey Neo as the PIV smart card where I’ll load my client authentication certificate which will be used to login to APS. The smart card configuration steps are basically based on Yubikey documentation which you can find here.

Install Yubico PIV Tool

The Yubico PIV tool allow you to configure a PIV-enabled YubiKey through a command line interface. Download this tool and use the following commands to load the certificate and key into the authentication slot 9a of your smart card. You may need to configure the device and set a management key to run the following commands. The device setup instructions can be found here.

Commands to load the client certs into Yubikey

# Set pivtool home and openssl-cert-gen-template directories

# Import Certificate
$pivtool_home/bin/yubico-piv-tool -k $key -a import-certificate -s 9a < $cert_dir/intermediate/certs/admin.cert.pem

# Import Key
$pivtool_home/bin/yubico-piv-tool -k $key -a import-key -s 9a < $cert_dir/intermediate/private/admin.key.pem

Verify certificates using YubiKey PIV Manager

This is an optional step. The YubiKey PIV Manager enables you to configure a PIV-enabled YubiKey through a graphical user interface. Once the certificate and key is imported, you can verify the imported certificates via this utility. The installer can be found here. When a certificate is successfully loaded into the authentication slot of your Yubikey, the PIV manager will display it as shown below.


Verify certificates using YubiKey PIV Manager

Browser Configuration

Install OpenSC

As you can see from the OpenSC wiki page, this project provides a set of libraries and utilities to work with smart cards. Since I’m using a Mac, I followed the instructions on this page to get it installed using the DMG file provided by OpenSC

Configure Browser

Though I am a Chrome user, I used Firefox (version 60.0.2)  for testing the Smart Card Authentication into APS.

If you really want to test this on Chrome, you can use the Smart Card Connector Chrome app to test this. Though this app is intended for Chrome on Chrome OS, it worked for me on my Mac too. However it may prompt you for the Yubikey admin pin too many times which is quite annoying!

My recommendation is to install Firefox and configure Firefox with the OpenSC PKCS11 module as explained below!

Preferences -> Privacy & Security -> Security Devices -> Load

  1. Module name -> “PKCS#11 Module”
  2. Module filename -> “/Library/OpenSC/lib/” (installed as part of the OpenSC installation above) 

Import the root and intermediate CAs openssl-cert-gen-template/certs/ca.cert.pem & openssl-cert-gen-template/intermediate/certs/intermediate.cert.pem respectively via Preferences -> Privacy & Security -> View Certificates -> Authorities -> Import so that the browser will trust servers configured with certificates issued by these CAs

Configure Keycloak

First step is to install Keycloak 3.4.3 as documented here. The Keycloak documentation is quite detailed, hence I’m not going to detail it out here again. In the next few sections, I’ll go through the X.509 specific configuration of Keycloak which is essential to get this working!

Configure Keycloak for two-way/mutual authentication

For more details on X.509 client certificate authentication configuration, please refer enable-x-509-client-certificate-user-authentication.

  • Copy the openssl-cert-gen-template/keystore/keystore.jks & openssl-cert-gen-template/truststore/truststore.jks files to $KEYCLOAK_HOME/standalone/configuration.
  • Open the standalone.xml file and add the following ssl-realm to management/security-realms group in the xml.
<security-realm name="ssl-realm">
             <keystore path="keystore.jks" relative-to="jboss.server.config.dir" keystore-password="keystore"/>
        <truststore path="truststore.jks" relative-to="jboss.server.config.dir" keystore-password="truststore" />
  • Add a https-listener to the profile/subsystem[xmlns='urn:jboss:domain:undertow:4.0']/server[name="default-server"] in the standalone.xml
<subsystem xmlns="urn:jboss:domain:undertow:4.0">
    <server name="default-server">
             <https-listener name="https" socket-binding="https" security-realm="ssl-realm" verify-client="REQUESTED"/>
  • Start Keycloak standalone using the command “$KEYCLOAK_HOME/bin/ -Djboss.socket.binding.port-offset=100 -b” which will start the server by offsetting the default ports by 100. This is helpful to avoid port conflicts on your localhost. With this command, the https port will become 8543 instead of default 8443.

Configure Keycloak authentication flows

Login to Keycloak by going to https://localhost:8543/ (admin/admin) is the default admin user credentials. Add a new user with a username that matches with the certificate attributes. Username “admin” and email “” by going to Keycloak -> <your realm> -> Users -> Add user

Configure Direct Grant

Configuring direct grant is the easiest way to verify the configuration. For more details refer adding-x-509-client-certificate-authentication-to-a-direct-grant-flow. Screenshots below:

Configure Direct Grant Flow


Configure Direct Grant

Configure Browser Flow

The following screenshots will show how to configure the browser flow to use X.509 authentication. For more details, please refer adding-x-509-client-certificate-authentication-to-a-browser-flow. Screenshots below:

Configure Authentication Bindings


Direct Grant

Use the following command to test the direct grant (please change the certificate path as per your configuration). For more details refer adding-x-509-client-certificate-authentication-to-a-direct-grant-flow


curl https://localhost:8543/auth/realms/alfresco/protocol/openid-connect/token \
      --insecure \
      --data "grant_type=password&scope=openid profile&client_id=aps&client_secret=5323135f-36bb-46c4-a641-907ad359827a" \
      -E /Users/cijujoseph/openssl-cert-gen-template/intermediate/certs/admin.cert.pem \
      --key /Users/cijujoseph/openssl-cert-gen-template/intermediate/private/admin.key.pem


Browser Auth Demo

Insert the smart card into your computer and test the browser authentication flow as shown in the below video




Special thanks to the following references!

Last week we spend some time closing the final details of the Java Runtime API and improved our support for Events and Base Data Types to make sure that our services can be completely decoupled. We are looking forward to close this release to continue our journey to continuous deployment of each of our component in an independent way.

@ryandawsonuk, @igdianovand @almericoworked on improving our deployment mechanisms by creating new HELM charts for Applications and Infrastructure. This should enable us to deploy our components to different Cloud Providers such as: Google Cloud Engine, Openshift, EKS (Amazon), AKS (Microsoft) and PKS (Pivotal).


@igdianovand @almericoworked on improving HELM charts and deployments of community bits as well as adding more flexibility to the GraphQL extension for the Query Service

@daisuke-yoshimoto is working on updating Audit Service implementation for MongoDB to fit the new interface of Audit Service API.

@MiguelRuizDevfollowed the Cloud Native in Kubernetes Workshop, getting a high-level understanding of the technologies taking part in it, especially the structure that holds a cloud native application together.

@constantin-ciobotarudiscussions and plans for refactoring organization service in modeling

@ryandawsonukAdded demo-ui to the quickstart based on Jenkins-X and got this working with gateway and keycloak, including CORS configuration. Identified an issue with the graphql part of query. Did a POC on publishing docker images to dockerhub from Jenkins-X.

@erdemedeirosrefactored Java API event listeners: use generics to specify the event type instead of having methods for all the events in the same interface (no empty methods anymore when implementing a event listener). Covered all the missing events currently supported by the runtime bundle (except integration requests) using the new Java API model.

@salaboyupdated the Audit & Query Service to use the new Java Runtime API types for Rest Controllers and Event Handlers.

This week, we will move the new Java Runtime APIs to the main we will start preparing all Java Modules to be released to Maven Central.

Get in touch if you want to contribute:

We are looking forward to mentor people on the technologies that we are using to submit their first Pull Request ;)