[Article] Nine Common Solution Patterns For Identity Management In An Enterprise

Introduction

It’s a fact that siloed applications have no future in a modern business.

One, businesses are opening up APIs; you now can - and need to - open up your data to gain an advantage over the competition. Two, employees work on their own devices; and they have more freedom; they even indulge in what we call “bring your own identity” - where identity is held exclusively in one domain and access is handled by several other domains.

A good example is the Facebook logins that we use for several applications. They do it because it’s fast, easy and convenient. Applications that exist in solitude are an anathema to this progress.

However, these changes also come with identity and security management issues. Enter WSO2 Identity Server (WSO2 IS), which is an open source identity and access management solution. In this article, we will explore a number of use cases and understand how WSO2 IS can be useful in those scenarios.

Problem 1: Kermit Co and its identity needs

Kermit Co is an open source product development company. It has employees, customers, and an open source community.

It has some internal systems used by employees (Office 365, Redmine, Salesforce and Star Accounts). It has some external systems which are used by customers and community. It intends to upgrade its identity infrastructure.

All employees reside in an LDAP in the Kermit data center. Kermit does not want to sync the LDAP to cloud systems, so employees have to maintain several account passwords for the other systems they use. These are, thus, decentralized identities; name and account changes are not synced. As the number of systems grows, this becomes a problem.

Firstly, they need a Single Sign-On (SSO) system; when an employee logs into one system, they should be able to access the others. The problem here is that different systems use different protocols. Office 365 uses WS-Federation, Salesforce uses SAML, and Star Accounts uses Open ID Connect, and so on.

WSO2 Identity Server adds a layer of identity management across these systems to provide SSO.

Now, when the user logs into the first system, it adds a session cookie to the browser. As long as the user uses the same browser (and the same cookie) to access the other system, they will be granted access. This removes a large part of the burden of writing code that can handle identity across different systems and protocols.

Problem 2: Multifactor authentication

Ginger works in Finance. Ginger’s account has been hacked. She’s used a simple password and all finance data from Kermit Corp has been leaked. Kermit decides to introduce multifactor authentication.

This introduces another problem: how many internal systems can handle this type of input? After all, not every internal system supports multi-factor authentication as a built-in feature.

This is where WSO2 IS comes in. With a few step-by-step configurations, Identity Server can provide this kind of security. You can configure password authentication and use protocols like FIDO (which focuses on biometric verification) or SMSOTP (which generates one-time passwords delivered to your mobile) in a sequence of authentication stages to be passed by the user. Different authentication steps can be configured for different applications.

Problem 3: When external users want in

Kermit Corp now has a variant of what they deployed WSO2 IS for. Customers need to authenticate to several customer-facing systems: there’s a website for product downloads, JIRA for reporting issues, a certification portal and a partner portal. All external users, by design, are in a different LDAP - Kermit decided to maintain customers and employees in separate stores.

We can add both identity stores to WSO2 IS, but it’s not an approach we would recommend: external users and employees are different things. External users can scale to large numbers: they can add, modify or delete their records at will; they can use multiple email addresses and fake data. The control of this particular aspect is not within the organization.

Along with the upgrade, Kermit also decides to allow customer-facing systems to have social sign-up/sign-in capabilities. Kermit needs to add these users and perform just-in-time provisioning on the External Users database.

This means two problems: one, Kermit does not have access to the source code of, say, JIRA, in order to add the new sign-up capability; secondly, Facebook and Google use different protocols; for those apps that they CAN modify, this implies a lot of coding for each application, and a lot of error-prone code.

By using WSO2 Identity Server, Kermit can perform identity federation. The website leads them to a login screen; it uses only SAML 2.0 authentication, and WSO2 IS provides the protocol conversion. Kermit resides as a Service Provider in WSO2 IS. We tell Identity Server that the outbound authentication can be the Kermit username and password, Google or Facebook - any of the three. Identity Server is capable of reading the different claims that these services provide - they send out user details differently - and translating the user details as appropriate.

Thus the user is redirected appropriately, logins in and comes back to the Identity Server, which is configured to trust the authentication response from Google and Facebook and logs the user into the website.

If Kermit’s developer selects Just-in-time provisioning, Identity Server will check with the User Store and provisions users appropriately. This allows users to create and sign up immediately, and neatly solves a fairly complex problem.

