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

In the early days of identity, organizations were required to write bespoke code to integrate apps with identity systems. With the advent of software-as-a-service (SaaS) apps, this model was no longer viable because you don’t control the code of the SaaS application.

Instead, identity vendors began creating and maintaining connectors to support different apps as needed. This model worked because the app vendors shared the connectors across all their customers, who were happy they no longer had to write their own integration code.

This approach was scalable initially since there were only a dozen or so popularly used SaaS apps. However, as these numbers grew, maintaining and testing the app connectors needed to keep them working became problematic.

Customers didn’t mind because connectors were managed and delivered by identity systems providers. But increasingly, those connectors could not support apps that didn’t work with identity standards like SAML or OpenID Connect (OIDC).

Identity Orchestration Recipes

In the cloud era, connectors are reaching their breaking point. Just as they were created to address an industry pain point, a new model designed to solve the connector impasse has emerged called identity orchestration recipes.

This evolutionary approach replaces connectors by eliminating the need for app connectors in the first place. It securely addresses the ‘last-mile’ integration with a universal session that works with any app running anywhere, thereby eliminating the need to rewrite apps.

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

Some use case examples include implementing personalized user journeys, app modernization, deploying passwordless authentication, supporting multiple identity providers (IDP), and more. Each recipe can be applied to hundreds of apps.

Consider Lego building blocks. Someone with a big enough box of Legos can build something amazing — provided they have the time and the skills. For most people, though, it’s far easier to use the pre-designed kit for making a Star Wars Millennium Falcon. You get what you want faster and more easily if everything you need is right there, and you can assemble it following simple instructions.

Identity orchestration recipes function in much the same fashion and are focused on achieving a desired outcome.

Getting Started

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

• Create an inventory of apps, users, and identity systems: What ingredients do you have to work with? Start with an inventory of your systems, then an inventory of your applications. Lastly, make an inventory of your users: Are you talking about customers, employees, partners, or all of the above?
• Connect the ingredients: Once you’ve worked out the systems, applications, and user buckets, the recipe comes down to how you connect or integrate those three circles of users, apps, and systems (identity providers, authentication, and other tools).
• Implement recipes: Like boiling an egg; this can be as simple or as complex as you want it to be. 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 of your business use cases and write them down. A whiteboard or a sheet of paper will do. Do you want to modernize apps and identity? Do you need to roll out passwordless MFA? Do you want to streamline user sign-up and sign-on experiences?
• Define the user journey you want for each recipe: The fastest way to build a recipe is to ask: “Users are trying to get to something. What do we want to have happen?” You may notice a flow of orchestration begins to take shape.
• Remember that ingredients in the recipe are interchangeable: Don’t get hung up on how this will work with any particular ingredient (IDP, authentication, app, etc.). Recipes allow you to swap out one technology for another; for instance, if you need to change out a legacy SiteMinder system for Azure AD, then simply swap out the identity provider, and the rest of the user flow will continue to work.
• Get buy-in: Use the recipes and their outcomes to get buy-in from business decision-makers and stakeholders by demonstrating the results they can expect. This saves time and money because it’s easier to show the recipe on a whiteboard than to build a software demonstration. It’s also really easy to build and demo a quick proof of concept and then scale that out to hundreds of apps once the business is onboard.

Final Thoughts

In addition, 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 across all apps they use without having to do it on a piece-by-piece basis. Apply the recipe to 700 applications, and you’re done; no need to make 700 connectors. Making modifications is just as easy as replacing bourbon with whisky in an Old Fashioned cocktail.

Like a Lego kit allows you to arrive at your desired outcome faster and more efficiently, identity orchestration recipes provide a holistic approach to solving complex IAM use case challenges.