Hello everyone,

this sprint, we've added more awesome features to Indicium Universal, the most important of which is the migration to .NET 5. Below you can read about the benefits of this migration. We also worked hard, among other things, on authentication and further improved security.

We'll keep you updated regularly about Indicium's progress. You can read the Indicium user manual to read about Indicium's features. 

Download Indicium 2021.1.17 here.

Indicium Universal

As of this version, Indicium Universal will be running on .NET 5. This means that in order to run Indicium Universal on IIS, you need to install the ASP.NET Core 5.0.4 Windows Hosting Bundle.

The update to .NET 5 offers the following advantages compared to Indicium Universal version 2021.1.16:

• Platform independence: all releases of Indicium Universal from this point onward can run on Linux and macOS as well.
• Performance: this version of Indicium Universal has multiple big and small performance improvements compared to 2021.1.16. The two request types which benefit most are those that return a lot of data in the response and smaller requests which were already quite fast. Overall, you can expect an improvement of around 10-40% in response times, depending on the request and various variables.
• Maximum load: though hard to quantify, this version of Indicium Universal will be able to handle more load than version 2021.1.16, meaning that a single instance of Indicium can handle more concurrent users.
• Data usage: the response sizes are roughly 30-40% smaller in this version of Indicium Universal. This is part of the performance improvement described above, but it also means that clients will use less data and that the performance improvement will scale higher on poor network connections.

The update to .NET 5 allows us to improve the performance even more in the future!

The following components of Indicium Universal still require .NET Framework version 4.7.2 or higher (NOTE: not .NET 5). Without .NET Framework 4.7.2 or higher installed, Indicium Universal will start, but these components will not work.:

• CrystalReports.
• DevExpress reports (will be .NET 5 compatible in the near future).
• SQL Server Reporting Services.

Using this version of Indicium for DB2 databases requires some additional installation steps which have been outlined in our Installation manual.

