Security in Microservices

This tutorial is adapted from Web Age course Architecting Microservices with Kubernetes, Docker, and Continuous Integration Training.

1.1 Why Microservice Security?

Security is important in all systems and more complicated in a distributed system. We can no longer put our application behind a firewall and assume that nothing will breakthrough. Testing the security of microservice is required and may vary slightly depending on how you implement security. Individual services may just be doing token validation, which means we have to test at the individual service level. Using another service or a library to validate tokens, requires our services to be tested in isolation with those interactions being tested and validated in a production-like environment.

1.2 Security Testing in Microservices

Testing the security of microservice is required and may vary slightly depending on how you implement security. Individual services may just be doing token validation, which means we have to test at the individual service level. Using another service or a library to validate tokens, requires our services to be tested in isolation with those interactions being tested and validated in a production-like environment.

1.3 Security Topology


Collections of microservices are grouped as applications, and surface external APIs as endpoints through a gateway. One obvious difference above, from monolithic to microservice, is the number of moving parts. The other is how many more requests there are. In microservice enterprise architecture, you need to be aware of the possibility that the applications will make or respond to many millions of requests and responses.

1.4 Authorization and Authentication


  • Establishing the user’s identity is performed by a dedicated, centralized service or an API gateway.
  • Central service could then further delegate user authentication to a third party.


  • When establishing a user’s authority or permission to access a secured resource in a microservices environment keep group or role definitions coarse-grained in common, cross-cutting services.
  • Allow individual services to maintain their own fine-grained controls.
  • This is different than typical monolithic applications where fine-grained roles are stored in the application database or some centralized mechanism. For microservices, this could be an antipattern due to the need to modify that central resource when deploying or modifying the services.

1.5 J2EE Security Refresh

Each Java EE server service must be trusted by all of the other services. Users receive security tokens after authentication (in WebSphere Application Server, this is an LTPA Token). User tokens must be valid on all servers. Trust stores are defined so that every server has the certificates of every other server. All services must use the same finite set of key(s). All J2EE servers for the same application(s) must be in the same security realm

1.6 Role-based Access Control in a Nutshell

Implementation of Role-based authentication in code, has our system with an action for creating and updating customers, that we want the ‘Sales’ role to have access to, and so we write code like this:

[Authorize(Roles="Sales")] public ActionResult CreateUpdateCustomer() {     return View(); }

Later, we realized that, sometimes, people from the ‘Operations’ role should be able to create and update Customers. Now we update the Action method as:

[Authorize(Roles = "Sales", "Operations")] public ActionResult CreateUpdateCustomer() {     return View(); }

Later again, we realize that some of the operations people should not be able to do this action, but it is not possible to assign a different role for those people who are in Operations. So, we are forced to allow all operations people to create and update Customers.

 Anytime we change the roles, people are assigned, that should be allowed to create and update customers, we have to update all of our MVC Action methods Authorize attributes, build & deploy, test, and release our application.

Finally, we realize that ‘Operations’ is the wrong additional group for this role and we needed ‘Marketing’, now we’re updating code again across a bunch of services, and re-releasing.

1.7 Claim-based Access Control in a Nutshell

We define some set of claims like this :

“AllowCreateCustomer”, “AllowUpdateCustomer”, “AllowEditCustomer”

Now, we can decorate our Action Method like this:

        [ClaimAuthorize(Permission="CanCreateCustomer")]         public ActionResult CreateCustomer()         {             return View();         }

We can see that, CreateCustomer action method will always need permission ‘CanCreateCustomer’ and it will very likely never change. In our data store, we create a set of permissions (claims). In our data store, we create the user related to the permissions. From our administration interface, we can set permission (claim) for each user who can do an action or operation. We can assign ‘CanCreateCustomer’ permission (claim) to anyone who should be permitted. Users will only be able to do only what has been assigned from a permissions perspective. Claim information is usually passed between requests as a cookie to avoid database access, but again with a view to security and performance

1.8 Sharing Sessions

When we split authentication off from a “monolith” application, we have two challenges to contend with:

  • Sharing cookies between the auth server(s) and application server(s) On one server on one domain, this was not an issue. With multiple servers on multiple domains, it is. We’ll address this challenge by running all servers under one domain and proxying to the various servers.
  • Sharing a session store across server(s) With a single monolith, we can write sessions to disk, store them in memory, or write them to a database running on the same container. This won’t work if we want to be able to scale our application server to many instances as they will not share a memory or a local filesystem. We address this challenge by externalizing our session store and sharing it across instances.

1.9 Session Cookie


JSON Web Tokens need to be transient. Creating long-lived JWTs isn’t practical, as they’re self-contained and there’s no way to revoke them.

