Identity and access management has become a bit of a beast. It has gone from a system that was contained within an enterprise – usually directory driven, for very controlled purposes – to something that impinges upon almost every aspect of our daily lives.
This has been driven by a number of factors: cloud computing changing the way we access files and documents, BYOD and shadow computing, and even the increase in remote working, has had an impact on the development of what IAM needs to be. IAM is shifting its morphology, it may still be expressed ultimately as a platform, but it will be based on an API framework.
The new IAM needs to be fleet of foot and agile in deployment and scalability. The exploding market for microservices, expected to be worth $33 billion by 2023 according to analysts Market Research Future, is just in time for the new wave of IAM solutions. In parallel, will be supporting systems including containers for microservice deployment. But what are the implications of using microservices and containers for Customer IAM and the security of personal data?
Containing RESTful services in a service superstructure
Having a RESTful API framework gives you enormous flexibility in providing identity-based services. Identity isn’t just about ‘identity’ anymore. It’s about using identity data to transact with other online bodies. It’s about taking privilege and making it highly dynamic and flexible across myriad services while at the same time, linking that with external third party checks and measures. If you like it is a ‘super-service structure’.
Modern IAM systems have to work in a highly fluid manner. They verify information given is true using a multitude of call-outs, often to third-party services. These data are then used to perform other actions, sometimes within the organization, sometimes outside of it – with other types of third-party services. There is a lot of ‘toing and froing’ of communications across sometimes disparate protocols and applications. And, you have to make sure the information being shared is secure whilst also providing a beautiful, easy, sweet customer experience. The whole can be thought of like a biological system, individual cells communicating via stimuli such as light or pheromones.
IAM systems are moving rapidly towards a more RESTful API approach to managing the expectations of a modern identity framework and the super-service structure. In line with an API-based identity system, we need to also improve the underlying architectural needs of this fluid system that has to communicate within this superstructure. Enter stage left, in the nick of time, microservices.
What are microservices and where do they fit in the context of identity?
Microservices are an architectural method that is based on using distinct separate modules to run applications – the application being hived off into symbiotic services with a backbone of an API communicating between them. It can be thought of as a new, highly evolved version of the more traditional Service-Oriented Architecture (SOA) that used web-services as its core.
Microservices are based on the idea that each service is built and run around a single job – like a UI allowing for registration, or taking payments or sharing an identity document with a passport issuing service. Microservices, unlike Virtual Machines, do not need to run an embedded operating system, so they offer the flexibility different identity/data-based services need.
There have been some push backs in the use of microservices around areas like resource wastage, but containers have come to the rescue and when used to deploy microservices, offer a more optimized version of them.
What is really useful when using microservices in an identity context, is that you can break each down into component parts. IAM is more and more going towards a ‘pick and mix’ of services that need to be agile in their development, scalability, and easily updatable.
The benefits of using a microservice architecture for identity systems include:
- Removing the single point of failure for both downtime and security
- Flexibility of library split off – separate development teams can be used for DevOps agility
- Offers API economy and separate product deployment – allows for different offerings across different service needs
- They are stateless so information (PII) is not stored
- Flexibility around architecture and design ideal for deploying partial solutions as well as full platforms, e.g., you could offer an authentication service without a full identity platform
- Much more granularity of scaling – each service can be individually scaled
- Allows for fast seamless and independent updates
- Loosely coupled independent servicing /updating
- Internal communication traffic will be fast and even between external services the traffic should be fast
You won’t be able to use microservices for everything within a full identity system, for example, a helpdesk might need to be connected to the same database as the identity provisioning service, but using microservices and containers for identity-based services offers much more flexibility in configuration and deployment.
What about the security of microservices?
Because identity systems are based upon the transfer of often sensitive data, and so come under the watchful eyes of regulatory frameworks, security is a very important aspect of microservice configuration and deployment. Microservices are often deployed using a ‘container’ such as Docker. Containers like Docker can offer a more managed way to deploy microservices, and this is being evidenced by the uptake in containers in general.
In a 2017 report by analysts Forrester, they found that 31% of enterprises are now using containers. However, the report also points out that containers do need attention to security. Forrester and container security specialists Aqua agree on certain fundamental container security best practices.
Identity systems are the modern perimeter and we need to ensure that the personal data and PII upon which their operation depends is secure. Microservices, based on containers, offer the architecture needed for flexible IAM.
However, as always, with technology changes the security of the system must be an integral part of the design goal and using best practices to ensure this will create a powerful way to take IAM to the next level.