Some of Indicium's authentication features, such as Single Sign On (SSO) and Single Logout (SLO), require Indicium's authentication cookie to have the samesite=none attribute. Chrome has recently made a change that causes cookies with this attribute to only work when the cookie is secure, meaning that the cookie was requested and received over a secure channel (i.e. https://). Consequently, you can no longer log in over http:// when using Chromium-based browsers such as Chrome and Edge, and this behavior will likely extend to more browsers in the future.

We already require usage of https:// in production environments, but if you must do testing over http:// then a different, non-Chromium browser needs to be used, such as Firefox. We will look into minimizing the inconvenience of this in our next release, by looking into not using the samesite=none attribute when it is not required. However, since we can no longer guarantee that all of Indicium's features will work over http://, we recommend using https:// for both development and testing environments.

Authentication through OAuth 2.0 Bearer Tokens

Being an Identity Provider, Indicium already served access tokens, but these tokens could only be used to fetch user claims and not to access Indicium's API itself. As of this version, we’ve added support for the JWT Bearer authentication scheme that allows access tokens to be used as a means to authenticate users for API access.

Note that this feature is specifically meant for third-party clients and won't be used by our own clients such as the Universal GUI.

A third-party client will receive an access token after a user has authenticated and given consent that the client may access the API on their behalf. The client can then make a request to Indicium’s API, using that token in the Authorization header. An access token will give access to all APIs that are available to that user, no more and no less.

For this feature to work, an OpenID client needs to be configured in IAM (menu OpenID > OpenID clients). Be sure to check the API checkbox for the OpenID client and add a redirect URL and client secret. Furthermore, the location of the Authority, which is the URL to Indicium, needs to be provided by means of the BearerTokenAuthority setting in Indicium's appsettings.json. This Authority URL must use 'https', e.g.:

{ 
  "BearerTokenAuthority" : "https://localhost:5001" 
} 

Once the OpenID client and Authority URL are configured, an access token can be requested like this (in the example below, the API tool Insomnia is used):

• Grant type: Indicium uses OAuth 2.0’s Authorization Code Flow which exchanges an Authorization Code for a token. For more information, see https://auth0.com/docs/flows/authorization-code-flow. Optionally, PKCE can be used as well if the client is deemed insecure.
• Authorization URL: This endpoint is used to retrieve an authorization code via the browser and involves authentication via the login prompt and (when required) consent. The Authorization URL can be retrieved by calling the following endpoint on the Authority URL: <Authority URL>/.well-known/openid-configuration. Typically, the authorization URL looks like this: /connect/authorize.
• Access token URL: This endpoint is used to retrieve the access token. Just like the authorization URL, the Access Token URL can be retrieved by calling the following endpoint on the Authority URL: /.well-known/openid-configuration. Typically, the Access token URL looks like this: /connect/token.
• Client ID, Client secret and Redirect URL: Client information from IAM.
• Scope: This should include full_api_access in order to obtain an Access Token that gives API access. Other scopes such as openid, profile, email, etc. can be requested simultaneously if necessary.

When in IAM is configured that consent is required, the following consent page will appear. Only after allowing, Indicium will give out the access token.

Please be aware that at this moment, Indicium only gives out access tokens, the exchange of a refresh token is not supported. Access tokens are valid for one hour.

PKCE support for OpenID

We've added PKCE support for OpenID to reduce security risks for native apps.

PKCE is short for Proof Key for Code Exchange. It is an OAuth 2.0 security extension for public clients on mobile devices, to avoid a malicious program creeping into the same computer from intercepting the authorization code.

Single Logout (SLO) for external OpenID Identity Providers

In this version of Indicium Universal, we have augmented our support for authentication through external Identity Providers with Single Logout (SLO). This means that it is now also possible to log out of the external Identity Provider in an integrated way from Indicium's log out page if you were logged in with an external Identity Provider (see OpenID connect).

In order to use Single Logout on top of this, we have added two new properties to the configuration in the appsettings.json: SignOutButtonIcon and SignOutButtonText. These properties allow you to configure the sign-out button that will appear on Indicium's logout page:

"OpenIDConnect": {
 "IdentityProviders": {
  "Microsoft": {
   "MetadataEndpoint": "",
   "ClientId": "",
   "ClientSecret": "",
   "ButtonIcon": "microsoft.png",
   "ButtonText": "Sign in with Microsoft",
   "SignOutButtonIcon": "microsoft.png",
   "SignOutButtonText": "Sign out of Microsoft" 
  }
}

The type of SLO that Indicium supports is called front-channel logout. The way it works is that Indicium will redirect the user to the logout page of the external Identity Provider where the user can log out. Upon doing so, the external Identity Provider will send a logout call back to Indicium before redirecting the user back. This logout call will need to be configured at the external Identity Provider. Taking Microsoft's Azure Active Directory as an example, the screenshot below shows how you can configure the front-channel logout URL. Just like how the post-sign in redirect URL is /signin-{name} — where {name} is the name of the Identity Provider in the appsettings.json — the front-channel logout URL is /signout-{name}.

If the Identity Provider is configured as the DefaultIdentityProvider, then the Indicium logout page will not be shown, but it will be as if the Sign out of X button is clicked automatically, immediately redirecting the user to the external Identity Provider's logout page.

Partial support for the report parameter property "Export Path"

Indicium now partially supports the Export path report parameter Property. This property can be selected in the menu Processes > Reports > tab Report parameters > tab Form > tab Report parameter > field Property.

Indicium still won't export report results to disk, but it will respect the file name provided in the download that it offers to the client. Indicium will determine the download file name as follows:

1. If there is a Report parameter with the Export Path property:

   • If the value of the parameter is a file path that ends in a file name, Indicium will use this file name. If the extension is incorrect, Indicium will correct it to, for instance, .pdf.
   • If the value is not a file path or it does not end in a file name, Indicium will use the translation of the report as the file name.

2. If there is no report parameter with the Export Path property:

   • Indicium will use the translation of the report as the file name.

3. If the report does not have a translation, the report ID will be used instead.

Minor fixes and tasks

• We've fixed an issue with the $export request parameter when the selected data set contained a column with data type 'TIME'.

• We've fixed an issue that caused the OpenID Authorization Code flow to fail sometimes in load-balanced environments when using Indicium as the Identity Provider. To fix this issue, Indicium will augment the IAM database with three new tables upon starting:

  • dbo.__EFMigrationsHistory
  • indicium.DeviceCodes
  • indicium.PersistedGrants.

  Multiple load-balanced instances of Indicium need these tables to communicate intermediate tokens with each other in order to have the Authorization Code flow succeed when not every request goes to the same instance of Indicium.

• We've fixed an issue for message protocol independent process flows that caused responses with content types likes application/json or application/xml to be returned as if they were string literals. For example the response
  { "some_property": "some_value" }
  would erroneously be returned as
  "{ \"some_property\": \"some_value\" }"