Microservices Architecture(MSA) : Security, Authentication & Authorization

Problem : How to handle security with authentication & authorization in MSA?

MSA requires uniform security to ensure microservices can communicate and collaborate with-in and outside the system. Each microservice needs info about who triggered the call for system usage. Authentication & Authorization are two core components of the security apparatus both are independent of each other.

Authentication : Identity of the user

Authorization : Decision on user is allowed to access & execute actions

  • Individual microservices should not perform authentication(central server approach can be adopted)
  • Authorization enables the interplay between microservices hence it would require the user groups, roles etc to created & administered collectively
  • OAuth2 is a widely supported protocol( Google, Microsoft, Twitter, XING, Yahoo etc)

OAuth2 solves the authentication & authorization primarily for human users for enabling it for microservices based system would need additional steps like:

  • Microservice to microservice communication protected by SSL/TLS against wiretapping (by encription) – REST supports such protocols
  • Certificates can be used to authenticate clients(non-humans)
    • Certificate Authority (CA) creates certificates & can be leveraged to verify digital signatures (SSL & TLS support certificates)
  • API keys (similar to certificates, keys are shared with external clients to allow them access to the system) – OAuth2 supports this through Client Credential
  • Firewalls : Use for controlling the microservice to microservice communication, helps in intrusion scenarios to enforce restrictions
  • Intrusion detection mechanisms (part of the monitoring system setup)
  • Datensparsamkeit : Concept enforces the restriction on data collection fields (collect the data which is absolutely required rest all are not store in the system)
  • Hashicorp Vault : Tool
    • Secret password
    • API keys
    • Keys for encryptions or certificates
    • Integrates with Hardware Security Modules (HSM’s),SQL databases, AWS IAM, can generate keys for AWS cloud by itself

Additional security scenarios for consideration:

Each micoservice has to ensure the below things in its design & implementation:

  • Integrity : Data integrity is the responsibility of every microservice it can be achieved by signing the data
  • Confidentiality : Ensures data modifications are not denied (again by using the user keys)
  • Data Security :
    • No data loss
    • Backup & disaster recovery solutions
    • Highly available storage solutions
  • Availability : Resilience approach should address the failure scenarios to ensure high availability

Most of the times above scenarios are ignored or missed out while designing security approach for the systems.

Questions to probe further during design discussions:

  • Session management implementation
  • What is the microservices communication & service discovery model?
  • User experience can change or should remain same?
  • Are you breaking the monolith to SPA(Single Page Applications)?
  • Do you have mobile clients?
  • How is identity and permission info conveyed to a service?
  • How is info decoded and interpreted?
  • What data would be required to make access decisions(ACL’s, roles, user accounts etc)
  • How is data managed?
  • Who is responsible for storing and retrieving it?
  • How to verify the tampering case?
  • Who all will interact with the services?
    • Users, Devices, Services, Applications, External Services,

Approaches available:

Evaluate all the approaches to see the proper fitment, multiple factors are at play, traditionally authentication in monnolith(heavyweight architecture) world has been always sateful service but MSA is lightweight distributed architecture but works mostly on stateless services, below are the approaches to work with stateful microservices:

  • Old world options available are….
    • Basic HTTP authentication (has drawbacks )
      • $ curl “https: //$username:$password@host/resource
    • Certificate based security : Supported in Sprint Security (X.509) – (has drawbacks )
    • Network security – (has drawbacks )
    • Custom Authentication Token
  • In MSA’s mostly deal with stateless stuff, we need to focus on what is stateful and stateless & how do we achieve statelessness?
    • Authorization servers are often stateful (they store issued access token in db for future checks)
    • By issuing JWT tokens as access tokens will help us to get statelessness to the interactions
      • JSON (JWT) is a secure way to encapsulate arbitrary data that can be sent over unsecure URL’s
  • Leverage JWT (JSON Web Tokens)
    • URL-safe
    • Exchanged between two parties
    • Claims are encoded as JSON object which is digitally signed by using secret between two parties
  • Use some Redis/Memcached db for user sessions in all the frontend microservices(this will ensure user authenticated once will have continuity for the following sessions)
  • Tokens (Expiry & Non-Expiry) : For expiry always pair with refresh tokens
  • API firewalls/reverse proxies are used for token translations
  • OAuth 2.0 is an open source delegation protocol allow secure authorization in simple & standard from desktop, web, mobile applications
    • In MSA context:
      • Authentication can be a microservice itself
      • Authorization is a common functionality across MS’s
    • Implicit grant (Frontend application)
      • For web applications running on the browsers with AngularJS or mobile apps
      • Gets access tokens directly
      • Similar to code grant but client gets access token directly
    • Client credentials grant :
      • Service-to-Service
      • Application authenticates itself using clientid and client secret
    • Password credentials grant:
      • Client collects username & password to get an access token directly
      • Only viable for trusted clients
    • Authorization code grant:
      • Server based application
      • Redirect flow for web server apps( to authorization server for code)
  • Frontend applications
    • Use implicit grant
    • Use HTML 5 localstorage for access and refresh tokens

