To Each His Own

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.

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).

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.

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

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.

Adding a Master Directory

With your master directory now set up to provide an authoritative record as to which apps should be allowed for which user, you can now set up directory integration on Okta. To get started, sign in to your Okta admin console and select Directory | Directory Integrations | Add Directory | Add LDAP Directory.

Okta walks you through this wizard-style process. You need to select a version of the Okta LDAP agent that is suitable for the server on which you intend to run it: RPM or DEB. You can copy the URL of your chosen installer and download it to your server with wget. To run the installer, enter:

$sudo dpkg -i OktaLDAPAgent-05.04.06_amd64.deb

Configure the agent to start automatically whenever the server starts. You want it to be running all the time so that your Okta directory always stays in sync with your master directory. Helpfully, Okta will email you immediately whenever it detects a change in the agent's online status.

$sudo update-rc.d OktaLDAPAgent defaults

Finally, start the agent:

$sudo service oktaldapagent start

The first time you do this, the agent will prompt you to enter your LDAP server credentials, Okta subdomain, and Okta account information. The agent will then start its process of long-polling your Okta account; the setup web page on your Okta account will automatically update when the agent starts communicating with it and will then take you to the next step of the process, which asks you to configure your directory integration settings. You will run into a couple of gotchas here, so it's worth showing a number of screen shots. Figure 5 shows the initial UID mappings.

In the unlikely event that your LDAP user object doesn't include a uid (User Name) attribute, you'll need to add one – Okta requires it. Finally, the all-important group settings allow you to assign individual apps per user (Figure 6).

Finally, you'll be prompted to select an Okta username format, which has to be in the form of an email address and can be either an email address pulled direct from your LDAP user objects or one composed of an LDAP username plus a specified domain. To verify your directory integration settings, enter an example username that corresponds to one of your real LDAP users, and Okta will attempt to import that user into its own directory (Figure 7).

Activating Users

You'll now be prompted to do an initial import of your directory, which populates your Okta directory with all the users and groups that meet the filter criteria you entered in the directory integration settings. Because (in this case) your LDAP directory is the master, you do not need to marry up your LDAP-imported users with users from any other source, so you can confirm all these assignments right away.

When your new user assignments are confirmed – either as part of your initial import or as part of subsequent incremental imports that you can configure to run on a schedule of your choosing – each newly confirmed user will receive an email inviting them to sign in to their Okta account. Given Okta's background as a provisioning/SSO service, rather than an actual application, there is some scope for user confusion, so you can choose to suppress these email messages if you prefer to handle this communication yourself. However, in situations in which you want to give users control over which apps they activate in their Okta accounts, you should allow delivery of this email.

The final step in directory integration is to schedule your regular imports. In this use case, in which the LDAP directory is the master and you want to keep your Okta directory synchronized as closely with it as possible, I don't see why you wouldn't go for the most frequent option, hourly (Figure 8). You can also force an import at any time you like under the Import tab.

With the Okta directory happily slaved to your master LDAP directory, you can turn your attention to the SaaS application(s) you want to provide to your users. You can use Okta purely to provision and de-provision accounts and allow your users to fend for themselves when it comes to password management, or you can give them SWA (see also the "SWA and SAML-Based SSO" box); if the app supports it, you can allow full single sign-on, so they'll use the same password for their SaaS apps as they already do for their internal apps currently linked to your LDAP directory.

Provisioning Options

From the Applications menu of your Okta account, work through all the available tabs for your chosen app. Most of the configuration is self-explanatory, and you can do whatever you please. The Sign On tab is where you'll choose between SWA and SSO (the exact options available here depend on what an individual application supports). Figure 9 shows the options available for Dropbox Business, with SAML 2.0 being their SSO protocol of choice; the setup instructions will tell you the corresponding settings to configure on your Dropbox Business admin console.

The Provisioning tab is where you'll configure Okta to provision and de-provision a users' accounts in the app automatically. The relevant options are disabled by default. The Import tab isn't relevant here – it refers to backporting existing user accounts from the app into your Okta directory and, optionally, from there into your LDAP directory. If you want to ensure that your LDAP directory remains the master of all it surveys, you should check all import settings in detail to make sure there's no way that Okta can write anything into it.

By this stage, Okta is configured to manage sign-on and provisioning for your chosen app. All that remains is to tell it which users to enact this on. Here, you rely on the fact that the LDAP directory integration pulls in all of your LDAP groups and users.

Assigning Application Groups

To check whether you can see your OpenLDAP application groups, go to Directory | Groups and edit the entry that corresponds to your application by clicking on its name (Figure 10). Click the Manage apps button, and then use the Assign Applications to DropBoxBusinessUsers dialog (in this case) to select the application that is being assigned to this group.

Assigning an app to a group of confirmed Okta users is the final step in making this integration achieve a useful result. It should immediately provision those users in the app, and, depending on the app configuration, the users will receive activation email from the app itself and be able to start using it, with their sign-in method determined by the SWA/SSO choice made at the Okta application configuration stage. To revoke a user's access to the app, remove them from the LDAP group; to restore it, just re-add them. (You'll need to wait for the next scheduled Okta import in both cases, and you should receive email after every import that results in changes.)

Testing Your Integration

This integration has quite a number of moving parts and scope for unexpected outcomes. Given what's at stake – access to critical data and applications by people whose jobs will either depend on the access or, conversely, who should absolutely not have access at all – Table 1 runs through a comprehensive set of tests.

Conclusion

Don't let your users suffer in a SaaS desert on account of directory management worries. By integrating your LDAP directory with cloud-based SaaS providers, you can achieve the dual aims of retaining control over your users' data and access to applications, while giving them the tools they want.