Die Portal Edition R5 ist die erste Version, die alle Funktionen vollständig im rollenbasierten Portal unterstützt. Die bisherigen alten Apps sind letztmalig im Produktpaket enthalten.  

Neu mit diesem Release:

• Neu im Portal: Query Configuration
• Neu im Portal: Action Configuration
• Neu im Server: Authentifizierung der Benutzer über OpenID Connect, Support von Okta und Keycloak
• Neu im Server: kompletter Portalbetrieb über Web-API ohne IIS auf Port 80/443
• Neu im Server: Web-API Healthcheck URL
• Neu im no-code UI: weitere ASRDisplay Optionen

Abkündigung ScriptRunner 2020 alle Releases

Die Versionen für ScriptRunner 2020 wurden mit Wirkung zum 31. Dezember 2022 abgekündigt. Für diese Versionen erfolgen keine Fixes oder Anpassungen mehr. Treten bereits bekannte Fehler auf, so wurden diese bereits in Folgeversionen behoben.  Sollten bisher unbekannte Fehler auftreten, werden diese nur in der aktuellen Version und nachfolgenden behoben.

Neu im Portal: Query Configuration

Im Portal können nun alle Querytypen konfiguriert und getestet werden. Dabei wurden gegenüber der Admin App sowohl die Übersichten und zugänglichen Funktionen neu gestaltet als auch die einzelnen Konfigurationselemente überarbeitet. Das grundlegende Look & Feel entspricht dabei dem von Targets und Credentials.

Neue Queries können aus vorgefertigten Templates erstellt werden. Das jeweilige Query-Template ist nun nach best practices für die Verwendung voreingestellt. Eine einmal erstellte Query kann dann in den Einstellungen geändert werden.

Vorlagen helfen, Queries im Handumdrehen zu erstellen

In Abhängigkeit vom Use Case können für Active Directory Queries und Azure Queries verschiedene vorkonfigurierte Query Cases ausgewählt werden. Das erleichtert die Konfiguration und verringert die Komplexität.

Vorauswahl von Query-Cases, hier einer Azure Query

Jeder vorkonfigurierte Query Case kann mit zusätzlichen Filtern angepasst werden, um die Ergebnismenge für die Anwender optimal zu steuern. Der Anwender bekommt nur das zur Auswahl, was gewünscht ist. Zudem kann das Result Set der Query auf ein einzelnes Attribut oder auf ein  JSON-Objekt mit mehreren Attributen (Multiattribut-Query) eingestellt werden. Letzteres ist zusammen mit dem Splatting-Feature in ScriptRunner eine sehr mächtige Funktion und reduziert insgesamt die notwendige Anzahl von Queries.

Die Azure Query für User erzeugt als Ergebnismenge für das no-code UI eine Auswahlliste aller deaktivierten User-Accounts des Mandanten

Neu gestaltet wurden die Einstellungen zur Ausführung der Query. Dabei wurden bisherige Optionen verständlich zusammengefasst. In Verbindung mit den Voreinstellungen ist es nun deutlich einfacher geworden, die bestmögliche Funktionsweise für die jeweilige Query  zu konfigurieren. 

Vereinfachtes Konfigurieren der jeweiligen Query

Zum Testen einer Query wurde eine eigenständige Testfunktion wie beim Target hinzugefügt, welche es erlaubt, die Ergebnisenge der Query beim Konfigurieren gleich zu überprüfen.

AD Query Result als Liste 

Eine Übersicht, welche die Verwendung der Query in verschiedenen Actions auflistet, rundet die Informationen zur jeweiligen Query ab.

Neu im Portal: Action Configuration

Die Konfigurationsmöglichkeiten für Actions im Portal sind im letzten großen Feature-Block zur Ablösung der alten Admin App. Neben der Neugestaltung der Liste aller Actions wurde insbesondere die Benutzerführung für die Einstellungen stark überarbeitet.

Nach dem Anklicken einer Action in der Liste öffnet sich eine neue, klar gestaltete Übersichtsseite. Hier sind sofort alle wesentlichen, verwendeten Elemente und Einstellungen zur Ausführungsrichtlinie im Blick. Beim Anklicken der jeweiligen Abschnittsüberschrift von General, Scripts, Queries, Targets, Delegations oder Scheduling wechselt die Anzeige direkt zu den zugehörigen Details.

