The new Authentication Providers will give the administrator the option to authenticate the agent using SRW/TK machines against one of these Identities, prior to launching the application. That way the ThinScale Team has added another layer of security whereas a user has to fully authenticate against an Azure AD or a Ping Authentication in order to fully launch SRW or TK.
Additionally, the admin can use the below option to rename the device which authenticates with one of the below Providers, inside the management console.
Note: rename a device using Ping is currently not supported
Note: ThinScale is not in control of any of the settings in either Azure, Okta or Ping. So please talk with your Administrator for more info.
Create a new App Registration
Click New Registration, give it a name and select public/native mobile and desktop
Client Id and Tenant Id
In your Azure Portal, new App Registrations must be created beforehand in order to retrieve this information.
The type of user interaction that's required.
ForceLogin = The user will be prompted for credentials
SelectAccount = The authorization server's authorised endpoint which would present to the user a list of accounts from which one can be selected for authentication.
AskConsent = Consent is the process of a user granting authorization to an application to access protected resources on their behalf. An admin or user can be asked for consent to allow access to their organization/individual data.
Create a new Scope if you don’t have one. Click Expose an API
Token Validation v7.1
The audience is your app's Application ID, assigned to your app in the Azure portal, or simply the Scope API without the Scope Name
From Overview click Endpoint and copy the value from OpenID connect metadata document
If enabled, and validity is set up, the user will be asked to re-authenticate after the specified number of hours.
Force Server-Side Validation
Forcing a Server-Side validation will ensure that not only the client token is validated against an app registration in azure, but it also gives the ThinScale server the capabilities to authenticate that the client token is a real token coming from the app registration and not an impersonate one.
Create a new App Registration for server-side validation alongside the one previously created.
The API Name is the Display Name of the App Registration
A new client secret must be created before:
- Click “Add new client secret
- Enter a description for example “MgmtSrvClientSecret”
- Set the expiration parameter (once the client secret has expired, the Management Server will not be able to perform the token validation and will have to set a new client secret again on the portal while also updating the console value as well)
- Click the “Add” button
- Once the client secret has been saved, it will be listed on the page. Copy the value, once you leave the page it will not be possible to visualize this value again and you will need to regenerate another client secret.
NOTE: Although the Console displays the value as "Client Secret Id" this is NOT the Secret ID but the Value from the Azure App Registration
Select from the left tab “API Permissions”. Click Add permission.
Click on “Microsoft Graph”
Click on “Application Permission”
Scroll down until you find the “User” category, click on it, then select the checkbox “User.Read.All”
Make sure you "Grant admin consent for "tenant name" " is selected.
Azure Group Object Ids
Optionally authorise the user by adding one or more Azure Active Directory Group Ids.
If a group Id is included in the configuration, any authenticating user must be a member of at least of the groups specified in the list to complete the authentication.