Upon successful authentication a PersistentJwtTokenBasedRememberMeServices

  • creates a persistent Session object
  • saves it to the database
  • converts the Session into a JWT token
  • persist Session to a cookie on the client’s side (Set-Cookie)
  • create transient JWT

JWT is meant to be used through the lifetime of the single page front-end and passed in the HTTP header (X-Set-Authorization-Bearer).

1.10 JSON Web Token (JWT)


JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWT contains the header and the payload. The first part is the token’s header which identifies the token’s type and the algorithm used to sign the token. The second part is the JWT token’s payload or its claims. There’s a distinction between these two. A payload can be an arbitrary set of data, it can be even plain text or another (nested JWT). Claims on the other hand are a standard set of fields.


1.11 Spring Security

Spring Security is a powerful and highly customizable authentication and access-control framework. It is the de-facto standard for securing Spring-based applications.

  • Spring Security features

  • Comprehensive and extensible support for both Authentication and Authorization
  • Protection against attacks like session fixation, clickjacking, cross-site request forgery
  • Servlet API integration
  • Integration with Spring Web MVC

1.12 Summary

  • Microservice security requires new techniques from monolithic applications
  • JSON Web Tokens can be created and manipulated by multiple frameworks
  • Role-based and claim-based security allows teams to secure applications

What is BIZBOK?

This tutorial is adapted from Web Age course Business Architecture Foundation Workshop

1. 1 What are BIZBOK and BIZBOK Guide?

 BIZBOK™ stands for the Business Architecture Body of Knowledge™. BIZBOK comprises the core set of Business Architecture concepts and artifacts that enable every organization to create, communicate and manage their respective Business Architecture. The BIZBOK™ Guide is a handbook that provides business architecture practitioners and other individuals interested in this discipline with comprehensive coverage of BIZBOK. The Guide comprises a growing collection of concepts, disciplines, and emerging best practices used by many business architecture practitioners in various industries. The Business Architecture Guild, the sponsor of the BIZBOK Guide, promotes the Guide as the emerging standard for building, deploying, and leveraging business architecture within an organization.

1.2 The Business Architecture Guild

The Business Architecture Guild is a not-for-profit organization of business architecture practitioners dedicated to advancing the discipline of business architecture.  Best practices emerging in the field of the business architecture discipline are contributed through membership participation. The Guild sponsors the BIZBOK™ Guide which represents the consensus, formalization, and documentation of best practices and knowledge from active members of the Guild.

1.3 The BIZBOK Guide Make Up

 The BIZBOK™ Guide is organized into the following major parts:
◊ Business Architecture Blueprints (Views of the Business )
◊ Business Architecture Practice
◊ Business Architecture Scenarios
◊ The Business Architecture Knowledge base
◊ Business Architecture and IT Architecture Alignment
◊ Industry Reference Models

1.4 BIZBOK’s Definition of Business Architecture

 BIZBOK defines business architecture as  “A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.”  According to BIZBOK Guide, a business architecture is not confined by the Enterprise boundaries and must also provide for the interests of the external stakeholders (partners, clients, etc.)

1.5 Business Architecture Characteristics

Business Architecture blueprints use a common vocabulary, standardized framework, and shared business knowledge base of business artifacts and elements. The common vocabulary includes such terms as capabilities, value streams, information views, etc. which helps eliminate much of the confusion often found across business units. The above arrangements form the following characteristics of a Business Architecture:
◊ It is about the business
◊ It’s scope is the scope of the business
◊ It is not prescriptive
◊ It is iterative
◊ It is reusable

1.6 Who, What, Where, When, Why, and How

Business Architecture helps executives answer commonly asked questions: who, what, where, when, why, and how

Fig 1. Aspects of the Business Represented by a Business Architecture
Source: BIZBOK Guide, v 3.5, 2014, p. 2

1.7 What are a Capability and Value Stream?

These are core BIZBOK Guide’s business architecture concepts and blueprints.  Capabilities are what a business does; it is an ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome. For example, an insurance company will have such capabilities as Claims Management and Policy Management. A value stream defines the major stages involved in delivering value to the internal and external stakeholders. In an insurance business, the Process Claim business process represents a value stream. Capabilities enable each stage of the value stream. The BIZBOK™ Guide assists practitioners with the creation and use of these business blueprints.

1.8 BIZBOK Common Blueprints

Adapted from: BIZBOK Guide, v 3.5, 2014, p. 4

1.9 The BIZBOK Business Architecture Framework

There are three important components within the Business Architecture framework:
◊ Business blueprints
◊ Business Architecture scenarios
◊ Business Architecture knowledge base