oauthfig1

Solution Frameworks:

  • Netflix Zuul
  • OAuth : It is not for authentication & authorization but for scalable delegation protocol where actors involved are (map the numbers beside approach to the figure shown above ):
    • Resource Owner(RO)
    • Authorization Server(AS) – (2) (5)
    • Resource Server(RS) – (4)
    • Client – (1)(3)(6)
    • Access tokens are JWT (JSON tokens help in achieving the statelessness)
      • By Value(Inside the network)
      • By Reference(Outside the network)
  • OpenID Connect
    • Resource Owner(RO)
    • Authoriztaion Server(AS) – (2)
    • Resource Server(RS) –  (5)
    • Client – (1)(3)
    • MyMail.com – (4)(6)
    • Sessions – (5)
  • JSON Web Tokens
  • Sprint Security REST plugin
    • Spring Security core support – has inbuilt support for Oauth2 standard  that can be extended or customized for our implementation needs
    • Login & Logout REST endpoints
    • Token validation filter
    • Memcahed token storage
    • Partial implicit grant support for 3rd party providers
    • Oauth 2 support
  • SAML assertions (similar features to OAuth2)
    • XML focused
    • Standard based like OAuth
    • Supported by Spring Security
    • Standardized request signing
    • Enterprise usage
    • Drawbacks
      • Cumbersome setup for servers & clients
      • Headers will have large amount of XML data
      • Complexity for developers
  • Datensparsamkeit : Approach
  • Hashicorp Vault : Tool

(Image Source : OAuth.net )

oauthfig2

Solution Design:

