The benefits of cloud-hosted applications need no explanation, but in many large organizations with an on-premises mindset, the seemingly mundane task of provisioning Software as a Service (SaaS) for their users presents such technical and administrative challenges as to be an insurmountable hurdle, so users are denied access to the tools they want or are forced to find their own. Identity as a Service (IDaaS) providers such as Okta help lower the barrier of inconvenience by integrating with on-premises LDAP and Active Directory servers, allowing the master directory to remain unchanged while providing full provisioning and sign-on control of a huge range of SaaS applications.

Benefits of this approach include:

• Faster on-boarding of new employees (by being able to set up all their SaaS accounts in one fell swoop).
• Convenient and secure termination of employee accounts (disabling or deleting their LDAP account will immediately prevent them from accessing all their associated cloud apps).
• Single sign-on (SSO), a single place for users to reset their password, and a unified portal (in Okta) for all SaaS apps available to the employee.
• Increased oversight and security of company data – employees are no longer forced to "go it alone" and sign up for their own cloud apps that they then use for handling company data.

In this article, I demonstrate how to create, update, and delete end-user accounts easily in a token SaaS app – Dropbox Business – by linking Okta Cloud Connect to an on-premises OpenLDAP directory. All the interaction with OpenLDAP is simple, and you use whichever LDAP interface you like. Here, I'm using the command line and some screen shots from phpLDAPadmin [1]. I will be able to grant or deny an individual's access to my Dropbox Business account by means of adding and removing a memberUid to and from an LDAP group object, with no other actions required. I will also ensure that when the user's LDAP object is deleted or a custom enable/disable attribute is set to False , the Dropbox Business account access is also removed. I'll look at the two options that Okta provides to help users sign in to their cloud apps: Secure Web Authentication (SWA) and Security Assertion Markup Language (SAML)-based SSO. Finally, I list some simple test cases to make sure the complete integration works as expected.

Okta Cloud Connect

Okta is a well-known IDaaS/SSO provider. It's certainly not the only show in town that enables this type of provisioning, and the general principle of the integration explained here holds true for other providers, but the huge range of supported apps (approximately 5,500 at the time of writing) and the fact that Okta Cloud Connect is free make this a good choice for experimentation. Customers maintain directories in their Okta account, which are then used to provision and manage SSO for a range of apps that is configured and curated by you, the administrator.

Populating your Okta account directory can be accomplished in many ways, including the time-honored method of repeatedly filling out a web form asking for First Name, Last Name, Email address, and Password, but the method of interest here is "directory integration." In this use case, the Okta directory is enslaved to an on-premises master LDAP service: Active Directory, OpenLDAP, or any of a number of similar alternatives. The challenge of cross-firewall synchronization is solved by means of a lightweight Java agent supplied by Okta and running on an on-premises server that has direct access to (or could indeed be) the master directory server [2].

Figure 1 shows how the various components of this integration communicate with one another. Okta Cloud Connect restricts your account to a single application, which might be sufficient for some use cases, but more likely you'll end up wanting to upgrade to full-strength Okta to provision your users with multiple cloud apps. Either way, the process described here is the same.

Figure 1: OpenLDAP and Okta integration.

Creating an Okta Account

When you sign up for an account online [3], you'll be prompted to choose your one free app, which will subsequently appear as the only app you're allowed to assign under the Add Application section (Figure 2).

Figure 2: Selecting your application in Okta Cloud Connect.

If you subsequently change your mind about the app you want, as I did in the course of writing, you can't change it through the web interface, but the Okta support team is able to change it for you on their back end. I'll assume you already have a suitable account with your chosen app's service provider. Many service providers offer business accounts, or something named along those lines; usually that account type offers the features necessary for integration with Okta. For example, you cannot complete the integration I discuss in this article with the free domestic version of Dropbox.

Creating Groups and a Schema

Your master directory is going to be the source of truth regarding who should have access to which SaaS app. The Okta LDAP directory integration allows you to specify a Group Search Base container, within which it will look for objects of a specified class and add those as groups within your Okta account. It's then straightforward to configure your Okta account to assign a given app automatically to any member in a group (Figure 3), and there's no limit to the number of groups that Okta will import from your directory in this way, so this method scales nicely.

Figure 3: When your integration is complete, adding and removing users in an LDAP group such as this will automatically cause the users' accounts in the corresponding SaaS app, as mapped in your Okta configuration, to be added or removed.

You could also specify a global activate/deactivate flag for each user. This will determine whether or not a user's Okta account should be active or not. Deactivating a user's Okta account will prevent the user from logging in to Okta, as well as any of their assigned SaaS apps. For this purpose, I created an object class (Figure 4) and added it to my schema with

sudo ldapadd -Y EXTERNAL -H ldapi:/// -D "cn=config" -f oktaflag.ldif

Figure 4: Adding a custom object class to the OpenLDAP directory schema for enabling and disabling all cloud app access.

With this object class added to each of your user objects, the custom attribute AllowOKTAApps can then be specified in Okta's Account Disabled Attribute setting to indicate whether a user account should be enabled or disabled.