1.10 The BIZBOK Business Architecture Framework Diagram

Source: BIZBOK Guide, v 3.5, 2014, p. 5

1.11 Business Architecture Scenario Topics

The BIZBOK Guide covers the following business architecture scenario topics which include initiatives, programs, and projects:
◊ Investment Analysis
◊ Shift to Customer Centric Business Model
◊ Merger & Acquisition Analysis
◊ New Product/Service Rollout
◊ Globalization
◊ Business Capability Outsourcing
◊ Supply Chain Streamlining
◊ Divestiture
◊ Regulatory Compliance
◊ Change Management
◊ Operational Cost Reduction
◊ Joint Venture Deployment

1.12 Summary

In this tutorial, we reviewed the organization of the BIZBOK Guide sponsored by the Business Architecture Guild
 We reviewed the definition of the Business Architecture
 We defined the Capability and Value Stream blueprints
 The BIZBOK Business Architecture framework was introduced

What is Business Architecture?

This tutorial is adapted from Web Age course Business Architecture Foundation Workshop

1.1 Defining Business Architecture

 A Business Architecture is an essential function of the Business that describes what it does and how it does it to support organizational goals and objectives. Business Architecture is a composite of business capabilities and business processes expressed in the form of formalized artifacts. It is a part of the Enterprise Architecture.