Zusätzlich werden rechts die Ergebnisse der letzten fünf Ausführungen aufgelistet und auf einen Klick wird der entsprechende Report angezeigt.

Mit dem Run-Button wechselt ein Anwender in der Administratorenrolle auf dem kürzesten Weg in den Ausführen-Modus für die Action.

Neue Übersichtsseite aller Einstellungen einer Action mit Verlinkung zu den Details

Auf der Seite für die Vorbelegung von Skriptparametern und für die Zuweisung von Queries fällt sofort auf, dass im neuen Design wichtige Zusatzinformationen am verwendeten Parameter wie Datentyp, Parameter-Set und erweiterte Parameterattribute sowie Einschränkungen angezeigt werden. Das erspart nun beim Einstellen den notwendigen Blick in das Skript. Alle Informationen aus Header und Parameterblock sind sofort sichtbar. 

Skriptauswahl, zugehörige Skriptparameter inkl. aller Zusatzinformationen sowie aller Einstellungen nun auf einer einzigen Seite

Zusätzliche Möglichkeiten für eine Ausführungsrichtlinie, bspw. die Limitierung von gleichzeitigen, parallelen Ausführungen einer Action durch unterschiedliche Anwender, wurden auf einer separaten Konfigurationsseite zusammengefasst.

Advanced Options für eine Action wurden zusammengefasst

Die Einstellungen für die Delegation der Action an Help Desk und Endanwender wurden separiert und die Konfiguration der Anzeigeoptionen deutlich aufgewertet. 

Im oberen Bereich können sowohl die Kacheltexte als auch weitere Hinweise, welche auf dem Eingabeformular erscheinen, in allen unterstützten Sprachen editiert werden, sofern diese nicht bereits im Skript mit den Sprachtags von ScriptRunner hinterlegt worden sind.

Im unteren Bereich werden die Tags zur Registerkartendarstellung, das Icon und die Farbe für die Kachel eingestellt. 

Die erfolgten Einstellungen für die Kacheldarstellung werden sofort in der Preview mit WYSIWYG angezeigt, was einen erhöhten Spaßfaktor beim Konfigurieren mit sich bringt.

Einstellen der Anzeigeoptionen mit WYSIWYG mit Spaßfaktor 

Das zeitgesteuerte Ausführen von Actions ist eine wichtige Funktionalität im operativen Tagesgeschäft von Administratoren. Aus diesem Grund wurde das Einstellen der zeitlichen Steuerung (Scheduling) für eine Action komplett neu gestaltet.

Im ersten Schritt wählt man den gewünschten Zykluszeitraum aus. Von einmalig bis monatlich reicht das Spektrum. Aus dieser Vorauswahl ergeben sich dann die konkreten Einschluss- oder Ausschluss-Optionen. Spezielle Konfigurationen lassen sich im Register 'More' einstellen.

Beispiel für das wöchentliche Ausführen der Action am Montag und Freitag, jeweils 06:00 Uhr

Mehr zu den Neuerungen im Portal in diesem Video:

Authentifizierung über OpenID Connect

ScriptRunner verwendet zur Authentifizierung der Benutzer externe Identity Provider wie Active Directory, ADFS, Azure AD und jetzt auch weitere, welche auf OpenID Connect basieren. Ein sehr bekannter Vertreter dafür ist das Identity Management von Okta.

Grundlegendes zur Benutzeridentität in ScriptRunner

Als  Idee für die Benutzerauthentifizierung liegt zugrunde, keine eigenen ScriptRunner Identitäten zu verwenden, so wie es viele Softwaresysteme tun, sondern bereits vorhandene Benutzer- und Gruppenidentitäten zu nutzen.

In ScriptRunner können auf der Basis von Rollen-Templates ScriptRunner-eigene Access Groups angelegt werden. Dabei impliziert jedes Rollen-Template und damit jede ScriptRunner Access Group eine Kombination von Zugriffsrechten und Eigentümerschaften auf Elemente und Funktionen in ScriptRunner.

Externe Benutzer- und Gruppenidentitäten aus unterschiedlichen Identity Providern werden den ScriptRunner Access Groups zugewiesen. Dadurch erhält ein Benutzer oder eine Gruppe die entsprechenden Zugriffe im ScriptRunner Portal.

