Content of Figures
Commissioned by Avatier
IAM (Identity and Access Management) in general and IGA (Identity Governance & Administration, integrated solutions for Identity Provisioning and Access Governance) in specific are cornerstones of today’s IT Infrastructures, well beyond serving security and regulatory compliance requirements. However, most IAM solutions as of today are still built in a very traditional style. They are rather complex, monolithic applications that aren’t easy to deploy. They run on premises and it is hard to impossible to shift them to an as-a-service model. Shifiting to containerized IAM can help in overcoming many of the challenges that traditional IAM infrastructures bear.
Over the past decade, we have observed massive changes in the way applications are developed and operated. Agile development, DevOps, microservices, containers, container orchestration and even Serverless Computing became popular, either extending what has been there (such as APIs) or replacing formerly prominent concepts such as virtualization. These provide massive benefits, such as support for flexible deployment models; increased elasticity, scalability, and availability; continuous innovation, development, and deployment; ubiquitous APIs for integration and customization; and simplified operations.
This results in many specific benefits for IAM and IDaaS deployments, such as greater security, reduced preacquisitions of technology such as middleware before deployment, lower cost of operations, faster time to value, agile IAM deployments, faster quick-wins, and continuous innovation.
Avatier, an US-based vendor of IAM solutions, has decided a while ago to consequently move to a containerized approach for IAM. Their IAM and IDaaS offering is now named Avatier Identity Anywhere, built in a microservice architecture, and delivered in Docker containers with Docker Swarm or Kubernetes for orchestration.
Based on that approach, the solution can run in the respective environments that support Docker containers, from running Docker Swarm or Kubernetes on premises for load balancing and continous deliverly to running the environment as a service. The solution supports preparation of shifting Avatier Identity Anywhere workloads to other environments such as AWS, Microsoft Azure, Google Cloud, even private clouds or country specific data centers. It includes an agent to connect back to the remaining business workloads that the IAM solution must manage on premises.
Consequently, the solution comes with a pay-per-use, subscription based pricing model for both hosted and non-hosted deployments. Even though Avatier prides itself on offering a low-code/no-code solution, another element that is essential to containerized IAM and to be found in the Avatier Identity Anywhere solution is a comprehensive set of REST APIs.
However, shifting to such an approach on-premise isn’t a no-brainer. The organization must be prepared for working with paradigms such as DevOps, continuous delivery, and agile development, and for an environment that is based on microservices, containers, and APIs. Your tools for managing, monitoring, and securing servers do not work on containers. But that also means most hackers tools won’t work on contianers eithers. That changes the way IAM is done, but it changes it positively. Anyway, before moving to a containerized IAM, ensure that your business is ready for dealing with these modern new technologies that are changing the role of IT forever. Avatier helps by providing a pre-configured solution on premises, that overcomes most of the challenges of managing this new type of IAM deployment, but also can run as a full IDaaS in a completely managed manner in the cloud.
- Challenges of deploying and securing today’s on premises IAM infrastructures – the common pitfalls and problems
- DevOps, microservices, and containers explained in a nutshell
- The benefits of using modern, containerized architectures and infrastructures and how they apply to IAM
- Considerations to take when shifting to such architectures
- The Avatier approach on containerized IAM
- Recommendations for your journey to containerized IAM
3 The Challenges of Deploying and Securing Today’s IAM
Managing today’s common, monolithic, on premises IAM infrastructures is challenging. Scalability, flexibility regarding customizations and integrations, or rolling out new releases can become challenging and cumbersome.
IAM (Identity and Access Management) in general and IGA (Identity Governance & Administration, integrated solutions for Identity Provisioning and Access Governance) in specific are cornerstones of today’s IT Infrastructures, well beyond serving security and regulatory compliance requirements. IAM helps businesses in connecting all variants of users to all the services, regardless where they are running – on premises as legacy application, cloud services, etc. It thus serves the Digital Transformation of businesss by enabling seamless yet secure access of users from everywhere and with every device to every service, whenever that access is required.
IAM serves the Digital Transformation of businesses by enabling seamless yet secure access of all users to all the applications and services these require.
However, most IAM solutions as of today are still built in a very traditional style. They are rather complex, monolithic applications that aren’t easy to deploy or upgrade. They run on premises and it is hard to impossible to shift them to an as-a-service model. They frequently require a lot of pre-acquisitions such as databases, operating environments, or setting up components for running them, such as Microsoft IIS or other web servers and middleware. Frequently, integration and customization are challenges as well.
To look at these challenges in some more detail:
- Zero Day attacks are on the rise and having an Identity Management system that cannot be upgraded rapidly is no longer a viable option.
- Infrastructure Requirements: Traditional IAM tools, while sometimes deployed as virtual appliance, frequently require having certain technology stacks in place ahead of deployment, which not only causes cost and efforts, but also requires the team having infrastructure and middleware skills. Factually, such requirements frequently become a limiting factor in the choice of IAM tools, because customers restrict themselves to either Windows or Linux environments due to their lack of ability of managing the other platform.
- Deployment Models: The deployment models are limited to on premises and, in some cases, to managed service operations where the entire stack is lifted to the data center of a MSP (Managed Service Provider). However, there are no real as-a-service models available. This might be acceptable due to the fact that many IAM implementations are anyway heavily customized, making them not perfectly suitable to a multi-tenant cloud model, but anyway this is a limitation.
- Integration: Integration of traditional IAM solutions is not always straightforward, due to a lack of well-defined, comprehensive, and modern (REST) APIs. However, IAM does not exist isolated, but must co-exist and integrate with SIEM (Security Information and Event Management), ITSM (IT Service Management), or PAM (Privileged Access Management).
- Customization: For many of the tools and due to their architecture and the inherent shortcomings of well-defined API layers, customization can become rather complex. For some, this factually happens at the level of the middleware, requiring strong programming skills and knowledge of the runtime environment.
- Scalability and Availability: Finally, the more monolithic a tool is, the harder it is to solve the challenges of scalability and availability.
There have been good reasons for architecting IAM solutions in the traditional on premises style. Factually, that architecture – three-tier applications built on a standard middleware – were state-of-the-art back when the journey started. Furthermore, running IAM on premises had its logic when the vast majority of critical workloads was running on premises. The latter is about to change and we are at the tipping point for workloads now, with an ever-increasing part of critical workloads running as a service, in the cloud. In a time where requirements are changing and the technical options are different, in the age of agile development, DevOps, containers and microservices, it is about time to rethink the way IAM is done.
IDaaS could be an alternative to containerized IAM – but don’t underestimate the challenges in connecting back to the on premises infrastructure and supporting the hybrid reality of businesses.
One could argue that there is a simple solution available, which is just going for a cloud-born IDaaS (Identity-as-a-Service), i.e. just running all the IAM workloads as a service. However, for most solutions, this comes – as of now – with some shortcomings in capabilities, and it will always carry the challenge of connecting back to the existing legacy parts of IT, i.e. in supporting the hybrid reality of businesses. Pure-play IDaaS can be a solution for certain scenarios, but it isn’t for all of them. Notably, this looks fairly different when a strong on premises IAM offering is able to be run in the cloud, based on modern architecture.
This shifts the focus to rearchitecting IAM and using the benefits that microservice architectures and container-based deployments offer for balancing the need for “better” IAM architectures with the hybrid reality of businesses, where all types of services must be well-managed by the IAM infrastructure.
4 The Potential of Microservices & Containerization
Microservice architectures, DevOps and agile development as new paradigms, and container-based deployments are changing the way IT is done. There are obvious benefits in moving to such architectures such as increased flexibility and lower cost of operations, but also increased security.
Over the past decade, we have observed massive changes in the way applications are developed and operated. Agile development, DevOps, microservices, containers, and even Serverless Computing became popular, either extending what has been there (such as APIs) or replacing formerly prominent concepts such as virtualization (while one might argue that containers are more an evolution than a replacement of virtualization). To start, it is essential gaining some baseline understanding of the terms and concepts:
- Agile Development: This is an approach for developing software in small chunks instead of large blocks. Commonly, there is not an exhaustive roadmap but a distinction between what should be done now, soon, and later. Only the short-term aspects are planned in detail and then implemented by small teams in what is called “sprints” – short cycles of some days or few weeks. It must not be underestimated that agile development only works within well-thought-out frameworks regarding organization, methodology, and the infrastructure and services (such as identity and security services) to code against.
- DevOps: Development and Operations in an integrated approach, where new components from development are deployed in a standard process (commonly referred to as CI/CD for Continuous Integration, Development, Deployment). This allows for continuous updates, which are common today for most cloud services.
- DevSecOps: This term gives security a more prominent role in DevOps and is about integrating security into DevOps, by e.g. providing an Identity API layer that is consistently used in such environments.
- Microservices: These are the granular services that deliver a specific capability. Ideally, each set of capabilities is a single service, which then allows for flexible packaging in containers and deployment.
- Containers: Containers are execution environment for one or more microservices. Microservices are packaged in containers, which share the underlying operating system and middleware. Thus, containers are significantly leaner than virtual machines.
- Serverless: This is a model where even more of the capabilities are delivered to execute the services, by factually removing most of the overhead of containers as well. The service provider takes most control, which can be considered an opportunity or challenge.
Some of that is not entirely new. The concept of (REST) APIs and microservices is a consequent extension of a journey that started latest with the introduction of SOA (Service Oriented Architectures) and CORBA (Common Object Requests Broker Architecture) back in the early 1990’s. However, adoption, applicability to a variety of use cases, and efficiency as well as the related deployment models and software development models have fundamentally changed over the past three decades. It is just logical to follow the modern concepts when developing software, resulting in significant benefits for the customers:
- Flexible Deployment Models: Containers can run everywhere. In the own data center, in a private cloud, in the public cloud. They even can be distributed across such environments. Moving to containers opens the door for a perfect support of hybrid deployment models and a smooth, gradual migration to the cloud.
- Elasticity, Scalability & Availability: Containers are scalable and available by design, resulting in a level of elasticity that is unbeaten by traditional approaches. It is super-simple to run multiple instances of containers and to restart them in milliseconds. Many challenges around availability and scalability factually just disappear, when doing the modern architectures right. There are certain things to consider, such as integrity of data, thus it is not just about shifting a traditional tools into containers, but about rearchitecting it.
- CI/CD: Continuous change and evolution is a cornerstone of the concept. Instead of lengthy update cycles that frequently are disruptive to operations and error-prone, individual microservices are regularly updated, adding new features.
- APIs everywhere: When relying on microservices, APIs come as an integral part, both internal and external ones. The internal ones only serve the solution and other microservices, the external ones are available for customization and integration. Which well-defined APIs being a must for such architectures, integration and customization are massively simplified.
- Simplified Operations: While the complexity of running a DevOps environment and container infrastructures must not be underestimated, the standardization towards containers simplifies the environments. Managing operating systems and middleware is a lesser challenge than in traditional environments. However, the number of tools and services in a modern environment can be considerable, as well as their change rate due to continuous innovation.
This brave, new world is no such thing as a free lunch unless provided as a turnkey offering. DevOps environments are complex and there is continuous innovation. Ensure that you have the skills in place for shifting to the new paradigms.
However, this brave new world does not come for free. DevOps environments are complex, and even if you just look at an application that is delivered in containers, you need the environment to run and manage these containers – and to secure APIs. However, you will need this anyway, and well-architected modern applications will behave as a “good citizen” in your DevOps environment, if the latter is set up well and includes the services such as API Management and Security.
5 Considerations & Benefits for Successfully Running a Containerized IAM
Many of the benefits of modern, containerized infrastructures are effective for IAM. However, there are other, derived benefits that help businesses in overcoming common challenges and pitfalls of IAM, such as shifting from a “big bang” approach for roll-out to a gradual deployment.
There is a reason why REST APIs (easy to use compared to SOAP or earlier concepts), DevOps, Containers, etc. are that successful these days. They have an ever-increasing relevance to all areas of IT, including IAM. However, when looking at using such approaches specifically for IAM, some aspects should be considered:
- Is the IAM solution really as modern as the vendor claims?
- Does it consist of well-packaged containers?
- Does it become clear which microservices are packaged into which containers and are these really microservices, encapsulating distinct capabilities?
- Can it be repackaged, e.g. for a perfect fit for hybrid deployment scenarios?
- Are there well-defined APIs (REST) available for utilizing these capabilities?
- Is the solution constructed for the DevOps/Container Runtime environment you are owning or intend to use in the cloud, e.g. Docker-based and ready-made for Docker Swarms and Kubernetes?
- What about the security, when having microservices in containers that communicate with each other and with the services you intend to integrate?
- Are you capable of running container-based workloads securely, even critical workloads such as IAM?
- Do you have the skills in your organization for that type of architecture? If not: Build them, you will need them anyway.
Specifically the first aspect is worth having a closer look at, given that many IAM vendors have started that journey, but many of them, are – at best – half-way through.
There are obvious benefits of running a containerized IAM, such as the ability to run it in a hybrid environment and gradually shift to the cloud.
On the other hand, there are obvious benefits of running a containerized IAM. Most of them align with the general benefits outlined in the previous chapter. Specifically to mention are
- Geater Security: Much of the security comes with containerization. Containers are rather immutable, having their own resources and communicating privately with other containers.
- Reduced Preacquisitions for Deployment: The need for setting up operating systems, middleware, databases, etc. just disappears – this is just part of the infrastructure that comes well-packaged in containers (if done right).
- Lower Cost of Operations:The cost of operating and maintaining the environment is lowered when running IAM in a standardized container infrastructure.
- Faster Time to Value: Deployment can be gradual, and cost can be lower, including the cost of the operating environment. Lower cost equals faster time to value.
- Availability & Scalability: Containerized IAM is highly available and scalable by design, because that is an essence of well-architected microservice architectures and containerized deployments.
- Flexible Deployment Models: The shift of IAM from on premises to the cloud, following the shift of business workloads, is simplified, including hybrid deployments where e.g. customer authentication runs in the cloud while employee-centric workloads remain on premises for now.
- Gradual Roll-Out: The “big bang” approach that is common to on premise, monolithic IAM is past when relying on containerized IAM. Feature sets can be rolled-out gradually, connectors can be set up step-by-step, etc. Only containerized IAM enables an agile deployment of IAM.
- Simplified Application Performance Management: Application Performance Management (APM) can be easily integrated with the container infrastructure, allowing for measuring certain KPIs (Key Performance Indicators) for IAM easily.
- Continuous Innovation: Integral to the concept is continuous innovation – it is not about rolling out a new release of IAM every couple of months, but continuously, in a well-managed approach, avoiding the pitfalls of IAM migrations that many customers have experienced in the past.
When looking at these benefits, it becomes obvious that containerized IAM helps addressing many of the challenges in deploying and operating IAM, including the challenge of demonstrating quick wins. To be honest, it can’t solve everything. Setting up IAM processes well, rolling out well-working entitlement management models beyond RBAC, and other conceptual aspects remain challenging – but many other challenges are solved or at least simplified.
6 The Avatier Approach on Containerized IAM
Avatier is an innovative leader in the IAM space and has decided early on moving towards containerized IAM. They thus today can deliver and support customers in their journey towards a modern IAM approach. This is a turnkey solution that can run in both on premises and cloud environments.
Avatier, an US-based vendor of IAM solutions, has decided a while ago to consequently move to a containerized approach for IAM. Their IAM offering is now named Avatier Identity Anywhere, built in a microservice architecture, and delivered in Docker containers. Avatier also calls this approach IDaaC, for Identity-as-a-Container. In contrast to many other offerings, Avatier delivers the same set of capabilities regardless of the deployment model. Thus, there is no loss in functionality when opting for a full IDaaS approach.
Based on that approach, the solution can run in the respective environments that support Docker containers, from running Docker Swarms on premises for increased elasticity without the need for hardware load balancers and other costly elements, to running the environment as a service. The solution supports preparation of shifting Avatier Identity Anywhere workloads to other environments such as AWS or Microsoft Azure, including an agent to connect back to the remaining business workloads that the IAM solution must manage on premises.
The entry requirements are rather low. It needs some few minified host OS for Docker that are well-secured. It requires some few worker nodes for Kubernete or Docker Swarms. It requires the management of secrets for that environment and security monitoring/scanning tools. All these are common standard requirements that are usually well-served in current environments, or well-supported by cloud providers. There are no infrastructure requirements that differ or go beyond what is common to the modern environments in which Digital Transformation happens today.
Consequently, the solution comes with a pay-per-use, subscription based pricing model for both hosted and non-hosted deployments. Avatier offers such hosting on standard cloud platforms, that are operated and managed by Avatier.
Another element that is essential to containerized IAM and to be found in the Avatier Identity Anywhere solution is a comprehensive set of APIs. These APIs allow for extending and managing the environment in a simple manner, building on the inherent benefits of such architectures.
The solution itself consists of a number of services, that are – from a licensing perspective – packaged into four sets of capabilities:
- Password Management: These capabilities are around self-service password management and resets, one of the essential capabilities of IAM. Doing that efficiently can save significantly in help desk costs, given that most IAM-related help desk calls are about password issues. Avatier supports a broad range of authenticators for resetting passwords and for continuous use beyond passwords.
- Single Sign-On: Avatier supports SSO (Single Sign-On) capabilities to both on premise solutions and SaaS services, also integrating a SaaS licensing management for cutting down SaaS licensed costs of unused accounts. SSO is another key capability from an end user perspective, simplifying access to applications.
- Lifecycle: This component bundles the Access Request Management and Identity Provisioning capabilities of Avatier. It also connects to HR systems and other sources of identity information, and comes with a simple shopping cart paradigm and a broad range of connectors to target systems.
- Access Governance: Finally, there is the Access Governance module, supporting regular reviews of entitlements and thus the common regulatory requirements in that area.
Avatier delivers a typical IGA solution – the area, in which deployment, customization, and maintenance are most challenging and the potential benefits of shifting IAM to a containerized IAM approach are biggest.
With Avatier Identity Anywhere, Avatier reinforces its position as one of the innovative leaders in the IAM market.
While Avatier is not unique as a vendor incorporating the new paradigms and moving towards a containerized IAM, they are further down that path than others. Avatier today provides a solution that delivers on the promises of containerized IAM. With that move, Avatier reinforces its position as one of the innovative leaders in the IAM market.
7 Action Plan for implementing Containerized IAM
While containerized IAM is a logical step, it requires the organizational readiness and skill sets for running containerized IAM. Thus, this step needs to be well-prepared and will be easier to make for organizations that already have experience in agile development, DevOps, and containerized IT infrastructures.
There are many good reasons for moving towards a containerized IAM. The benefits are obvious, and if a solution comes with a well-thought-out microservices architecture, well-defined APIs, and ready-to-use containers, there are strong advantages compared to traditional IAM and specifically heavy-weight, on premises IGA architectures. However, there remain some prerequisites that should be kept in mind:
- Ensure that the environment for running such infrastructures is in place or supported as a turnkey solution by the new IAM
- Create a new culture of digital transformation beyond Identity Management.
- Ensure that the skills for managing such environments are available – this is different than traditional IT.
- Have an established, mature, and well-thought-out DevOps approach in place, with the required constraints to really make it work.
- Prepare for an agile deployment of IAM, but in a well-defined framework, understanding how to do this and what to deliver in which order.
- Define the current and future deployment approaches and prepare for securely running distributed and hybrid deployments.
- Prepare for an agile approach on customization and integration and ensure that you have the skills in place.
- Execute your plans.
In sum, we strongly recommend evaluating containerized IAM for the next step in the IAM journey, given that these approaches balance the advantages of broad and deep capabilities plus hybrid support well with the advantages of as-a-service models, when it comes to operations and elasticity.
8 Related Research
Executive View: Avatier Identity Management Suite - 71510
Leadership Compass: Identity as a Service: Cloud-based Provisioning, Access Governance and Federation (IDaaS B2E) - 70319
Leadership Compass: CIAM Platforms - 70305
Leadership Compass: Access Governance & Intelligence - 71145
Leadership Compass: CIAM Platforms - 79059
Leadership Compass: Identity Provisioning - 71139
Leadership Compass: Identity Governance & Administration - 71135