Enterprise Security as Microservice – A Key Digital Transformation Step to Reuse the Security Investments
Shaji Nair
Enterprise Transformation leader with expert-level hands-on skills in Technology. Architecture, Cloud, ML, Gen-AI, and Architecture, Engineering Team Management. I specialize in banking, finance, and retail domains.
This article is intended to provide an architecture and design point of view on transforming your legacy enterprise security investment as Microservice and enable the security as service capability within your digital application landscape deployed to the next generation container farm using the commonly available open source technology frameworks and Microservice architecture guidelines.
This article is going to apply the following sequential story flow
1. Address the concerns and establish a case
2. Baseline the concept requirements
3. Ideate the concept using a solution approach
4. Close the talk with a final note
Security Concerns in the Microservice Based Digitally Transformed Application Landscape
Business has invested millions of dollar and thousands of hours of experienced manpower to establish the security as an enterprise asset. Enterprise security is one the mission-critical capability of the company in protecting the core business assets and the customer data.
As we move forward with the digital transformation of the enterprise applications, we wanted to make sure the security is a critical consideration to ensure the program success. Digitally transformed applications are stateless or even in server-less in nature. They are based on Microservice architecture principle and run in virtualized infrastructure containers. Microservice applications are micro in nature [single responsibility principle] of the exposed functionality. Microservices expose their functionality as stateless APIs, they build their computational context based on the consumer initiated API calls or the events consumed via their dump pipe interfaces.
Business processes orchestrated using Microservice architecture has to be executed in a stateless collaborative mode using the API collaborations approach – mean execute each step of the business process by invoking the APIs of the exposed Microservice functionality.
In order for the Microservice to trust and process the consumer request, it should have access to the consumer’s security identity as a portable container which can be received as part of the functional request and should be exchanged between the services during the stateless API collaboration.
Extending the enterprise security to the microservice farm in microservice form is an essential early step we have to consider for our digital transformation. So let us define some of the security transformation requirements to make it fit for the microservice based application landscape.
The Requirements In a Nutshell
In order for us to successfully extend the enterprise security capability to the microservice farm, we need to transform the enterprise security as a microservice enabled capability so that digital consumers and microservice based business process orchestration can access the security function as APIs. The transformed security service should provide the basic security functions such as authentication and authorization and the following extract capability to support the security considerations of the end-to-end business process flows in the digital context.
1. Support the integration with all the existing security store and protocols using a pluggable integration architecture. Reusing the existing enterprise security investment is a mission-critical success factor.
2. Support the integration with any new security store using a pluggable integration architecture. Extensibility is a good ROI
3. Support the integration with a security service data store to extend the authorization data specific to the microservice applications. This will help to customize the authorization data at the microservice level without bugging the legacy security stores.
4. Deliver the authenticated security context as a portable, encrypted, stateless entity, which can be received by the digital consumers as a security token and can be used by the digital consumers to invoke digitally exposed products and services.
5. Support the verification of the ported security context so that business Microservices can assert the verification of the portable security context they have received via the API invocation before executing the business functionality for the digital consumer and ensure the right authentication and authorization of the consumer to access business functionality and the associated data.
The Concept
Let us see whether we can put together the concept in a simple diagram and minimum flow.
The diagram above shows the conceptual transformation of the enterprise security as microservice and the integration of the same capability to enable the secured consumption of the digitally exposed products and services.
The sequential flow-1 demonstrates the execution of a digital consumer security context verification using supported authentication mechanism and creating a portable stateless, encrypted security context.
The sequential flow 2 demonstrates the consumption of digitally exposed business products and services by the authentication digital consumer. The second flow also demonstrates how the API based Microservice composition work together with the portable security context to execute the business processes associated with the digital products and services.
The Solution Realization
Let us try to put together the solution. In order for us to demonstrate the solution realization we are going to use some of the proven open source technology frameworks as explained below.
1. Establish the API gateway as a front-end firewall framework to protect the access to the business services.
2. Establish the gateway service using spring boot based gateway Microservice approach
3. Extend the gateway functionality to filter the security and business service invocations by the digital consumers using gateway and filter patterns.
4. Establish the security Microservice using the spring security framework.
5. Enable the security service to support the numerous security protocols such as SAML, LDAP, AUTH2 and KERBEROS to cover current and future security provider’s requirements
6. Use the JWT token framework to deliver the authenticated security context as a portable, encrypted entity
7. Enable the business service requirements using spring boot and .NET core frameworks and provide the flexibility of technology choices in Microservice based application transformation.
8. Externalize the configuration using a config service and implement the same using spring boot framework.
9. Extend the security context verification as a service to service collaboration functionality between the business services and the security service.
10. Deploy the whole solution to a DOCKER based container farm for the scalability and availability.
The diagram below provides the solution relation details using the above mentioned open source frameworks.
The solution flow is composed of the following details and notations
Solution ROI and TCO
Let us look into some of the ROI and TCO factors of this solution
- Reuse of the enterprise assets
- Low-cost implementation
- Scalable and extensible
Final Note
Digital transformation is not the PPT or youtube video talk. It is all about transforming the business for tomorrow’s digital channel and the competitive market. The only way to achieve digital transformation is by transforming your core business applications using next-generation technology capability so that your products and services can be enabled across all the digital channels throughout the worldwide market. You current security investment is the result of decades-old effort, extending the current security asset to the digital landscape is one of the core success factors of your digital transformation program. Today, open source technologies help us to achieve such mission-critical transformation steps without spending a lot of money. Be real and achieve the digital transformation using digital engineering projects based on the open architecture and next-generation technologies and stop talking the repeated fancy words.
Enterprise/Solution Architect: Integration, Governance, Digital Transformation, Services, Security
6 年It seems to me that there are no differences between proposed 'concept' for Microservices and the wellknown one used before inn the enterprise, The only difference is that now we use one network protocole and before we could use sever different ones. I cannot grasp these "new " requirements 1 - 5 which can be realised in a simple way - the existing security solutions exposed via APIs. If we still situate inside the enterprise boundaries, we might not needed to put Security into containers. Strange but real. I think that the major value of this article is in the technologies used for implementation of that routine concept. Well, it is a real value that can be enough to publish it.
Enterprise/Solution Architect: Integration, Governance, Digital Transformation, Services, Security
6 年I 've started reading the article and plan to post a few comments because this material is very important to be seen in the right light of orientation on service (as Security was and is). I cannot rid of a feeling, that the author treats Microservices as objects with no minimal understanding of the differences between remote objects and services. Let's start with "Digitally transformed applications are stateless or even in server-less in nature." First, stateless or server-less are about different things. Why digital applications should be stateless? Is it because a Microservice, to be scalable, should better be stateless? Well, but we talk about application that likely includes one or several orchestrates compositions and orchestration must be statefull to keep its current state over a failure. This is a fact proved million times since 2001 when stateless Web Services appeared. If a Microservice "even in server-less in nature", you do not know how it is realised on another server - stateless or statefull. "Microservice applications are micro in nature [single responsibility principle] of the exposed functionality" - very naive if not to say wrong. A Microservice is a handicapped Services or a a one that is not fully developed in the Service. This knowledge is outside technology and may be unknown to developers, but this does not change the reality (see OASIS SOA RAF specification for more information on Services) "Microservices expose their functionality as stateless APIs" - an illiterate statement: API as any interface cannot have its own state; the Service's or Micstoservice's body can be stateless or not. "... they build their computational context based on the consumer initiated API calls or the events consumed via their dump pipe interfaces" - this is one of the fundamental difference between a Microservice and real Service because real (standardised) computational context of the Service execution must depend on surrounding computational and business regulation environmnet AND, only then, on the consumer's session data. If a Microservice acts as an object, i.e. considers only context related to the consumer session, such Microservice risks to be incompliant or even illegal. A statement "Business processes orchestrated using Microservice architecture has to be executed in a stateless collaborative mode using the API collaborations approach" is simply a nonsense. Any business process is stateful by definition. The process logic can receive inputs from stateless providers (actually, for the process, it does not matter whether the providers are stateless or not) and utilise the current state of the process to make the decision which next step to perform. There are no exceptions (regardless used technology) from this definition. "In order for the Microservice to trust and process the consumer request, it should have access to the consumer’s security identity as a portable container " - this is a typical inside Enterprise line of thinking. This is how we worked with objects. If we say Microservice, we have to understand that it can be used across Enterprise boundaries,i.e. where it will not have "access to the consumer’s security identity as a portable container". If you are a developer of the Microservice, you have to assume that someone else might compose it in an application and can make it externalised, i.e. for external consumers. BTW, this is one of the trivial assumptions for real Services. The latter, in order to establish a trust between the service provider and consumer, OASIS standard requires setting a contract between them before initiating a communication. In this contract, the consumer researches the provider's offer and sets the way how they will verify identities of each other online.