While Business Architecture is a relatively new discipline it has been recognized by industry standards bodies such as the Open Group and OMG. In practice, there is no general consensus as to what Business Architecture exactly is. Even to the extent that mature architecture frameworks such as TOGAF or FEAF agree (and they largely do), there is still a gap in the perception of many business and IT professionals regarding the scope and content of the Business Architecture discipline.
IBM Global Business Services promote their own understanding of what a Business Architecture may be, which they call the Actionable Business Architecture ( According to IBM GBS, an Actionable Business Architecture is the product of “the confluence of three often disparate models in strategy, operations and IT” which accelerates time-to-value in business / IT projects. IBM GBS define models as “reusable assets, industry leading practices and industry standards or guidelines that capture knowledge about the industry and the enterprise.”

1.2 Layers of the Enterprise Architecture

 Enterprise Architecture regards the Organization as a large and complex system of interconnected sub-systems. One way of reducing system complexities is to separate them into layers with their own problem (architecture) domains.


1.3 The Business Architecture Domain

Within the Business Architecture Domain fall the following core components and activities which reflect and help with the realization of the Organization’s strategy and vision:
◊ Business Process design and modeling
◊ Business Requirements
◊ Business Rules
◊ Critical success factors
◊ Organization structure

1.4 The Values of Business Architecture

The Value of Insight
◊ If you found 10% more funds to invest, where would be the optimum place to invest?
◊ If you needed to trim 5% from your operating costs, where would you look first?
◊ Without a model for how business gets done and an understanding of how your business is structured (which are all artifacts of Business Architecture), these types of decisions are very challenging

 The Value of Managed Change

 Process changes, organization changes, requirements changes, and comprehensive strategy changes are a fact of business. Business Architecture provides a baseline model to support and enable enterprise changes without the usual chaos and confusion that is typically associated with significant change.

1.5 Relationship with Other Types of Architecture

There are four domains of architecture recognized by most prominent architecture frameworks. Business Architecture is positioned at the top of the enterprise architecture stack driving project activities downstream in support of the strategic and
tactical business decision. 

Business Architecture project activities must occur early in the life cycle of enterprise projects in other architecture domains.  Other types of architecture must align with the Business Architecture. Underlying Architectures provide upstream feedback helping fine-tuning standards, business models and requirements.
TOGAF and FEAF both recognize these 4 domains of architecture. 
NIH (National Institutes of Health) condenses their framework down into three domains:
• Business Architecture
• Information Architecture (including Data, Integration, and Application)
• Technology Architecture

1.6 Other Pillars of Business Architecture

In addition to the Technology supporting pillar, Business Architecture also depends on the Human Resources and Business Processes of the Organization. Company’s Human Capital and Business Processes are accounted for in Business Architecture and must be coherently aligned for realizing Enterprise Strategy and Vision.

1.7 Formal Business Architecture

Characteristics of ineffective Business Architectures

Difficult to interpret artifacts – Explanatory information is often incomplete. Also, artifacts representing similar or even the same parts may use different characteristics or visual notations, further confusing readers.

Difficult to retrieve related artifacts – Stored in multiple repositories, individual machines or buried in documents.

Difficult to maintain artifact consistency – If something about a part changes, a name for example, and the part is depicted in multiple artifacts, than all artifacts need to be updated.

Part relationships not maintained –The fabric of your business is encompassed by the relationships among it’s parts: To be of value, your business architecture needs to precisely express these relationships.

Characteristics of Formal Business Architectures
No ambiguity – Each unique part in the model has a single precise representation (formal grammars) and is maintained only once in the database.

Formal relationships – Relationships between parts are themselves parts, and as such have formal grammars and are maintained only once.

Easy to make changes – Parts and relationship representations are used by all model artifacts. Thus, when the model representation changes, all the artifacts using that part are updated automatically.

Easy to find – Model parts, relationships and all artifacts are stored in a single computer database.

1.8 Ownership vs Stewardship

Business Architecture (BA) should be OWNED by the Business, even if it is actively managed, or STEWARDED, by the technology team. IT often serve as stewards (executors, servers) of business rules engines, process modeling tools, databases, etc. which gives the illusion of ownership, while, ultimately, those are paid for, created in support of and owned by the Business. ◊ It may help to view BA as a joint effort between Business (owners) and IT (stewards).

1.9 Business Architecture Frameworks

 Business Architecture must be documented in and realized through some sort of an Enterprise Framework which must:
◊ Capture the “essence” of the Business
◊ Be suitable for identifying technology needs
◊ Establish consistent vocabulary and notation
◊ Be product and technology agnostic
◊ Reflect multiple views of the enterprise
◊ Be comprehensive
◊ Provide for agile and cost-effective change

1.10 Enterprise Architecture Frameworks

 Enterprise Architecture (EA) Frameworks help deal with complexity and change.  We will review two popular EA frameworks as they apply to Business Architecture:
◊ Zachman
◊ The Open Group Architecture Framework (TOGAF)

1.11 Business Architect vs Business Analyst – 1/3

To help further define Business Architecture, it may be useful to review the differences in roles of a Business Architect and Business Analyst
 Noted Enterprise Architect Nick Malik (Enterprise Architect with Microsoft), provides the following comparison between Business Architects and Business Analysts

  Business Architect Business Analyst
Why To uncover the gaps between strategic needs of a business unit, and their abilities to meet those needs, and to charter initiatives to fill those gaps. To develop and document the detailed knowledge of a business problem that an initiative has been chartered to address.
How Analysis of future-looking strategies, capturing of capabilities, and modeling of inter- and intra- business relationships needed to discover the key capability gaps that a business must be prepared
to face, along with the development of cross-functional roadmaps to address them. System requirements are NOT captured.
Interviews with existing business stakeholders and SMEs to elicit business rules, understand processes, information, and systems in use, and
detailing the consequences (intentional or not) of making a business change to address a specific issue. The primary result of this activity is the document of System Requirements.
When On-going process that is triggered by periodic strategy cycles within a business. As-needed activity that is triggered .AFTER a problem has been identified and requirements for a solution are needed.
Who Business or IT Generalists with a  strong understanding of business functional
issues, interdependencies, and business structural concerns. Must be excellent at capability analysis. Must leverage modeling and rigorous analysis skills.
Business or IT Generalists with a strong understanding of information and application interdependencies, requirements analysis, and system development methodologies. Must be excellent at IT requirements elicitation.
Must leverage modeling and rigorous analysis skills.
What Business motivational models, Value Streams, Scenarios, Capability models, Heat Maps, Funding Maps, Risk maps Business Requirements, Business Rules, Use Cases, and Detailed Business Process descriptions
Scope Enterprise continuum / cross-domain Project / process
Focus Strategy / tactical / solution-neutral / holistic Solution and/or operation specific
Skills /
Architecture methodologies / human relation Applied process engineering / task-oriented

Nick Malik’s blog entry: business-architect-and-business-analyst.aspx 

1.12 Going Beyond the Process

It is quite common to confuse Business Architecture with Business Process Modeling (BPM) or business process management. The important thing to realize is that Business Architecture will typically INCLUDE and even direct process improvement activities and high-level end-to-end business process modeling, but will typically refrain from detailed process modeling and management activities . For many organizations, BPM is considered a subset of Business Architecture.  No formally recognized architecture framework or architecture discipline treats Business Architecture and BPM as being synonymous .

Key Elements of Business Architecture (beyond process)
• Model-driven
• Integrated artifacts
• Formal semantics and grammar
• Consistent and unambiguous descriptions of capability
• Business / IT alignment

1.13 Summary

 There is a lot of confusion surrounding the role of Business Architecture.
 A few universal aspects are broadly agreed upon with respect to business architecture:
◊ It is essential
◊ It is a joint effort between Business and IT
◊ It occurs early in the architecture life cycle and drives and informs other downstream architecture activities
◊ Business Architecture is not the same as Business Analysis