The cloud has pushed identity to its breaking point. And after?

The hardest part of identity and access management (IAM) technology is making it work with a multi-vendor infrastructure and the growing number of applications that companies rely on to do business. This is primarily because the last mile integration of applications and identity systems has traditionally been hard-coded to allow the exchange of information about a user, their identity, roles and access permissions. .

In the early days of identity, organizations had to write custom code to integrate applications with identity systems. With the advent of software-as-a-service (SaaS) applications, this model was no longer viable because you do not control the SaaS application code.

Instead, identity providers started building and maintaining connectors to support different applications as needed. This model worked because the app vendors shared the connectors among all of their customers, who were happy to no longer have to write their own integration code.

This approach was initially scalable, as there were only a dozen commonly used SaaS applications. However, as these numbers grew, maintaining and testing the application connectors needed to make them work became problematic.

This didn’t bother customers, as the connectors were managed and provided by identity system vendors. But increasingly, these connectors couldn’t support apps that didn’t work with identity standards like SAML or OpenID Connect (OIDC).

Identity Orchestration Recipes

In the age of the cloud, connectors are reaching their breaking point. Just as they were created to solve an industry problem, a new model designed to solve the connector impasse has emerged called Identity Orchestration Recipes.

This scalable approach replaces connectors by eliminating the need for application connectors in the first place. It securely addresses “last mile” integration with a universal session that works with any application running anywhere, eliminating the need to rewrite applications.

Identity orchestration also allows customers to define use cases in terms of patterns and repeatable patterns called recipes, which shifts the focus of work from plumbing to innovation and allows companies to focus on higher-level concerns such as customer experience. This is possible because security is built into a plug-and-play integration model that does not require custom code.

Some example use cases include implementing personalized user journeys, modernizing applications, deploying passwordless authentication, supporting multiple identity providers (IDPs), and more. Each recipe can be applied to hundreds of applications.

Consider Lego building blocks. Anyone with a big enough box of Legos can build something amazing, provided they have the time and skill. For most people, however, it’s much easier to use the pre-made kit to make a Star Wars Millennium Falcon. You get what you want faster and easier if everything you need is there, and you can put it together with simple instructions.

Identity orchestration recipes work in much the same way and are focused on achieving a desired result.

Begin

Implementing orchestration recipes is as easy as browsing a “cookbook” of use case recipes and integrating your identity fabric using a plug-and-play setup . Here are some simple steps that will help you get started:

• Create an inventory of apps, users, and identity systems: What ingredients should you work with? Start with an inventory of your systems, then an inventory of your applications. Finally, take an inventory of your users: are you talking about customers, employees, partners, or all of the above?
• Connect the ingredients: Once you have defined the systems, applications, and user groups, the recipe boils down to how you connect or integrate these three circles of users, applications, and systems (identity providers, authentication and other tools).
• Implement the recipes: Like boiling an egg; it can be as simple or as complex as you want. Most recipes are implemented in hours or days instead of weeks or months.

Best Practices

Recipes don’t need to be convoluted; here are some best practices to keep in mind:

• Focus on the use cases you want to orchestrate: Think about your business use cases and write them down. A whiteboard or piece of paper will do. Do you want to modernize applications and identity? Do you need to deploy MFA without a password? Want to streamline user sign-up and login experiences?
• Define the user journey you want for each recipe: The quickest way to create a recipe is to ask, “Users are trying to access something. What do we want to happen?” You might notice that an orchestration flow starts to take shape.
• Remember that the recipe ingredients are interchangeable: Don’t dwell on how it will work with a particular ingredient (IDP, authentication, application, etc.). Recipes let you trade one technology for another; for example, if you need to replace an old SiteMinder system with Azure AD, simply replace the identity provider and the rest of the user flow will continue to work.
• Get Membership: Use the recipes and their results to gain buy-in from decision makers and business stakeholders by demonstrating the results they can expect. This saves time and money because it’s easier to post the recipe on a whiteboard than to create a software demo. It’s also very easy to create and demonstrate a quick proof of concept, then scale it to hundreds of applications once the business is onboarded.

Final Thoughts

Additionally, recipes can also be adapted to changing needs as the organization grows. If you have a specific access policy for your employees, you can apply the same recipe to all the applications they use without having to do it on a case-by-case basis. Apply the recipe to 700 applications, and voila; no need to make 700 connectors. Making changes is as easy as replacing bourbon with whiskey in an Old Fashioned cocktail.

Just as a Lego kit helps you achieve the desired result faster and more efficiently, identity orchestration recipes offer a holistic approach to solving the complex challenges of IAM use cases.