Camunda BPM Erweiterung um SSO in einer JBoss EAP 6 Installation
Dabei stehen die immer gleich ablaufenden Arbeitsabläufe oder auch Prozesse im Vordergrund, deren Qualität und Effizienz durch eine IT-gestützte Ausführung und (teilweise) Automatisierung verbessert werden soll. Eine auf dem Markt existierende Engine ist die auf Java basierte camundaBPM Engine, die die Ausführung von Modellen in den OMG-Notationen BPMN, CMMN und DMN unterstützt. Diese ist Open Source verfügbar und bringt neben der reinen Engine zum Ausführen der Prozesse (BPMN), Cases (CMMN) oder Entscheidungen (DMN) auch direkt einsetzbare Webkomponenten für die Abarbeitung von Benutzeraufgaben (Cockpit, Tasklist) als auch eine REST API mit. In einem konkreten Kundenkontext sollte das Cockpit in eine bestehende Single-Sign-On (SSO) Sicherheitsarchitektur integriert werden, was ich in diesem Blogpost näher erläutern möchte. Mit einer Integration des Cockpits in die SSO-Architektur sollte eine komfortable Möglichkeit geschaffen werden den Enduser ohne eine weitere Loginmaske direkt für das Cockpit, die Tasklist und die Admin-Oberfläche anzumelden.
Die folgende Tabelle gibt dabei eine gute Zusammenfassung über die umzusetzende Lösung, die technischen Voraussetzungen und Zielstellungen:
| User Story | Als Endanwender möchte ich automatisch eingeloggt werden, um mich nicht extra auf der CamundaBPM Cockpit-, Tasklist- und Administrationsseite einloggen zu müssen. |
| Problem | Das Camunda Cockpit und die Taskliste sind via eines eigenen Logins verfügbar. Dieser Login ist nicht komplett in eine mögliche SSO-Sicherheitsinfrastruktur integriert. Der Endbenutzer soll sich über eine SSO Mechanik einloggen und nicht erneut seine Logininformationen Dialog von Camunda eingeben müssen. |
| Anforderungen | Es soll möglich sein, dass kein explizites Einloggen an der Cockpit und Tasklist Anwendung nötig ist. Außerdem muss das Rollen und User Konzept eines aktiven Active Directory und/oder LDAP übernommen werden. |
| Technische Voraussetzungen | Die Single-Sign-On (SSO) Mechanik soll über die Standard JBoss Konfiguration aktiviert werden. Dabei werden in dieser Variante folgende technische Komponenten genutzt: Windows Active Directory (AD), JBoss AS7 / EAP 6, Windows Server 2008 und neuer |
| Lösung | Die Integration des JBoss und der CamundaBPM Anwendung in die vorhandene Infrastruktur kann über die JBoss Konfiguration erfolgen. Dabei muss das Installationszielsystem mit Kerberos und dem Usermanagement eines Active Directory konfiguriert werden. Die CamundaBPM Webanwendung muss angepasst, bzw. umkonfiguriert werden, um die Credential Negotiaton zu aktivieren. |
In den folgenden Abschnitten möchte ich nun die Umsetzung anhand der einzelnen Komponenten genauer beschreiben:
Aufsetzen der Komponenten
Insgesamt beschränkt sich die Installation auf die Konfiguration des JBoss EAP, Java und eine Änderung der Camunda Webapp. Im JBoss muss die Security Konfiguration mit mehreren Konfigurationsdateien (Kerberos, JAAS, Principal-Credential) hinterlegt werden. Daraufhin wird die Java Runtime mit weiteren Security Policies ausgestattet, damit eine bessere Verschlüsselung als 128 Bit möglich ist. Zu guter Letzt muss noch die Camunda Webapp um einige Konfigurationsdateien (JBoss und Applikations Konfiguration) und einem angepassten Securityfilter ergänzt werden.
Konfiguration des JBoss EAP 6
Um einen JBoss EAP 6 an ein Active Directory zu koppeln und damit in Applikationen die SSO Mechanik zu nutzen ist eine umfangreiche Konfiguration des JBoss notwendig. Diese Änderungen müssen zentral an der standalone.xml im Verzeichnis %JBOSS_DIR%/standalone/configuration durchgeführt werden.
Zunächst muss im Active Diretory ein Service User für den JBoss Service angelegt werden. Dieser Serviceuser muss sich im Active Directory anmelden können, damit verschiedene Operationen gegen das AD möglich sind. An den User muss auch ein sogenannter Principal hinterlegt werden, welcher dann genutzt wird, um andere Benutzer innerhalb der AD Userstruktur zu finden. Der zweite Punkt ist die Integration von Camunda in das Active Diretory. Dazu müssen die Plugins „LdapIdentityProviderPlugin“ und „AdministratorAuthorizationPlugin“ in der Camunda Installation innerhalb des JBoss hinterlegt und konfiguriert werden . Camunda läuft ab diesem Zeitpunkt mit den Usern und Gruppen des AD. Dann müssen im JBoss sogenannte Security-Domains hinterlegt werden, die die Kerberos-Konfiguration und die SPNEGO Konfiguration enthalten. SPNEGO integriert die Windows Authentifizierung in Java. Eine Besonderheit der SPNEGO-Konfiguration ist das Login-Modul „Advanced-AdLdap“, welches die genaue Lokation und Konfiguration des Active Directory benötigt.
Für Kerberos müssen noch einige Konfigurationsdateien, wie die krb5.ini und weitere Einstellungen in den System-Properties des JBoss hinterlegt werden. Desweiteren muss die JAAS Implementierung mit der richtigen Konfigurationsdatei verlinkt werden. Die anderen Optionen in den System-Properties des JBoss sind Debugging Optionen, die nach erfolgreichem Testen wieder entfernt werden sollten.
Die komplette Konfiguration der standalone.xml folgt an dieser Stelle:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 |
<server xmlns="urn:jboss:domain:1.5"> ... <system-properties> <property name="java.security.krb5.realm" value="NOVADOMAIN.LOCAL"/> <property name="java.security.krb5.kdc" value="192.168.0.1"/> <property name="java.security.auth.login.config" value="C:\login.conf"/> <property name="java.security.krb5.conf" value="C:\Windows\krb5.ini"/> <property name="sun.security.krb5.debug" value="true"/> <property name="jboss.security.disable.secdomain.option" value="true"/> <property name="javax.net.debug" value="true"/> <property name="java.security.debug" value="true"/> </system-properties> ... <profile> ... <subsystem xmlns="urn:jboss:domain:security:1.2"> ... <security-domains> <security-domain name="myhost" cache-type="default"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="principal" value="HTTP/nbookeh2.novaDomain.local@NOVADOMAIN.LOCAL"/> <module-option name="keyTab" value="C:/krb5.keytab"/> <module-option name="doNotPrompt" value="true"/> <module-option name="refeshKrb5Config" value="false"/> <module-option name="debug" value="true"/> </login-module> </authentication> </security-domain> <security-domain name="SPNEGO" cache-type="default"> <authentication> <login-module code="SPNEGO" flag="requisite"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="serverSecurityDomain" value="myhost"/> <module-option name="removeRealmFromPrincipal" value="true"/> </login-module> <login-module code="AdvancedAdLdap" flag="requisite"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="bindDN" value="cn=Administrator,cn=Users,dc=novaDomain,dc=local"/> <module-option name="bindCredential" value="jessica_4321"/> <module-option name="java.naming.provider.url" value="ldap://vmserver2015.novaDomain.local:389"/> <module-option name="java.naming.referral" value="follow"/> <module-option name="baseCtxDN" value="DC=novaDomain,DC=local"/> <module-option name="baseFilter" value="(cn={0})"/> <module-option name="roleAttributeID" value="memberOf"/> <module-option name="allowEmptyPassword" value="false"/> </login-module> </authentication> </security-domain> </security-domains>nur </subsystem> ... <subsystem xmlns="urn:org.camunda.bpm.jboss:1.1"> <process-engines> <process-engine name="default" default="true"> <plugins> <plugin> <class>org.camunda.bpm.identity.impl.ldap.plugin.LdapIdentityProviderPlugin</class> <properties> <property name="serverUrl">ldap://192.168.0.1:389</property> <property name="managerDn">cn=Administrator,cn=Users,dc=novaDomain,dc=local</property> <property name="managerPassword">jessica_4321</property> <property name="baseDn">dc=novaDomain,dc=local</property> <property name="userSearchBase">cn=Users</property> <property name="userSearchFilter">(objectCategory=person)</property> <property name="userIdAttribute">cn</property> <property name="userFirstnameAttribute">name</property> <property name="userLastnameAttribute">sn</property> <property name="userEmailAttribute">mail</property> <property name="userPasswordAttribute">userPassword</property> <property name="groupSearchBase">cn=Users</property> <property name="groupSearchFilter">(objectCategory=group)</property> <property name="groupIdAttribute">cn</property> <property name="groupNameAttribute">name</property> <property name="groupMemberAttribute">member</property> </properties> </plugin> <plugin> <class>org.camunda.bpm.engine.impl.plugin.AdministratorAuthorizationPlugin</class> <properties> <property name="administratorUserName">eh</property> </properties> </plugin> </plugins> </process-engine> </process-engines> ... </subsystem> ... </profile> ... </server> |
Erstellung der login.conf Datei
Um die JAAS Implementierung zu nutzen, muss eine „login.conf“ Datei hinterlegt werden, die dann in dem JBoss als System-Parameter hinterlegt werden kann. Die „login.conf“ Datei wird von der Kerberos Bibliothek innerhalb des JBoss angezogen und verwendet die dort festgelegte Konfiguration.
|
1 2 3 4 5 6 7 8 9 |
com.sun.security.jgss.login { com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true debug=true renewTGT=true; }; com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true debug=true renewTGT=true; }; com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true debug=true renewTGT=true; }; |
Generierung des Principal Credentials
Damit Kerberos komplett funktioniert, wird eine „*.keytab“ Datei benötigt. Diese wird im Active Directory mit dem jeweiligen Principal erstellt und wird dann direkt im JBoss als System Property verlinkt. Zum exportieren dieser Datei muss das Active Directory richtig konfiguriert sein. In diesem Beispiel benutzen wir die Testuser „eh“, „TestUser“, „Administrator“ und die Testgruppe „TestGroup“.
Mit dem folgenden Befehl in der Standard Windowskonsole wird dem User „eh“ der Principal „HTTP/nbookeh2.novaDomain.local“ hinzugefügt.
|
1 |
setspn -A HTTP/nbookeh2.novaDomain.local eh |
Dann kann mit dem Tool ktpass die *.keytab Datei erzeugt werden:
|
1 |
ktpass /out krb5.keytab /mapuser eh@NOVADOMAIN.LOCAL /princ HTTP/nbookeh2.novaDomain.local@NOVADOMAIN.LOCAL /pass jessica_4321 /kvno 0 /crypto all |
Konfiguration von Kerberos
Kerberos ist mit jeder Windowsinstallation an Bord. Für eine Konfiguration von Kerberos muss eine „krb5.ini“ angelegt werden. Diese benötigt eine spezifische AD Konfiguration und wird mit dem JBoss über die System properties verlinkt. Diese Datei definiert welche Security Mechanismen genutzt werden und wo der Kerberos Server (Key Distribution Service) erreichbar ist.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
[appdefaults] validate=false [domain_realm] novadDmain.local = "NOVADOMAIN.LOCAL" .novaDomain.local = "NOVADOMAIN.LOCAL" [libdefaults] ticket_lifetime = 600 default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes256-cts aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc default_tgt_enctypes = aes256-cts-hmac-sha1-96 aes256-cts aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes256-cts aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc dns_lookup_kdc = "true" forwardable = true default_realm = "NOVADOMAIN.LOCAL" [logging] [realms] NOVADOMAIN.LOCAL = { admin_server = "192.168.0.1" kdc = "192.168.0.1" } |
Mehr Sicherheit in Java
Eine Standard JRE oder ein JDK unterstützt nur eine Verschlüsselung von 128 Bit. Mit der Installation der Datei „UnlimitedJCEPolicyJDK7.zip“ von der Oracle Website in die JRE und des JDKs kann eine bessere Verschlüsselung angewandt werden.
Camunda Cockpit
Das Camunda Cockpit muss im letzten Schritt angepasst werden. Dazu sind folgende Schritte notwendig:
- JBoss spezifische Konfiguration hinterlegen in den Dateien:
- jboss-web.xml
- jboss-deployment-structure.xml
- Anpassung der web.xml in der Camunda webapp
- Hinzufügen eines eigenen Security Filters der die SSO-Mechanik verwalten kann.
Um diese Änderungen automatisch durchzuführen wurde ein Repackager für Camunda webapp entworfen, der diese Umkonfiguration mittels eines Maven Builds ermöglicht. Dieser Repackager wird bei Camunda auf GitHub bereitgestellt: https://github.com/camunda/camunda-sso-jboss
Fazit
Die Integration des camundaBPM Cockpit in die vorliegende SSO Architektur hat erneut gezeigt, dass das Paradigma „open source“ / JEE bei camundaBPM ernst genommen wird. Die SSO Mechanik ist einfach in die camundaBPM Implementierung integrierbar. Somit kann mit der Mechanik in dieser Sicherheitsinfrastruktur geredet werden. Diese Anleitung gilt nur für die Webapplikation in Zusammenhang mit einem JBoss AS 7 und einem Active Directory.
Es stellen sich noch einige Fragen, die dieser Artikel nicht weiter beantwortet:
- Ist es sinnvoll ein Single Sign On zu implementieren, wenn ein Single Sign Out nicht implementiert wird?
- Kann diese Mechanik auch in anderen Containern (Tomcat, Glassfish, …) realisiert werden?
- Können andere SSO Authentifizierungsverfahren genutzt werden?
Eventuell haben Sie auch Erfahrung mit dieser Thematik und haben schon eine SSO Konfiguration in Camunda oder auch anderen Engines konfiguriert, dann bin ich an einem Austausch interessiert, in wie weit sich solche Konfigurationen unterscheiden können. Melden Sie sich einfach unter meiner E-Mail Adresse.
Wenn Sie ihre Camunda Installation um diese SSO Mechanik erweitern wollen, dann checken Sie sich den Repackager unter https://github.com/camunda/camunda-sso-jboss aus und konfigurieren Sie zum Test einen JBoss so, um dass der JBoss mit ihrem Active Directory kommunizieren kann. Falls Sie Fehler oder Verbesserungen an dieser Lösung finden, dann melden Sie sich bei mir unter eberhard.heber@novatec-gmbh.de oder stellen Sie einen Pull Request an das Beispiel Repository.
Aktuelle Beiträge
Artikel kommentieren