Learning Center/General education/For Software Vendors

Enabling identity management in your application

Thomas Pedersen
posted this on September 25, 2010 03:45 pm

Identity management is usually not one of the first features SaaS vendors implement, which is no wonder. It's not at the top of the requirements list when customers are going to make a purchase decision. But it's a but like plumbing. It's not the biggest selling point, but it's rather inconvenient if your home doesn't have it.

Single sign-on

First and foremost, you should provide a single sign-on protocol. We recommend using SAML for a number of reasons, but OpenID or a proprietary protocol will also work. As long as you allow your customer to sign in users without the use of a password and follow a few guidelines.

Single sign-on is not just about convenience, it's also about security. An enterprise owns its employees identities in the SaaS application it uses and the enterprise should be able effectively manage those identities. For example, when an employee leaves a company, the company should be able to prevent that employee from accessing all its cloud apps. You can help the enterprise achieve this by providing a few settings in your application.

  • Disallow username/password login – when customers are using your SSO protocol, they usually want to disable employees ability to sign in using a password. You should provide a setting for this.
  • Disallow password resets – prevent users from changing or resetting the password via email.
  • Disallow email address change – companies usually want users to only use their work email address as this is one that the company controls. Don't let the user change it to a personal email address.

In addition to the settings above, there are some common best practices you should follow.

  • Enforce session timeouts – Don't let users be signed in indefinitely, but expire idle user sessions. Use the session timeout value from the SAML response or have a setting per account. When user clicks on a link in the app after the session has expired, your app should send a SAML request to the identity provider to see if the user is still authorized to sign into your app.
  • Force sign-in – If the application receives a sign-on request, but the user's browser already has an active session, replace that with a session for the new user. This reduces the risk of a user inadvertently seeing someone else's data and it also helpful  to people who use SSO portals to sign into different accounts in the same application.

If you follow these simple guidelines, you are enabling companies to much better management employee identities in your application. 

User provisioning API

If your application is multi-user and your customers typically have many users in your application, you should consider offering a user provisioning API. This allows identity management providers to remotely manage users in your application, which can yield huge efficiencies for your customer as well as increased security because it enables one-click de-provisioning.

Unfortunately, there are no widely adopted standards for this and we recommend that you go with a simple RESTful API. Many of the modern web applications have RESTful APIs and they are easy to understand and easy to integrate with. Here are the provisioning operations you should support.

  • Find user (by email or ID)
  • Create user (name, email address)
  • Delete user
  • Update user
  • Suspend user
  • Reactivate user

If your application has any critical user-level attributes such privileges, groups or departments, you should also provide API functions for extracting those so identity management providers can build more robust integrations. The create and update functions should also support those attributes although you can opt to manage those via separate functions.

Next steps

If you have not yet prepared your app for identity management, we welcome a conversation about how OneLogin can help.