There is no one size fit all the solution for this scenario, we have to adjust our solution according to the context & need of technical setup on the ground

  • Core problems in MSA :
    • Identifying user
    • Creating sessions
  • Leave authentication to Oauth or OpenID server
  • Make all MS’s accept JWT’s (with translate using reverse proxy for by reference to by value translations)
  • Ensure that….
    • Everything is self-contained
    • Standards based
    • Non-reputable(don’t trust anything)
    • Scalable
  • JSON (JWT) can be used for…
    • Single Sign-On
    • Secure payload transportation (obscure url parameters or POST body elements)
  • JWT for achieving statelessness
    • Instead of storing access token in a stateful way, do it with JWT
    • On the client browser securely store the JWT-encoded access tokens ( this is helps us to achieve one of the basic rule of REST i.e. state transfer
    • JWT claims can be signed
    • JWT can leverage JWE (JSON Web Encryption)

 Summary:

Lightweight distributed architecture based services demand lightweight infrastructure, security is very important but should be unobtrusive, spring security makes it easier for the developers to understand the low level needs of security communication & implementation. Oauth 2.0 being a standard helps to have common streamlined approach to solution implementation.

  • Spring Security Oauth
  • Spring Security SAML Assertions
  • Sprint Session
  • Oauth2 seems to be evolving as the alternative it is
    • Extremely simple for client (lightweight)
    • Access token have information other than identity only
    • Resources are free to interpret token content
    • Standards based hence changes be decoupled for uniform implementation
    • Supports bearer tokens
      • Centralizes account mgmt. & permissions
    • Supports Authorization Server, Resource Server & Client Application
      • Examples
        • Facebook – Graph API
        • Google – Google API
        • Cloud Foundry – Cloud Controller

References:

Microservices Architecture : Integrations & Communications

Systems can’t be built in isolation, each part of the system needs to communicate with the components and also integrate with other parties to provide & seek the services. Microservices are no different they need to be integrated & have to communicate with other services & systems, this happens at various levels as shown below…let us explore each of these to understand the details of implementations & challenges, it is going to be long post as we need to see the various options available for the challenges to be addressed during integration scenarios. I would advice a cup of coffee won’t be a bad idea while reading  🙂

msafig3

User Interface (UI) Integration

  •  Each microservice can have its own UI
  • Single Page Applications(SPA)
  • Single HTML Page
  • JavaScript (udpates page dynamically)
  • Logic in JavaScript
  • Useful for complex interactions & offline ability requirement

Single Page Application(SPA) Technologies

  • AngularJS (Runs in browser, given by Google under MIT open source license)
    • Provides bi-direction UI data-binding which tracks changes at
      • View Level (Renders in browser)
      • Attribute Level (Code Level)
  • Ember.js (Similar to AngularJS with it s own module Ember data it provides MDA(Model Driven Approach)  for accessing REST resources. Also available under MIT open source license)
  • Ext JS provides MVC features & UI compose like Rich Client Applications. GPL license v3.0 ( Free for non-commercial implementation, for any commercial implementation license needs to be obtained from Sencha)

Microservices & SPA’s

  • SPA per Microservice
    • Each microservice can have its very own SPA which calls microservice via JSON/REST interfaces
      • Tight coupling of SPA’s is difficult
      • Switching between SPA’s needs browser app reload (not a recommended integration)
    • SPA’s should have uniform Authentication & Authorization to avoid the need for multiple logins , OAuth2 & Shared Signed Cookie can help solve these kind of problems

msafig4

Uniformity with Asset Server

  • Each SPA is assembled with its own UI
  • SPA’s of microservices can use the resources(JS,CSS etc) from asset server to enable uniform UI
  • Proxy Server helps in masking the security rules of different URL’s (helps in giving uniform experience)
  • Separation of assets will result in new problem of dependency(All the changes to the assets will require changes in microservices as well)
    • Risk to independent deployments
    • Scenario best avoided
    • Reduces dependencies in frontend

“Asset Sever is more a problem than a solution”

msafig5

JavaScript in SPA can access the data

  • From the same domain as the code originates(called as origin policy)
  • JavaScript can’t read data from multiple domains
  • All microservices are accessible to the outside under the same domain due to proxy(this is no limitation)
    • Policy has to be deactivated when UI of a microservice is supposed to access the data of different microservices
      • Solution 1: CORS (Cross Origin Resource Sharing) solves the origin policy problem
      • Solution 2: Have all SPA & REST services under one domain (here asset server is the best option to enable the solution)

Single SPA with multiple microservices

msafig6

Binding of UI would be required as the functionality of the pages might come from different microservices which are composed of the module(JavaScript, CSS) of specific microservice that has all the UI formation (assuming that implementation is AngularJS based)

  • AngularJS supports multiple modules for different SPA units/parts hence facilitating the each MS to have its own UI control module

Drawbacks:

  • Dependency across SPA & microservices for build & deployments( requires lot of coordination) – Better to avoid this setup
  • UI based coupling of microservices results in shared deployment artifact – Better to avoid this setup

“One advantage of this approach is SPA brings together UI from different microservices & shows to the users without any intervention “

HTML Applications

Each microservice has one or more web pages(HTML, JavaScript, CSS etc) generated on the server (difference from SPA is that only a new HTML web page is loaded not an application/module by the server)

ROCA (Resource Oriented Client Architecture)

msafig7

  • Handles JavaScript & dynamic elements in HTML UI
  • Alternative for SPA’s
  • JavaScript plays limited role of optimizing the usability of pages(facilitates & add effects to the web pages)
  • Core assumption application should be functional without JavaScript
  • ROCA reduces dependencies (core philosophy that web should work on HTML over HTTP)
  • In various microservices coupling can be enabled by links (natural integrations unlike SPA’s)

Routing based integration

  • From outside the mircoservices should appear like a single web application(with one URL)
  • Also enables the assets to be shared without violating same origin policy of various assets in the system

msafig8

Function of the router is to redirect the requests from external/internal parties to appropriate microservices

  • We can leverage Zuul for achieving this functionality, also reverse proxies can also help(like webservers nginx, apache httpd that direct request to other servers)
  • Request can be modified & URL’s are altered which is very easy in Zuul to extend & implement

NOTE: When the rules in router become complex it can kill the purpose of isolated deployment strategy hampering independent development & deployment.

JavaScript for HTML Layouts

  • AJAX can be leveraged to load the content of a link from another microservice(s)
  • Link based approach can be used
  • Facebook BigPipe :
    • Optimizes load time
    • Composes web pages from pagelets
    • JavaScript is used to replace elements of webpage(DIV elements etc)

Frontend Server based integration of Microservices

msafig9

  • Frontend Server assembles the HTML webpage from HTML code snippets generated by microservices
  • Assets like JavaScript, CSS etc can be stored in frontend server
  • Edge Side Integrations(ESI) concept helps by providing simple language to collate HTML from various sources
  • ESI cache holds static & dynamic content of a page (this mix of static & dynamic contents is key for assembling pages)
    • Proxies & cache (Varnish & Squid implement ESI)
  • Server Side Integrations (SSI) can be another alternative, but SSI doesn’t have cache support) and only available in webservers
  • Each microservice can deliver HTML snippets which can be integrated on the server
    • Apache httpd supports SSI’s with mod_include
    • Nginx supports SSI’s with ngx_http_ssi_module
  • Portlets can be used as an alternative solution for the content assembly ( JSR 168, 286) in this case but it is very complex and the portlets are implemented differently in various servers (For microservices this solution is best not to be considered) Also most of the portlet implementations restrict us to java technology only…

