Skip to the main content.

ScriptRunner Blog

ScriptRunner Portal Edition R5 – Mission accomplished

Table of contents



Post Featured Image

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.   


New with this release:

  • New in the Portal: Query configuration
  • New in the Portal: Action configuration
  • New in Server: Authentication of users via OpenID connect, support of OKTA
  • New in Server: Complete Portal operation via web API without IIS on port 80/443
  • New in Server: Web API healthcheck URL
  • New in no-code UI: Additional ASRDisplay options


Discontinuation ScriptRunner 2020 all releases

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.


New in the Portal: Query configuration

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.

01_queries_active directory or azure

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.

02_new azure query

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.

03_new azure query - list

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.  

04_new azure query - execution mode

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.

05_list of USERs from AD- NEW

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.


Mission accomplished – Here is our release video: 



New in the Portal: Action configuration

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.

06_action_details - reset an AD account password

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. 

07_action_details - out-of-office message

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.

08_action_details - HTML report

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.

09_action_details - out-of-office message

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.

10_action - weekly execution

Example for weekly execution of the Action on Monday and Friday, 06:00 each day


Authentication via OpenID Connect

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.


Basic User Identity in ScriptRunner

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.


11_element ownership_access group-1

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.


Login Operating Principle 

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 Integration 

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 Integration

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


Operating the Portal via Web API on Port 80/443 without IIS

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:

  • ScriptRunner Service does not need IIS on the server anymore.
  • Communication between Portal and ScriptRunner Service takes place over the same port.
  • ScriptRunner Service can now also be operated on standard port 80/443. This makes it easier to enable access from different infrastructures and home offices.
  • ScriptRunner Service only uses the Portal. The old web apps as well as the desktop app are no longer needed.

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. 


Updates in Existing Installations 

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.


New Installations

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.


ScriptRunner Server Healthcheck URL

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.


Additional ASRDisplay Options in No-Code UI

The functions for the no-code UI are regularly extended and improved. In Portal Edition R5, there are two new options:


New Parameter Attribute ASRDisplay(ReadOnly)


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.


New Parameter Attribute ASRDisplay(Checkbox)


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.




One Click Away: Select a Role and Try out Some Actions 

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! 

ScriptRunner-try it out now




Related links

Related posts

19 min read

ScriptRunner Ultimate Edition 6 – AI‑powered scripting

13 min read

ScriptRunner Portal Edition R5 – Mission accomplished

17 min read

ScriptRunner Portal Edition R4

About the author: