My personal look at the German eID system (“Neuer Personalausweis”)

Business Problem

Many business processes in Germany involve paper (or better TONS OF PAPER!) and surely many manual steps: think of opening a bank account or registering a car at your local “Zulassungsstelle”. In my opinion one of the main reasons for that is that the identity of a user cannot be properly verified online. You could now argue that things like video identification or Deutsche Post PostIdent came up to address this problem. However this only solves part of the problem, since the signature still needs to be done manually.

In Germany the so called nPA (neuer Personalausweis) is able to solve this problem by providing a qualified signature. So you will be able to digitally sign contracts online. Therein lays the potential to completely transform tons of paper-based processes. And huge amounts of time and money could be saved as well!


Use cases of the eID system

The nPA has two main functions “Identification with Online-Ausweisfunktion” and “Electronic Signature”, which allow to implement many exciting use cases. These range from simple verifications (like age check, address validation) to login mechanisms for websites (the nPA can be considered as a single-sign-on system in this context). Moreover the nPA also allows to apply a qualified digital signature to documents, which is equal to a genuine signature (according to German law).

Since its launch in 2010 a couple of federal institutes and enterprises have made their services ready for the nPA:

  • ElsterOnline (German tax)
  • Rentenkonto online (German pension fund)
  • Punkteauskunft aus dem Verkehrszentralregister (VZR)
  • UrkundenService
  • Allianz Kundenportal

A complete list of applications can be found here: However, from my perception the adoption still leaves a lot of room for improvement.

Architectural overview