Zusammenhang zwischen Rollen, Access Groups, Memberships und Element-Ownership in ScriptRunner 

WICHTIG: Die Benutzerauthentifizierung ist nicht zu verwechseln mit den administrativen Zugriffsrechten auf die von ScriptRunner verwalteten Zielsysteme zum Ausführen von Skripten! Beide sind als grundlegende Security-by-design Merkmale komplett voneinander getrennt.

Funktionsprinzip der Anmeldung

ScriptRunner nutzt ein implizites Anmeldeverfahren. Das bedeutet, dass der Benutzer an seinen Identity Provider eine gültige Anmeldung vorgenommen hat (Login). Die Details im Anmeldeverfahren und die Protokolle unterscheiden sich je nach Identity Provider und dessen Konfiguration. So nutzt Active Directory Windows-integrated oder Kerberos, während Azure AD eine MS-eigene Implementierung von OpenID Connect verwendet. 

Hat der Benutzer keine Identität, wird er von  ScriptRunner auf seinen Identity Provider verwiesen. Bei einer ungültigen Identität, also ohne für ScriptRunner gültige Benutzer-oder Gruppen-Claims, wird der Benutzer vom ScriptRunner Service abgewiesen.

Eine gültige Identität mit den entsprechenden Claims wird von ScriptRunner über die ScriptRunner Access Groups auf die jeweiligen Berechtigungen gemapped, das Portal agiert also rollenbasiert. Für Anwender, die mehreren unterschiedlichen Rollen zugeordnet wurden, gilt die Rolle mit den höchsten Berechtigungen.

Okta Integration 

Okta ist ein ein führender Anbieter von Identity Management und unterstützt den OpenID Connect Standard. Für die Integration muss ScriptRunner Server in Okta mit der Methode OIDC als Single Page App eingerichtet und konfiguriert werden. Anschließend sind die zu verwendenden Gruppen-Claims für ScriptRunner zu definieren.

Nach der Einrichtung in Okta folgt die Konfiguration auf dem ScriptRunner Server. Zuerst sind die in Okta hinterlegten Gruppen-Claims in der Benutzerkonfiguration von ScriptRunner zu hinterlegen. Als Gruppentyp wird claim-based verwendet. Danach sind die Einstellungen am ScriptRunner Webservice Endpoint einzurichten. Dafür wird ein SSL-Zertifikat benötigt. Mit dem Cmdlet Set-ASRSTSOptions erfolgt die Konfiguration für den AuthMode OIDC für den Port 8092. Zuletzt wird noch die App.json für das Portal auf diese Methode angepasst, um die Redirection zur Anmeldung an Okta sicherzustellen.

Eine detaillierte Anleitung für Okta kann bei unserem Support angefragt werden.

Hier das Thema Okta in unserem Release Video (ab Min. 3:59):

Keycloak Integration

Keycloak ist ein Open Source Identity Management, dessen Entwicklung von Red Hat unterstützt wird. Auch dieses System deckt den Standard OpenID Connect ab. Zuerst muss eine Anwendung in Keycloak angelegt werden, danach erfolgt die Einrichtung der Gruppen und Claims sowie der Scopes für ScriptRunner. 

Ist das abgeschlossen, können die Gruppen-Claims in ScriptRunner hinterlegt werden. Die Anpassung von ScriptRunner Server für Keycloak erfolgt ebenfalls mit dem Cmdlet Set-ASRSTSOptions unter Verwendung des AuthMode OIDC für den Port 8092.  Zuletzt wird noch die App.json für das Portal auf diese Methode angepasst, um die Redirection zur Anmeldung an Keycloak sicherzustellen.

Eine detaillierte Anleitung für Keycloak kann bei unserem Support angefragt werden. 

Portalbetrieb über Web-API auf Port 80/443 ohne IIS

Die Portal Edition R5 ist das erste Release auf dem Weg in die erneuerte Backend-Technologie. Ein wichtiger Aspekt ist dabei der vollständige Betrieb von ScriptRunner über die eigene Web-API. Damit verbunden sind folgende Vorteile:

• ScriptRunner Service benötigt keinen IIS mehr auf dem Server.
• Die Kommunikation zwischen Portal und ScriptRunner Service erfolgt  über den gleichen Port.
• ScriptRunner Service kann nun auch auf Standard-Port 80/443 betrieben werden. Das erleichtert die Freischaltung für Zugriffe aus unterschiedlichen Infrastrukturen und Homeoffices.
• ScriptRunner Service verwendet ausschließlich das Portal. Die alten Web Apps sowie die Desktop App werden nicht mehr benötigt.

Als Zwischenschritt wird es weiterhin zwei Setup-Pakete geben. Das Trial-Paket für Testkunden enthält ausschließlich das neue Service-Setup inkl. Portal. Das Full-Package enthält sowohl das neue Service-Setup als auch zusätzliche Setups, um das Portal und die Admin App auf dem IIS installieren zu können sowie die Desktop Apps. 

Updates in bestehenden Installationen 

Beim Update in bestehenden ScriptRunner-Installationen ändert sich nichts. Die vorhandenen Einstellungen und der bisherige Betrieb des Portals über den IIS sowie die Service-Endpoints an Port 8091/8092 werden beibehalten. Nach dem neuen Service-Setup muss das Web Apps Setup zur Bereitstellung des Portals und optional der Admin Web App auf dem IIS ausgeführt werden. Das optionale Setup für die Desktop Apps enthält u.a. das ISE Add-on.

Der bestehende Betrieb von ScriptRunner Service mit IIS kann ausschließlich durch das manuelle Entfernen des IIS-Binding und durch Rekonfiguration von ScriptRunner Service auf den Endpoint 80/443 sowie der App.json für das Portal umgestellt werden.

Neuinstallationen

Wird das neue Service-Setup als Neuinstallation ausgeführt, so wird immer standardmäßig die Web-API für das Portal sowie der Service-Endpoint 80 (http) verwendet. Zur Umstellung auf https muss der Service-Endpoint mit einem Zertifikat versehen und auf Port 443 eingestellt werden. 

Migrationen 

Das Vorgehen für Migrationen entspricht im Verfahren den bisherigen Schritte. Einziger Unterschied ist, dass die neuen Server ohne IIS implementiert werden und die Notwendigkeit für Port 8091 entfällt.

ScriptRunner Server Healthcheck URL

Um die Web-API von ScriptRunner einfacher überwachen zu können, wurde eine separate Healthcheck URL nach RFC implementiert. So können nun Monitoring-Systeme die Web-API überwachen und Load Balancer oder Drittsysteme vor dem Aufruf des Web Service Connector prüfen, ob der ScriptRunner Service verfügbar ist.

Das Settings-Cmdlet Test-ASRUri verwendet die neue Möglichkeit ebenfalls. https://support.scriptrunner.com/articles/server/system-health

Weitere ASRDisplay Optionen im no-code UI

Die Funktionen für das no-code UI werden regelmäßig erweitert und verbessert. In der Portal Edition R5 gibt es zwei neue Optionen:

Neues parameter attribute ASRDisplay(ReadOnly)

[Parameter(HelpMessage="ASRDisplay(ReadOnly)")]

[string]$MyReadOnlyField

Mit dieser Option lassen sich Formularfelder mit Werten als reine Information anzeigen, können jedoch nicht vom Anwender geändert werden. So liefert bspw. eine Multiattribut-Query ein JSON-Objekt mit mehreren Parameter-Wert-Paaren, von denen die mit dem Parameterattribut ASRDisplay(readonly) versehenen im UI grau hinterlegt und unveränderlich angezeigt werden. 
https://support.scriptrunner.com/articles/coding/read-only

Neues parameter attribute ASRDisplay(Checkbox)

[Parameter(HelpMessage="ASRDisplay(Checkbox)")]

[bool]$MyBool

Mit dieser Option ändert sich die Darstellung für den Parametertyp [bool]. Statt einer Auswahl mit $TRUE und $FALSE wird nun eine Checkbox angezeigt. Eine aktivierte Checkbox entspricht $TRUE, andernfalls $FALSE.
https://support.scriptrunner.com/articles/coding/logic-input

Weiterführende Links

• Unser Release Guide: Technische Informationen jeweils für unser neustes Release 
• Mission erfüllt! Hier geht es zu unserem Portal Edition R5 Release Video 
• Teste unsere Software, hier geht es zum Download der Trial Version
• ScriptRunner: Teste unsere Software, hier geht es zum Download der Trial Version