Nintex Workflow – In welchem Userkon­text wird die Workflow Action ausge­führt?

|

Mit Nintex Workflow und Nintex Forms lassen sich relativ schnell prozess­ge­steu­erte Anwen­dungen in Micro­soft Share­Point imple­men­tieren. Schnell werden verschie­dene Workflow Actions und Bedin­gungen zusammen geklickt: hier mal eine Create Item Action, dort Execute SQL, da mal ein Call Web Service, dann noch kurz Creden­tials eintragen und — damit es übersicht­lich bleibt — noch schnell einige Actions in ein Action Set gruppieren. Schnell entsteht ein Workflow Prototyp, noch kurz veröf­fent­li­chen und fertig? Nein!

Wie bei jeder anderen Anwen­dung ist es wichtig, zu wissen, in welchem Sicher­heits­kon­text die Anwen­dung bzw. die Nintex Workflow Action ausge­führt wird/werden kann – und welchen Einfluss das auf das Lösungs­de­sign des Workflows hat. In diesem Blog beschreibe ich, in welchen verschie­denen Kontexten eine Nintex Action ausge­führt werden kann, und welche Vor- und Nachteile das haben kann.

 

Option 1: Kontext des Anwen­ders, der den Workflow startet

Wird nichts weiter konfi­gu­riert, so laufen Workflows im Kontext der Person, die den Workflow startet. Gerade bei Workflows in Webs mit komplexer Rechte­struktur und gebro­chener Berech­ti­gungs­ver­er­bung kann es zu Fehlern kommen, wenn die Person, die einen Workflow startet, nicht auf Listen Zugriff hat, auf die der Workflow zugreifen soll.

Option 2: Kontext des Workflow Owners

Workflow Aktionen, die in einem Action Set, einer Loop-Action oder in einer State-Machine enthalten sind, können im Kontext des Anwen­ders ausge­führt werden, der den Workflow veröf­fent­licht hat. Dazu gibt es in den Einstel­lungen der Action > Common folgende Einstel­lungs­mög­lich­keit:

Nintex Forms Workflow Action Set

In der Regel hat der Workflow Owner auch Owner-Rechte in dem Web, d.h. Zugriff auf Listen & Biblio­theken sollten berech­ti­gungs­tech­nisch möglich sein. Aber was passiert eigent­lich, wenn:

  • … der Anwender, in dessen Kontext der Workflow veröf­fent­licht wurde, sein Windows Kennwort ändert? à nichts, die Workflow Funktio­na­lität ist nicht einge­schränkt
  • … der Account des Anwen­ders, in dessen Kontext der Workflow veröf­fent­licht wurde, im Active Direc­tory deakti­viert wird à nichts, die Workflow Funktio­na­lität ist nicht einge­schränkt
  • … der samAc­count­Name des Anwen­ders, in dessen Kontext der Workflow veröf­fent­licht wurde, im Active Direc­tory umbenannt wird à der Workflow funktio­niert nicht mehr – Actions in diesem Action Set laufen auf einen Fehler!
  • … der Account des Anwen­ders, in dessen Kontext der Workflow veröf­fent­licht wurde, im Active Direc­tory gelöscht wird à der Workflow funktio­niert nicht mehr – Actions in diesem Action Set laufen auf einen Fehler!

 

Option 3: Nintex Creden­tial Picker

Die folgenden Nintex Workflow Actions aus der Kategorie Integra­tion nutzen den Nintex Creden­tial Picker, um auf externe Services zuzugreifen:

  • Call web service
  • Create CRM record
  • Delete/Disable CRM record
  • Execute SQL
  • Find users by status
  • Get user status
  • Query BCS
  • Query CRM
  • Query Excel Services
  • Query LDAP
  • Query XML
  • Send / receive BizTalk
  • Update CRM record
  • Update XML
  • Web request

Der Nintex Creden­tial Picker kann in drei verschie­denen Arten genutzt werden:

Nintex Forms Workflow Credential Picker

1.      Creden­tials in der Action

Die Creden­tials können direkt in der Action angegeben werden, Beispiel:

Nintex Forms Workflow Credential

Vorteile:

  • Es ist gleich zu erkennen, welcher Account genutzt wird.

Nachteile:

  • Um den Account zu ändern, muss der Workflow geändert und neu veröf­fent­licht werden – auf in Ausfüh­rung befind­liche Workflow Instanzen hat das keinen Einfluss.
  • Verwenden mehrere Actions im Workflow den gleichen Account, so muss dieser mehrfach im Workflow geändert werden, was z.B. beim Export & Import des Workflows auf verschie­dene Umgebungen aufwändig sein kann.

 

2.      Stored Creden­tials — Nintex

Über die Nintex Settings können die Creden­tials als Nintex Konstante auf Site, Site Collec­tion oder Farm Ebene konfi­gu­riert werden; Optional kann definiert werden, wer dieses Creden­tial nutzen darf:

Nintex Forms Workflow stored credential

Danach kann die Nintex Konstante im Creden­tial Picker ausge­wählt werden:

Nintex Forms Workflow add constant

Vorteile:

  • Das Creden­tial kann in Nintex an zentraler Stelle geändert werden.
  • Die Konfi­gu­ra­tion ist einfach und gut nachvoll­ziehbar.
  • Es reichen Site oder Site Collec­tion Owner Berech­ti­gungen aus, um die Creden­tials zu definieren (Ausnahme: Farm Level Creden­tial).

