6 min read
Boost your IT automation efficiency with new ScriptRunner release
We have just released our latest ScriptRunner update, version 7.1, packed with powerful new features aimed at making IT...
ScriptRunner Blog
Portal Edition R5 is the first version that fully supports all functions in the role-based Portal. The previous old apps are included in the product package for the last time.
The versions for ScriptRunner 2020 have been discontinued effective December 31, 2022. No more fixes or adjustments will be made for these versions. If previously known bugs occur, they have already been fixed in subsequent releases. If previously unknown errors occur, they will only be fixed in the current version and subsequent ones.
All Query types can now be configured and tested in the Portal. Compared to the Admin App, the overviews and accessible functions have been redesigned and the individual configuration elements have been revised. The basic look and feel is the same as for Targets and Credentials.
New Queries can be created from ready-made templates. The respective query template is now preset for use according to best practices. Once a Query has been created, it can then be modified in the settings.
Templates help create Queries in no time
Depending on the use case, different preconfigured Query cases can be selected for Active Directory Queries and Azure Queries. This simplifies configuration and reduces complexity.
Preselection of Query cases, here an Azure Query
Each pre-configured Query case can be customized with additional filters to optimally control the result set for users. The user gets only what is desired to select. In addition, the result set of the Query can be set to a single attribute or to a JSON object with multiple attributes (multi-attribute Query). The latter, along with the splatting feature in ScriptRunner, is a very powerful feature and reduces the overall number of Queries required.
The Azure Query for users generates a selection list of all deactivated user accounts of the client as a result set for the no-code UI.
The settings for Query execution have been redesigned. Previous options have been summarized in a comprehensible way. In conjunction with the default settings, it has now become much easier to configure the best possible functionality for the respective Query.
Simplified configuration of the respective Query
To test a query, a standalone test function has been added like the one for Targets, which allows to check the result set of the Query right away when configuring it.
AD Query Result as list
An overview that is listing the use of the Query in various Actions rounds off the information on the respective Query.
The configuration options for Actions in the Portal are part of the last major feature block to replace the old Admin App. In addition to the redesign of the list of all Actions, the user interface for the settings in particular has been significantly revised.
After clicking on an Action in the list, you land on a new, clearly designed overview page. This means that all the main elements and settings used for the execution policy are immediately visible at a glance. Clicking on the respective section heading of General, Scripts, Queries, Targets, Delegations or Scheduling, the display switches directly to the associated details.
In addition, the results of the last five executions are listed on the right and the corresponding report is displayed after clicking it.
With the Run button, a user in the administrator role switches to the shortest way to the execution mode for the Action.
New overview page of all settings of an Action with link to the details
On the page for presetting script parameters and for assigning Queries, it is immediately noticeable that the new design displays important additional information on the parameter used, such as data type, parameter set and extended parameter attributes as well as restrictions. This makes looking into the script during configuration redundant. All information from header and parameter block are immediately visible.
Script selection, associated script parameters including all additional information and all settings now on a single page
Additional options for an execution policy, e.g. limiting simultaneous, parallel executions of an Action by different users, have been combined on a separate configuration page.
Advanced options for an Action have been merged
The settings for the delegation of the Action to help desk and end users have been separated and the configuration of the display options has been significantly enhanced.
The settings for the delegation of the Action to help desk and end users have been separated and the configuration of the display options has been significantly enhanced.
In the lower area, the tags for the tab display, the icon and the color for the tile are set.
The settings made for the tile display are immediately shown in the preview with WYSIWYG, which creates an increased fun factor when configuring.
Setting display options with WYSIWYG with fun factor
The scheduled execution of Actions is an important functionality in the operational day-to-day business of administrators. For this reason, scheduling an Action has been completely redesigned.
The first step is to select the desired cycle period. The spectrum ranges from once to monthly. This preselection then results in the concrete inclusion or exclusion options. Special configurations can be set in the 'More' tab.
Example for weekly execution of the Action on Monday and Friday, 06:00 each day
ScriptRunner uses external identity providers such as Active Directory, ADFS, Azure AD and more recently others based on OpenID Connect to authenticate users. A very well-known representative of this is Okta's Identity Management.
The underlying idea for user authentication is not to use our own, custom ScriptRunner identities, as many software systems do, but to use existing user and group identities.
In our Portal, ScriptRunner's own Access Groups can be created based on role templates. Thereby each role template and thus each ScriptRunner Access Group implies a combination of access rights and ownerships to elements and functions in ScriptRunner.
External user and group identities from different identity providers are assigned to ScriptRunner Access Groups. This gives a user or group the appropriate access in the ScriptRunner Portal.
Relationship between roles, access groups, memberships and element ownership in ScriptRunner
IMPORTANT: User authentication is not to be confused with administrative access rights to target systems managed by ScriptRunner for running scripts! Both are completely separated as basic security-by-design features.
ScriptRunner uses an implicit login procedure. This means that the user has made a valid login to his identity provider. The details in the login procedure and the protocols differ depending on the identity provider and its configuration. For example, Active Directory uses Windows-integrated or Kerberos, while Azure AD uses MS's own implementation of OpenID Connect.
If the user does not have an identity, ScriptRunner refers them to their identity provider. In case of an invalid identity, i.e. without user or group claims valid for ScriptRunner, the user will be rejected by the ScriptRunner service.
A valid identity with the corresponding claims is mapped by ScriptRunner to the respective permissions via ScriptRunner Access Groups, so the Portal acts role-based. For users assigned to several different roles, the role with the highest permissions applies.
Okta is a leading identity management provider and supports the OpenID Connect standard. For integration, ScriptRunner Server must be set up and configured in Okta using the OIDC method as a single page app. Then, the group claims to be used for ScriptRunner must be defined.
After the setup in Okta, the configuration on ScriptRunner Server follows. First, the group claims stored in Okta have to be stored in the user configuration of ScriptRunner. Claim-based is used as the group type. After that, the settings have to be set up on the ScriptRunner web service endpoint. For this, an SSL certificate is required. The Set-ASRSTSOptions cmdlet is used to configure the AuthMode OIDC for port 8092. Finally, the App.json for the Portal is adapted to this method to ensure redirection for logging in to Okta.
Detailed instructions for Okta can be requested from our support team.
See our Release Video, where we explain Okta Integration (min. 3:50):
Keycloak is an open source identity management whose development is supported by Red Hat. This system also covers the OpenID Connect standard. First, an application must be created in Keycloak, then the groups and claims are set up, as well as the scopes for ScriptRunner.
Once that is complete, the group claims can be stored in ScriptRunner. The customization of ScriptRunner Server for Keycloak is also done with the cmdlet Set-ASRSTSOptions using the AuthMode OIDC for port 8092. Finally, the App.json for the Portal is adapted to this method to ensure the redirection for logging in to Keycloak.
Detailed instructions for Kecloak can be requested from our support.
With the Portal Edition R5 the way to the renewed backend technology is taken. An important aspect is the complete operation of ScriptRunner via its own web API. This has the following advantages:
As an intermediate step, there will still be two setup packages. The trial package for test customers contains only the new service setup including the Portal. The full package contains both, the new service setup and additional setups to install the Portal and the Admin App on the IIS as well as the desktop apps.
When updating in existing ScriptRunner installations, nothing changes. The existing settings and the previous operation of the Portal via the IIS as well as the service endpoints at port 8091/8092 are kept. After the new service setup, the web apps setup for deploying the Portal and optionally the admin web app must be run on the IIS. The optional setup for the desktop apps includes, among other things, the ISE add-on.
Existing ScriptRunner service operation with IIS can only be converted by manually removing the IIS binding and reconfiguring ScriptRunner Service on the 80/443 endpoint and the App.json for the Portal.
If the new service setup is run as a new installation, it will always default to the web API for the Portal as well as the service endpoint 80 (http). To switch to https, the service endpoint must be provided with a certificate and set to port 443.
The procedure for migrations is the same as the previous steps. The only difference is that the new servers are implemented without IIS and the need for port 8091 is eliminated.
To be able to monitor the web API of ScriptRunner more easily, a separate health check URL according to RFC has been implemented. This allows monitoring systems to monitor the web API, load balancers or third party systems to check if the ScriptRunner service is available before calling the web service connector.
The settings cmdlet Test-ASRUri also uses the new option.
https://support.scriptrunner.com/articles/server/system-health
The functions for the no-code UI are regularly extended and improved. In Portal Edition R5, there are two new options:
[Parameter(HelpMessage="ASRDisplay(ReadOnly)")]
[string]$MyReadOnlyField
With this option, you can display form fields with values as information only, but they cannot be modified by the user. For example, a multiattribute query returns a JSON object with multiple parameter-value pairs, of which those with the ASRDisplay(readonly) parameter attribute are grayed out in the UI and are displayed as unmodifiable.
https://support.scriptrunner.com/articles/coding/read-only
[Parameter(HelpMessage="ASRDisplay(Checkbox)")]
[bool]$MyBool
This option changes the display for the [bool] parameter type. Instead of a selection with $TRUE and $FALSE, a checkbox is displayed now. An activated checkbox corresponds to $TRUE, otherwise $FALSE.
https://support.scriptrunner.com/articles/coding/logic-input
We created some Actions and provide an easy way to takt a first look at our product. No registration, no download – no time to lose!
Sep 30, 2024 by Frank Kresse
We have just released our latest ScriptRunner update, version 7.1, packed with powerful new features aimed at making IT...
Aug 16, 2024 by Heiko Brenn
Welcome to Scriptember! We are thrilled to announce the launch of a unique, month-long campaign dedicated to...
Aug 14, 2024 by Jeffery Hicks
I'd like to think that because you are reading this, you are a professional PowerShell user and this article will be a...
Frank Kresse is Head of Product and CEO of ScriptRunner. As the inventor of the automation and delegation solution for PowerShell, he advises clients on use case scenarios and develops solutions for the automation and the digitalization of their processes. He is also involved in technology start-ups.