Management Authentication Providers Okta

Management Authentication Providers Okta #MC-KB20

Written by Giuseppe

Last published at: March 25th, 2022

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, LDAP, Ping Authentication or OKTA 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, Ping or Okta.  So please talk with your Administrator for more info.


Okta

Before you start creating all the below configurations on the Okta side, keep in mind that the user logged in must be a "Super Admin".

If that is the case, please follow the step as they are or the Okta Provider may not work as expected.


Application Creation

In order to use The Okta Authentication Provider for both SRW / Console and Server Side Validation, 2 Applications Integration have to be created. Let's create the first one

Log in to your Okta Dashboard and click Create App Registration




SRW - Console Application Integration


For SRW and Console OIDC - OpenID and Native Application Connect must be utilized.


Click Next, give it a name and select the following options. Then click Save



https://login.microsoftonline.com/common/oauth2/nativeclient 


Note: a redirect URIs can be any web page, via HTTPS, internal to the company. The ThinScale Team used the Azure redirect as an example. 

Note: if groups are already created in the Okta Directory, limited access can also be given to this application, as seen below. Once done click Save



Once done click the Application you just created and then General.  Save into a Wordpad, notepad or anything you like the Client ID, the Okta domain and the redirect URI as you will need them inside the ThinScale console.




 Move Over to Security and API and click Add Authorization Server





 Give it a name, an audience and a description. The audience is important so please use the following naming convention

Click  Save


Save into a Wordpad, notepad or anything you like the Audience, the Issuer and the Metadata URL as you will need them in the console.


Move to Scopes

There are already different scopes pre-populated for you, however, a new one is needed for our Auth Provider. Click Add Scope, give it a name and Enable "User consent". Click Create. 

NoteThis scope is needed inside the Console, so please save the name somewhere


Click Claims



There are three claims that are needed. Click Add Claims. Claims are case sensitive so please create all of them the way you see here.

Add the Auth Scope previously created. You can start typing and the name will be pre-populated for you.








Once done click Access Policies. Add a New Policy and the client name. You can start typing and the name will be pre-populated for you.

Add a Rule within it. Give it a name and enable just the following options.

Note: those 3 numbers must match the number on the console, so, please make sure correct values are assigned.


Click Token Review and if everything is green you are good to go to the next step.






Server Application Integration

For the Server Integration, API Services must be utilized

Click Next, give it a name and select Save 


Please note, Client ID, Client Secret and Okta domain are all values that are needed inside the ThinScale Console, so please copy them or make sure you know how to retrieve them later.


Move Over to Security and API again and click Add Authorization Server. The steps below are similar to the previous one, but there couple of differences.

Please follow them along.


Save into a Wordpad, notepad or anything you like the Audience, the Issuer and the Metadata URL as you will need them in the console.



Click Scope and Add a new Scope. The server doesn't need any user consent. So just give it a name, a description and click Create. Once done move to Access Policies. Server Auth doesn't need any Claims.


Add a new Policy and like before a new Rule


Click Add Rule now. 

As you can see scopes and client actions are different from the SRW integration. Please select the below options and click Create Rule


Job done. You can now Preview the token.

The last missing piece is the SSWS Token. Click on Security API and the Tokens.




Click Create Token. Give it a name and make sure you copy the value generated.

Note: that the value will only be displayed once and cannot be retrieved.





Your new Okta Authentication Provider back end is now complete.

The last step is to populate the items in the console with all the above information. However, there are some steps you need to follow.

The items on the left side of the Okta dialog belong to the SRW - Console Application Integration

The middle options belong to the Server Integration and finally,

The right-hand side is configurations that a user must perform manually.

SRW 


SERVER


Please Note: You cannot lookup ID before the Apply Domain config is enabled. 



Give the API Service Name a name, type or paste the SSWS Token you copied previously and Click Apply Domain Config. If everything goes well you will see a successful message and a new Application will be displayed inside the Okta Dashboard. 




Once done please click Add.

Go back to the console and the Lookup ID by name will be now enabled.

Assuming the Groups exist inside the Okta Dashboard you will be able to search them by name