Integration Scenario with Mobile & Rich clients

Mobile & Rich client applications present a different challenge in the current context microservices integration as they have separate client side installer which is required to access the services whereas web implementation is more universal and generic with central management of the UI assembly with HTML snippets shared by microservices. Also the entire mappings can be controlled by single coordinated client & server deployment.

  • Mobile, Rich or desktop clients requires separate installation for the client (which is predominantly monolith in nature) which has to offer/manage the interfacing with microservices
  • These client requirements might drive/dictate changes in the microservices development & deployments hence it is advised to bring some modularity into the context
  • We can’t have multiple client app deployments for the feature changes in microservices as the users will have direct impact or overhead requiring updates on the devices (this isolation development approach is considered in SPA’s for client & server development but the same is not recommended)
  • Both client & microservices can’t be isolated coordination is required to rollout and address the channel based needs at optimum levels

Organization Scenario

  • Mobile client development teams are different from the microservices teams (adding the client specific developers in each microservice team is not a great approach)
  • Mobile platform team needs to interact with all the microservices implementation teams which requires lot of communication which is not recommended by microservices approach

msafig10

One probable solution can be microservices team develops the features for web and the same will be available to mobile app when it is released but the catch here is that each microservice needs to support different features for web & mobile (to avoid the scenario we can have similar features across channels but in the domain context it might not be the case as the requirements/usecases might vary)

 

 

How to leverage pinterest as a social commerce accelerator?

Pinterest is new site that gives registered customers (purely by invite, they are rapidly growing I am watching their strategy when they will make it open or continue it same wayJ) to create and customize pictorial boards. It is quick and easy way to share & use the existing content of your products. Allows you to categorize products and acts as bulletin board marketing tool for your products.

Pinterest

If you can visit and see there are already few million users having private & public boards. Pinterest is providing the retailers to share their products and engage customers on social platform.

Now let us talk some business J for ecommerce sites, What is in Pinterest for a online retailer?

how to leverage it, here are the few ways:

  • Create your own pinterest brand board : Helps you to share the product information with customers. It is catching up viral already on the fashion products. I would say a new way to promote your products J
  • Add “Pin It” button to Product Detail Pages of ecommerce sites: Enables the visiting customer to quickly share the product images with PDP links. With this sharing done by customer whenever someone else in pinterest community clicks on your product images they get redirected to your site pdp hence increase your traffic, promoting your products in turn can result in revenue growth.
  • Announce your pinterest to customers: Use social media options like twitter & facebook. Add “pinit” buttons to your promotional contents.
  • Organize contests, brand buzz events on pinterest : Allows you to engage customers to create a brand buzz online.

Pinterest is already creating waves in the online promotions of products, generating traffic via bulletin board marketing approach, very soon there will be lot ecommerce sites using this on their sites.

This is a new trend developing keep a watch on the best ways to cash it for our customers. Please post your experiences if any on the same lines.