Lead Image © scyther5, 123RF.com

Lead Image © scyther5, 123RF.com

Quick and easy SaaS provisioning for OpenLDAP

To Each His Own

Article from ADMIN 47/2018
By
Provisioning SaaS apps for OpenLDAP users with Okta Cloud Connect lets you retain control of your users' data and access to applications, yet gives them the tools they want.

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • LDAP integration with popular groupware suites
    Your LDAP directory holds user data for the whole network. Why not save time and avoid duplication by integrating the LDAP directory with your groupware environment?
  • OpenLDAP Workshop
    Centralized user management with LDAP or Active Directory is the standard today, although many prefer to manage user data manually rather than build this kind of infrastructure. In this article, we look at a better approach with OpenLDAP.
  • What's new in Samba 4
    In December 2012, the open source world received the first, and very long awaited, release of the Samba 4.x series.
  • Migration from LDAP to FreeIPA
    The change from centralized user authentication on a vanilla LDAP server to the FreeIPA identity management solution is easier than many admins think. Given attention to a few points, the migration takes very little time and effort.
  • Samba 4 appliances by SerNet and Univention
    Shortly after the Samba team finalized Samba 4 in December 2012, SerNet and Univention integrated the new Samba into their appliances that give administrators an easy way to set up and test a Samba 4-based Active Directory domain controller.
comments powered by Disqus