Nachteile:

  • Creden­tials sind nicht im Secure Store Service gespei­chert, sondern in Nintex. Die in Nintex gespei­cherten Creden­tials können nicht für andere Anwen­dungen außer­halb von Nintex wie zum Beispiel BCS oder Excel Services genutzt werden.
  • Standard­mäßig darf jeder Workflow Ersteller auf die hinter­legten Creden­tials im jewei­ligen Scope (Site, Site Collec­tion, Farm zugreifen. Es besteht das Risiko, dass das Creden­tial von anderen Workflow Erstel­lern für andere Zwecke verwendet werden.

 

3.      Stored Creden­tials — Secure Store

Ähnlich zur Option 2, Unter­schied ist, dass die Creden­tials im Secure Store Service abgelegt werden. Diese Funktion ist seit dem Release 3.1.3.0 (April 2015) verfügbar.

Nintex Forms Workflow edit constant

Bei Verwen­dung der Option Secure Store Creden­tial wird auf eine Target Appli­ca­tion ID referen­ziert. Die Target Appli­ca­tion muss im jewei­ligen Secure Store Service existieren.

Nintex Forms Workflow edit store target

Nintex Forms Workflow set credentials

Die Verwal­tung von Creden­tials im Secure Store Service ist aus Anwen­der­sicht komplexer als in Nintex und setzt einiges an Wissen voraus:

  • Der Anwender benötigt im Secure Store spezi­elle Rechte, um eigene Creden­tials (sogenannte Target Appli­ca­tion IDs) im Secure Store anzulegen und zu verwalten. Diese Rechte müssen initial durch den Farm Admin konfi­gu­riert werden. Unabhängig davon ist die Central Adminis­tra­tion von Share­Point auf SSL / https umzustellen, damit die hinter­legten Creden­tials nicht im Klartext durch das Netzwerk geschickt werden. Wird der Secure Store ohne SSL verwendet, so erscheint die Warnung: Warning: this page is not encrypted for secure commu­ni­ca­tion. User names, passwords, and any other infor­ma­tion will be sent in clear text. For more infor­ma­tion, contact your adminis­trator.
  • Im Secure Store Service sind verschie­dene Target Appli­ca­tion Types möglich. Im Falle von Creden­tials, die in Nintex genutzt werden, ist der Target Appli­ca­tion Type = Indivi­dual ausrei­chend, da Nintex mit der Identität der Weban­wen­dung auf den Secure Store Service zugreift. Dies stellt aber auch ein Risiko dar, da jeder Code, der als Farm Solution bereit­ge­stellt ist, poten­tiell durch Nutzung von RunWi­thE­le­va­ted­Pri­vi­leges auf dieses Creden­tial zugreifen kann.

Vorteile:

  • Sofern vorhanden kann eine bestehende und gesicherte Secure Store Service Imple­men­tie­rung genutzt werden – die Creden­tials werden an zentraler Stelle verwaltet.

Nachteile:

  • Die Komple­xität bei Nutzung der Nintex Konstanten und des Secure Stores ist nicht zu unter­schätzen – es ist mit Schulungs­auf­wand zu rechnen. Durch die verteile Konfi­gu­ra­tion in Nintex und im Secure Store wird zudem das Trouble­shoo­ting erschwert.
  • Creden­tials im Secure Store sind global und können – je nach Berech­ti­gung – in der Farm genutzt werden. Defini­tion von Creden­tials auf Site oder Site Collec­tion Level ist nicht möglich.

 

Zusam­men­fas­sung / Best Practices

  1. Wird ein Action Set mit der Option Run as workflow owner verwendet, so sollte der Workflow im Kontext eines Workflow-Anwen­dungs­ac­count veröf­fent­licht werden, nicht mit einem perso­na­li­sierten Account. Bei Verwen­dung eines perso­na­li­sierten Accounts wird der Workflow nicht mehr funktio­nieren, wenn der perso­na­li­sierte Account im Active Direc­tory gelöscht wurde.
  2. Bei Verwen­dung von Actions mit dem Creden­tial Pickers sollten die Creden­tials nicht fest in der Workflow Action hinter­legt werden, sondern referen­ziert werden. Ob diese Nintex, oder im Secure Store verwaltet werden, hängt von den unter­neh­mens­spe­zi­fi­schen Voraus­set­zungen, bzw. Richt­li­nien ab. In jedem Fall ist aber sicher­zu­stellen, dass die Zugriffs­rechte auf das Creden­tial nach dem Minimal-Rechte-Prinzip konfi­gu­riert sind, andern­falls besteht das Risiko, dass Creden­tials missbraucht werden.

Joachim von Seyde­witz

Solution Archi­tect



Kontakt

Ihr Anliegen. Unsere Experten. Erleben Sie netunite. Wir freuen uns auf Ihre Anfrage.
Gerne sind wir auch telefonisch unter 089/8906599-0 oder per E-Mail unter info@netunite.eu für Sie erreichbar.

netunite AG
Lindwurmstraße 97
80337 München


Pflichtfeld

Pflichtfeld


Absenden
Absenden

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung. Akzeptieren