There is extensive documentation available which describes the technical architecture behind the eID system (personally I recommend the information from BSI found here: That it why I do not want to go into the nitty gritty details.

However, to give you a rough understanding have a look at the following illustration, which looks similar to what is available in token based authentication systems (think of SAML and/or OpenID Connect concepts). There is something like a service provider (“WebServer”) who wants to protect a service; then an authority that is able to validate the identity (“eID-Server”); and a login component (“AusweisApp”) that allows the end user to enter login information like a PIN. Last but not least the user must have a card reader connected to his local system, which talks to the login component (“AusweisApp”).


It is important to understand that the login component (“AusweisApp”) is implemented as a standalone application, which must run on the user’s computer (and of course be installed beforehand). For 2017 it is planned to release mobile versions of the app (see Google Play Store) in order to use a mobile device as a card reader. In my opinion this will help to reduce the overall complexity from an end user’s perspective.

When looking at the system from a service provider’s point of view (e.g. I am an online shop provider who wants to enable users to login with their nPA), you have to consider a lot of things. Since their is neither a public instance of the “eID-Server” nor source code available, you have two options: create your own implementation based on the BSI spec or buy the service from a provider. Additionally you will have to think of how to integrate the token into your application: since there is no “reference implementation” of the “eID-Server” spec there is little to no documentation available. Overall the process feels rather complex and intransparent to me.

A detailed description of the application process can be found here: “Become Service Provider”.


The opportunity behind the German eID system is really huge and could speed up lots of processes and make all of our lives easier. But in my opinion there are a lot of things hindering the adoption and success of the system:

  1. There is no public eID-Server instance that can be used by public and private institutions. This makes the adoption unnecessarily complicated because all service providers have to find a solution for themselves.
  2. Little documentation for service providers available. Instead only tons of specs available that need a lot of work lifted by the service provider.
  3. Many services require that you map your eID to the identity in their system (at least once). This makes the process very uncomfortable for the end user.
  4. Currently an external card reader is needed. Firstly it has to be bought by the end user and secondly this does not work on the go. Fortunately this caveat has already been addressed with the mobile app version.

My final thoughts: the adoption cannot be forced by laws. Instead, I think that the eID system should be developed in a more transparent and community based manner. Moreover the integration by service providers should be as easy as putting a social login on my personal website.


JBoss Mobile Publications

Faster and more efficient processes by combining BPM and Mobile

A. Synopsis

What this is about

A lot has happened in the area of mobile since Apple kicked off the revolution by announcing the first iPhone. However, the overall mobile market still has to be considered as young and especially unstandardized. This really puts a lot of organizations in front of huge challenges concerning the efficient development of mobile applications and the secure integration into backend IT systems.

But there is no way around mobile in the next years! The smart combination of mobile techniques (MBaaS, micro services, etc.) and business process management approaches will definitely drive process efficiency and speed to a whole new level.

The use case or “What if the process was at the fingertips of your customer?”

This showcase addresses a scenario that almost all enterprises in the insurance industry are facing: nowadays users expect to be able to contact their insurance 24/7 on an ad-hoc basis (e.g. for opening a claim or just for asking a question concerning their policy). Additionally they want to see on demand what the status of a certain request is. From an enterprise point of view insurances are looking at new ways on reacting to this new speed of communication and transparency. They’re also thinking of new concepts to efficiently integrate agencies and remote workers in their existing processes. They key consequence to address these requirements is to enhance existing input & output management infrastructure by a newly established mobile channel.

In this showcase we used Red Hat Mobile Application Platform ( as a key building block to efficiently and securely connect the outside world with existing enterprise systems.


Through the platform approach we do not need to reinvent the wheel for each mobile app on the horizon. Instead we put in place a centralized platform for developing and running mobile application in a standardized manner.

The use of Red Hat Mobile Application Platform (RHMAP) comes with the following benefits:

  • Agile approach to developing, integrating, and deploying enterprise mobile applications—whether native, hybrid, or on the web
  • Out-of-the-box automated build processes (including build farm)
  • A service catalog for reusable connectors to backends
  • Easy scale-out through cloud native architecture
  • Collaborative development across multiple teams and projects with a wide variety of leading tool kits and frameworks

Architectural overview

From a technical point of view the showcase is comprised of three main building blocks:

  • CLIENT LAYER: Hybrid mobile applications running on the end user devices
  • CLOUD LAYER: Node.js based backend running in the cloud on RHMAP
  • BACKEND LAYER: Set of business process applications running on JBoss BPM Suite as the underlying BPM engine

ARC_OVERVIEW - Component model

Client layer

Since we have two different user groups (external end customer and employees) we’ve decided to develop two separate applications:

  • Customer App: This app is meant to be used by our end customers (using a broad range of different mobile devices) and has therefore being implemented especially with hybrid app development principles in mind. We chose Apache Cordova ( as our core development framework, which enables us to build our app against all common mobile OS with only one code base (“develop once, run everywhere” principle). In terms of the UI and application framework we decided to go for a combination of ionic ( and AngularJS ( Both projects have a vibrant and active community and have been successfully adopted by many projects.

  • Employee App: This app targets remote workers (such as insurance agencies e.g.) who shall work on our processes from remote. We’ve decided to go for the same hybrid app approach in order to share code and speed up development. However, for such an end user group where we might influence the use of certain device types (such as Apple iPhone) we could have also thought about a native app (RHMAP provides an SDK for all popular mobile OS; so we could also reuse existing backend functionality in our cloud layer).

The source code of both applications is hosted on RHMAP which allows us to make use of the built-in build farm (allowing us to create push button builds for iOS, Android et al), configure and also preview the application.

Client application in RHMAP

Cloud layer

The cloud part of an application built with RHMAP is comprised of a so called “Cloud Code App” providing the core functionality for our clients and a set of reusable MBaaS services that enable the connectivity to 3rd party (backend) systems. The following illustration shows an overview of all components created for our showcase:

Application overview in Red Hat Mobile Application Platform

Cloud code apps

For our showcase we’ve implemented a single Node.js based app called Cloud App which accepts all incoming requests from our client layer. RHMAP provides a feature rich development framework (including custom Node.js convenience modules) making the creation of cloud code apps easy and efficient. Through the use of Node.js as our programming language we get all the benefits of its evented and asynchronous model, that works extremely well with our use case of a data intense realtime application (DIRT paradigm).

MBaaS services (Mobile backend as a service)

An MBaaS (Mobile Backend-as-a-Service) is the primary point of contact for end user applications – both mobile and web. The MBaaS hosts Node.js applications – as REST API servers and/or Express.js based web apps. The primary purpose of the MBaaS is to allow users (developers) of RHMAP to deploy Node.js server-side for their mobile apps. The MBaaS also provides functionality such as caching, persistence, data synchronization and a range of other mobile-centric functionality. Multiple MBaaS may be utilized for customer segregation and/or lifecycle management (environments).

For this showcase we’ve developed a new MBaaS connector called fh-connector-jbpm-cloud, which is meant to be reused across multiple applications hosted on RHMAP. For the use in our project we’ve instantiated it and configured the environment variables to connect to our specific JBoss BPM Suite in the backend layer.

RHMAP MBaaS BPM connector

Function wise the MBaaS connector currently provides the following functionality:

  • Process management
    • Start process
    • Get process instance
  • Task management
    • Load tasks
    • Load task content
    • Claim task
    • Complete task
    • Release task
    • Start task

Push notifications

We make use of the RHMAP built-in mobile push API which provides a generic way to interface with multiple push networks (Google Cloud Messaging, Apple Push Notification Service and Microsoft Push Notification Service) via REST or Node.js. This makes it very convenient to send out push notifications from 3rd party application (such as JBoss BPM Suite as demonstrated in our showcase).

RHMAP Push Configuration

More information on the push API can be found here

Backend layer

This layer is comprised of a large set of different backend systems that typically run inside the datacenter of an organization; such as application servers, databases, messaging systems or ESB-like services. For the sake of this showcase we’ve chosen JBoss BPM Suite (( as the only system in here. The BPM Suite provides a full blown authoring and runtime environment for business process applications focused on the use of open standards (such as BPMN 2.0). The included BPM engine also exposes a rich REST API that is used extensively by our MBaaS connector fh-connector-jbpm-cloud to start new process instances, control the process flow etc.

Request processing application

The core business process for our scenario is implemented as a simple BPMN 2.0 workflow that is being deployed in form of our Java based Request Processing Application.

Business Process Diagram

After being instantiated the process firstly sends out a push notification to the requesting customer by simply calling the RHMAP push API. Secondly a human task called Process request is used to create a new work item in the work basket of our employees. Through our Employee App mobile application we empower remote employees to directly work on the request.

In addition to that the work items can be claimed via a traditional web-based application named Business Central, that is provided as part of JBoss BPM Suite.

Edit task via Business Central

Based on the decision the process completes with an according push notification to inform the customer.

More information on how to develop process applications can be found in the JBoss BPM Suite Development Guide.

B. Walkthrough

1. Customer creates new request

Customer App - Login
Customer App - Dashboard
Customer App - Create new request
Customer App - Create new request
Customer App - Create new request
Customer App - Dashboard showing push
Customer App - Show process status
Customer App - Process instance details

2. a) Employee works on request

Request processing application - Work on task instance
Request processing application - View process model

3. b) Agency / Remote worker completes


4. Customer receives push updates on current status

Customer App - Push notification on process status
Customer App - View dashboard
Customer App - View process status

C. Reference Information

Source code

The source code can be found here:

Client layer

Cloud layer

Backend layer

D. Credits

Special thanks to Sebastian Dehn ( for implementing large parts of the client layer.


JBoss Operations Network Showcase

A. Synopsis

What this is about

This demo project showcases some of the most common use cases regarding JBoss Operations Network, Red Hat’s leading enterprise middleware systems management tooling (more information on JON can be found here:

  • Automated provisioning of resources (e.g. JBoss Enterprise Application Platform)
  • Integration of custom JMX MBeans into JON

The resources provided with this showcase are intended as a starting point and shall help you to setup these use cases in your own JBoss Operations Network environment.

Screenshots – Automated provisioning of resources

1. Deploy Bundle - Select Bundle
2. Deploy Bundle - Select Bundle
3. Deploy Bundle - Select Bundle Version
4. Deploy Bundle - Enter input vars
5. Deploy Bundle - Bundle Deployment successful
6. Inventory - Import EAP instance
7. Inventory - JBoss EAP successfully imported

Screenshots – Integration of custom JMX MBeans

1. Custom MBean overview
2. Execute an operation on a custom MBean
3. View the operations history
4. Monitoring of custom MBean metrics

B. Base installation and prerequisites

1. JBoss Operations Network (JON)

Follow the official installation instructions for JON V3.3 here:

2. Apache Maven

You will need to install Apache Maven for building the source code for this showcase. Please follow the installation instructions here:

C. Use Case – Automated provisioning of resources

1. Benefits

This use case describes how to create a standardised JBoss Enterprise Application Platform (EAP) installation package. In terms of JON this is a so called “Bundle”. This Bundle can then be provisioned to a target system (or even multiple) in a highly automated fashion.

More information on the provisioning features can be found in the official JON documentation:

2. Showcase components

  1. eap-bundle – This project provides the core ingredients for creating a bundle to provision instances of JBoss Enterprise Application Platform V6.3.

3. Installation

  1. Create Bundle Group “JBoss EAP V6 Base Installation”
    Create Bundle Group

  2. Define a new bundle
    Create Bundle - Upload Recipe
    Create Bundle - Assign Bundle Group
    Create Bundle - Upload Bundle Files
    Create Bundle - Summary

  3. Deploy the bundle to a target system
    Deploy Bundle - Select Bundle
    Deploy Bundle - Select Bundle
    ![Deploy Bundle – Define Destination]( destination.png)
    Deploy Bundle - Select Bundle Version
    Deploy Bundle - Enter input vars
    Deploy Bundle - Deployment scheduled
    Deploy Bundle - Bundle Deployment successful
    Deploy Bundle - Filesystem view on deployment

  4. Import the newly created EAP instance into JON inventory
    Inventory - Import EAP instance

  5. Configure connection settings
    Inventory - Configure connection settings

  6. Start the server
    Inventory - JBoss EAP successfully imported
    Inventory - JBoss EAP successfully imported

D. Use Case – Integration of custom JMX MBeans

1. Benefits

It is a very common scenario that your applications have been enhanced with MBeans for management, runtime configuration or even monitoring capabilities. JBoss Operations Network allows you to integrate these MBeans into its management environment, which actually means that you can then leverage JON’s full systems management and monitoring capabilities:
– Historical monitoring of your MBeans
– Dashboarding and alerting
– Execution of MBean operations

2. Showcase components

  1. helloworld-mbean – JEE application that shows different ways of exposing MBeans (taken from EAP quickstarts at
  2. custom-jmx-plugin – JBoss Operations Network Agent plugin that integrates custom MBeans (provided by helloworld-mbean) via JMX into JON’s monitoring & dashboarding.

3. Installation

1. Build and deploy the MBean provider application

Build the application with Maven:

# OPTIONAL: Copy the provided settings.xml to your local maven conf dir
cp ~/.m2/

# Start the build
cd ./helloworld-mbean
mvn clean install

# Hot deploy the application to an instance of JBoss EAP
# you could use the instance that has been provisioned in the use case "Automated provisioning of resources"
cp ./helloworld-mbean-webapp/target/jboss-helloworld-mbean-helloworld-mbean-webapp.war <EAP_INSTALLATION_DIR>/standalone/deployments

2. Build and deploy the agent plugin

Build the application with Maven:

# OPTIONAL: Copy the provided settings.xml to your local maven conf dir
cp ~/.m2/

# Start the build
cd ./custom-jmx-plugin
mvn clean install

Deploy the agent plugin:

cp ./target/custom-jmx-plugin-1.0-SNAPSHOT.jar <JON_SERVER_INSTALL_DIR>/plugins/

The JON server periodically scans the “plugins” directory for updates and will pickup the agent plugin after some time, which is finally pushed to the connected JON agents. The agents might need to be restarted to detect the plugin after initial installation.

In the end you should see a service group called “Myapp Services” that contains the applications’ MBeans. You can now start to add the contained metrics to custom dashboard, define alerts on it and so on.

1. Custom MBean overview

Z. Appendix

The source code can be found here: