How to set up Okta as a Client Provider in Anypoint


When providing authorization and authentication mechanisms to our mule apps, one of the best practices that I always recommend to all my customers is to rely on an external Identity Provider (IdP).


It’s true that API Manager in Anypoint provides us with built-in policies like client id enforcement or Basic Authentication but these might not be secure enough, especially for our experience APIs which would be the ones that are more exposed externally. An external IdP will give us an extra layer of security.

One of the most commonly used in this scenario is Okta. In this post, we will see configure Okta in our Anypoint platform to be used as an Open ID server for our Mule apps. This way we will an example of how to add a new Client Provider in Anypoint.

Prerequisites

Before we configure anything in our Anypoint platform we need to have an Okta instance. For testing purposes you can use a trial (valid for 30 days) or you could sign up for a developer account in Okta.

Create a new Client Provider in Anypoint

Go to Access Management > Client Providers and click on Add Client Provider. Select the option OpenID Connect Dynamic Client Registration


Next, let’s see in detail all the values we need to provide to set up Okta as a new Client Provider. You’ll find a few sections in the form:


Client Information

Provide a name and description for our new client provider

Dynamic Client Registration

To provide the requested info in this section we need to go to our Okta instance > Security > API. Here we should see at least one Authorization Server (the default provided by Okta). Click on it to see its settings


In the settings section there should be a link for Metadata URI. Click on that


That link should show you in the web browser a JSON document with quite a bit of information. For now we’ll copy the issuer and the registration_endpoint, which correspond to the values of Issuer and Client Registration URL in the Anypoint form


We also need to provide the Client Request Timeout. This would be the maximum number of seconds that Anypoint will wait to get a response from Okta when requesting a new client registration. The default will be the minimum, 5 seconds.


Click on the Advanced Settings and select the last 2 options:
  • Enable client deletion in Anypoint Platform - This will allow us to delete Client Applications from Anypoint, but be aware that with this option only they won’t be removed from Okta
Enable client deletion and updates in IdP - This option requires the previous one enabled, and with this option enabled we will be able to edit and delete client applications in Anypoint and Okta as well.

We will skip for now the Authorization Header and the Token Introspection Client (we’ll get back later on how to get these values)


OpenID Connect Authorization URLs

The values in this section are in the Metadata URI we got in the previous step. The values we need are: 
  • Authorize URL - Look for the authorization_endpoint in the Metadata URI.
  • Token URL - Look for the  token_endpoint in the Metadata URI.
  • Token Introspection URL - Look for the introspection_endpoint in the Metadata URI.



Authorization Header

To get the Authorization Header get back to Okta and go to the list of Authorization Servers. Click on the Tokens tab and then click on Create Token


On the Create token form, provide a name to the token (Anypoint in this example) and select Any IP as the origin of the API calls. Click on Create token

The token for our Anypoint platform has been created. Make sure you copy that value before closing this window as it won’t be available anymore in Okta. That’s the value we need for the Authorization Header.


Make sure that, in the new client provider form, you include the prefix SSWS before the token value we’ve just copied.


Token Introspection Client

To get the client id and secret, from Okta, go to Applications > Applications and click on Create App Integration


Next, select OIDC - OpenID Connect as Sign-in method and below select Web Application as Application Type. Then click Next


After that, provide a name for the new Application in Okta (Anypoint in this example) and select the Client Credentials Grant Type:


Scroll down to the Assignments section and here select Allow everyone in your organization. Leave the Federation Broker Mode enabled and click Save


Once your app is created from the General tab copy the client id and paste it in the Anypoint form. Do the same for the client secret further down.


With that, we’ve got all the values required to create Okta as new client provider for our mule apps. Click on create and you should see now a new provider in the list.



Associate Environments

The last step, once our new client provider has been registered is to associate it to the environments where we want to use it with API Manager. For that follow the next steps:
  • From Access Management, click on Business Groups. From the list of Business Groups, click on the BG that contains the environment(s) where you want to make our new Client Provider available.
  • On the BG page, click on the Environments tab. You will see the list of environments and the Default Client Provider associated.

  • Now, click on the environment where you want to enable Okta. A new window will pop up with the option at the botton to select Okta as our Client Provider. Select it and click Update. Be aware that this change won’t affect your existing APIs using the default client provider. This change will only make Okta available for new apps.




With that, we’ve completed the set up to use Okta as Client Provider for our apps in API Manager. In the next post we’ll see How to secure APIs with Okta in API Manager and how to register new client applications in Okta from Exchange.
Previous Post Next Post