Problem 4: Users, profiles and hassle-free management

Often it’s not enough to just give users access. Once everyone’s logged into the website, they will need to manage their user profiles. One option is to allow the website to directly access the LDAP. However, this means there will be two systems updating the LDAP: the website and Identity Server. This can cause conflicts.

The best pattern for this is to use APIs available on Identity Server to perform user management. There is a set of standard SCIM APIs to add, delete, read and update users and roles, along with a user management service built into Identity Server. To developers, this is ideal, because they can use REST and SOAP calls - and not LDAP modules.

Problem 5: When employees want to connect out

We’ve considered the employees of Kermit Co connecting to multiple internal systems. What if employees want to connect to customer-facing systems, such as JIRA? Remember that these users are not in the database that holds the customer data; their identities have to be federated from the internal LDAP to external ones.

We need to add internal identity server as a federated Identity provider to the external identity server. Here the internal IdP becomes a federated IdP just as Google or FaceBook. Thus, employees of Kermit can log into customer-facing systems with their Kermit login details.

Problem 6: partner access using OAuth

Consider a marketing analytics company that does lead generation for Kermit. Call it Matrix.

Matrix carries out a file-based batch process that essentially updates Kermit’s Salesforce. Right now, they create an Excel sheet and sends it to Kermit; someone on Kermit’s end runs a shell script that adds the data.

Kermit wants to automate this process by exposing these update functions as APIs. They create three APIs; addSQLead, getRawLeads and getUsers. These APIs require protection using standard protocols. OAuth is useful for this: Kermit uses WSO2 Gateway, provide OAuth tokens for Matrix and use these tokens to access the internal databases. WSO2 IS can serve as the provisioner of these OAuth tokens. This is yet another pattern.

Problem 7: Provisioning the newbies

Each time a new employee joins Kermit, the infrastructure team has to add them one by one to every system. While Single Sign-On works for authentication, applications often need user profiles created for authorization and work role management. The Kermit infra team wants to automate this provisioning process.

If we use LDAP syncing with LDAP rules, applications can essentially perform authorization against the LDAP. There can be one LDAP maintained by the infra team, and this LDAP can be synced to all applications. This gives the same effect as provisioning.

However, this really works only if the control domain is the same in all cases. For example, if the the infra team controls the LDAP and the applications, this sync method is viable. However, Salesforce user management is in the cloud, and the infra team has no control over that login system.

This is where provisioning comes in useful. Kermit can write a set of custom provisioning connectors that provision users to different applications with the appropriate roles. The Kermit infra team adds the user into the database, and depending on the roles, WSO2 Identity Server can provision users to the appropriate applications via APIs.

Problem 8: Setting up fine grained authorization

Kermit’s use case now extends: they have deployed multiple websites and apps for clients, but want centralized fine grained authorization policies to be applied; in addition, they need all internal applications to comply with a centralized policy registry.

In this case, WSO2 Identity Server can act as a policy administration point (PAP) where you define policies. It can also act as a policy information point(PIP) and a policy decision point (PDP)- the actual point which looks at a user and decides whether to grant access to this particular resource. The policy enforcement points are at the websites. These points can retrieve the outcome of the policy decision and apply accordingly.

Problem 9: Managing the approval process

Kermit Co wants the partner registration has to go through an approval process. WSO2 Identity Server provides workflows for this: if a distributor tries to register, IS generates a workflow that alerts a human, who can approve or disapprove of it; on approval, the relevant provisioning and authorization protocols can be triggered across the entire architecture.

Conclusion: Moving on with Kermit

While this is hardly an exhaustive list of use cases, they are nevertheless some of the most common problems faced by companies that are in the process of their digital transformation.

As you can see, WSO2 Identity Server covers a wide range of these problems, and can work just as well in both single-organization scenarios or groups of companies or departments with centralized infrastructure management.

With the rapid increase in adoption of cloud services, some of the use cases - such as provisioning and authentication to multiple systems - are becoming more and more pressing concerns that show a clearly visible cost in both time and effort.

In empowering infrastructure with WSO2 Identity Server, organizations can run faster, leaner operations and open up new business capabilities, such as close centralized technology management without undue delays - precisely the kind of advantage needed in today’s digital world.

For more information, and to test out Identity Server, check out the product page or contact us. We’d be happy to help.