Zero Trust Framework- NEVER Trust, ALWAYS Verify

Current business needs and IT trends demands data to be accessible across boundaries. Data in silos has very little value and it is imperative for an enriched offering to continuously exchange data between varied applications, workloads, edge devices, data centers and other touchpoint. The core business data which in the past was secured within the security perimeter is now forced to be shared outside the entity to attain enhanced business value. There is an ongoing demand in moving data from Secured Castle to Cloud environment and to brace this change Enterprises must beef up their security controls.

Zero Trust Framework(ZTF) is a tangible security model which works based on NEVER Trust, ALWAYS Verify principle. By default this does not trust any user, device or workload irrespective of the location and is ideal for securing data shared across multiple streams.This model emphasises controls on the following focus areas that provides the necessary controls and isolation for data access.

• (Zero Trust) Network : The Network must be divided into Micro Segments and must be braced with multiple inspection points and junctions to block all the malicious and unauthorised access. This segmentation aids to isolate and contain the breach, if any within the segment.
• (Zero Trust) Workloads: Entire stack of workloads must be hardened and secured. Policies must be enforced on workloads for accessing data and any violation must be monitored and isolated in real time.
• (Zero Trust) Data: Data must be secured and policies must be defined in accordance with the value of the data accessed. Critical data should have extremely limited access and controls should be in place to detect and flag out abnormal data access
• (Zero Trust) People : Provide users with only minimal access and authentication must be stepped up using MFA
• (Zero Trust ) Devices :Every device in the network (mobile, laptop etc) must be uniquely identifiable and secured. Provision to be isolate compromised device must be set up.To minimise the network surface attack, the devices accessing the network should be monitored and access should be provided only after it is authorised
• Visibility and Analytics :All traffic must be logged, monitored and inspected in real time. Continuous Monitoring and Analysis of data access activity across the Network should be set up. Anomalies in data access pattern should be identified and isolated in real-time.
• Automation and Orchestration : Manual process is not effective in managing the scale of controls required for Zero Trust framework.This requires solid orchestration to handle the Policies enforcement, monitoring, remediation and threat detection. Automating these reduces the risk and provides agility that makes framework more manageable.

Adhering to this framework enables Enterprises to tighten the access control and establish processes to brace the shared data from being compromised. Enterprises can invest in security products that are Zero Trust compliant or can implement the additional checks in existing ecosystem to address all the focus areas of ZTF. Ensuring secure and legitimate sharing of data is very critical for any business and adhering to ZTF provides the necessary controls to achieve this.

API Design

 With API First approach gaining more traction it is very important to emphasise on good API Design. Designing a good API is more of art and iterative process.It is critical to put the Users first and spend a lot of time on refining the APIs.

A few years back APIs were considered to be just a software interface to connect disparate system to achieve a business capability. This was the bare minimum expectation but over the years this has increased to leaps and bound. 

Based on API 360 model, an API design should consider the following

• Usefulness - Does it address any relevant Business problem.
•  Engagement - Is the API easy to adopt and how good is the Developer Experience
•  Evolvability - Can it address the future requirement like support more users, different regions, etc
•  Security - Is it secure and manageable

The key considerations the designer has to keep in mind when designing an API are

• Who are the users of the APIs

Are the intended Clients internal or external to the organisation. Based on AWS API Mandate, an organisation should not build different set of APIs to cater for internal and external usage. Internal APIs should be build with the consideration that it should be able to support external traffic with few controls in place.

• What is the business problem the API is supposed to address

Identify the API type based on the capability it is expected to support

API types falls into 3 main categories

• System API -  API to support simple CRUD operation
• Process API - API to support interaction among different system, eg Generation of Consolidated Bank Statement
• Experience API - Typically custom made for external users

• Does the API handle any sensitive data

Proper encryption and encoding should be considered when handling sensitive data.

• Is it a global or region specific API

If the business process is region specific then building a single global API to handle all regions requirement could be an overkill and it is better to build region specific API and weave them together as Global API. For eg introduce an HTTP header to specify the market or region and the Global API would just do the routing to specific region.

A few best practices to consider when designing an API

1. Avoid jargons in API URL and field names
2. Use HTTP Methods and Resource to define the URL
3. API fields must be least restrictive
4. The API Response must reflect the resource mutations
5. Use Enums instead of Boolean
6. Timestamp field naming should  be <<verb>>ed_at format
7. Currency should be used to represent amount fields
8. Consistent way to search and list results
9. Use Nested Object instead of flat structure
10. Error Codes must be consistent across end point
11. Use consistent Authentication mechanism
12. Consider the throttling and rate limiting parameter
13. Leave place holders for Sunset headers
14. Strive to make any changes to API as backward compatible

Dockerizing Spring Boot App using Maven

This post details the steps required to dockerize an existing Spring Boot App

1. Create a Spring Boot App
2. Run  and verify the working of the App
3. Include the following  build plugin details  in  POM file to create the docker image

JSON API

JSON API is a specification that defines the standards for exposing and consuming API from Server and Client perspective.This brings in a common convention that provides a mutual understanding of interaction patterns between the client and server.JSON API formulates 3Rs - Resources,Relationship and Repository

There are a number of open source library available in different languages to support  JSON API . In Java, the following are a few

• katharsis
• crnk
• Elide

Adhering to JSON API increases the efficiency and performance of API consumption model by reducing the number of requests and amount of data transmitted .

JAXB UnmarshalException when converting Payload in Camel

Camel provides camel-jaxb jar  for converting XML to POJO data and vice versa using JAXB data format.

The samples provided in the documentation states that the contextPath should be set to the Java Package of the POJO class for the marshaling and unmarshaling purposes.

But when trying to set the contextPath to a required class package  it throws the exception “javax.xml.bind.UnmarshalException: unexpected element Expected elements are (none)”

This is raised because meta-data information is missing and the registryFormat element is not found in the context. This can be fixed by creating the Context with the Object Factory class and using this reference to unmarshal the data. 

JAXBContext jaxbContext = JAXBContext

                           .newInstance(new Class[] { com.test.ObjectFactory.class });

              DataFormat registryFormat = new JaxbDataFormat(jaxbContext);

              from("file:in?noop=true").convertBodyTo(org.w3c.dom.Document.class)

                           .unmarshal(registryFormat)

                           .log("The message after conversion" + "${body}");      

Unresolved constraint error when installing bundles in Fuse

When installing a bundle in Fuse, it quite common  to encounter the Unresolved constraint error: missing requirement: osgi.wiring.package error.

This error is thrown when the packages imported using Felix plugin are in conflict or if the dependent bundles are not installed. 

The article in this link provides a detailed explanation on the cause and fixes for this error 

But for those looking for quick fix ,the following steps would be handy.

• Use osgi:headers <> to list the manifest details of the bundle.
• In the manifest details,check for packages are marked in Red in Import-Package Listing. These are the  candidates which potentially cause this error.
• Verify if the bundle corresponding to the erroneous package is installed and started 

These  steps should help to resolve most of the unresolved constraint exception when installing a bundle.

IllegalArgumentException when invoking a webservice from a Camel Route

If a service exposes more than one operation then the operation name and namespace should be set in the header before invoking the call from the Route.

The IllegalArgumentException or BindingOperationInfo Exception is thrown when the framework is not able to find the matching operation to invoke.To fix this ,verify the operation name and namespace from the service class defined in the CXF EndPoint Bean.If the operation name or namespace is different,the binding would fail and IllegalArgumentException would be thrown.To fix this error,ensure that  the operation name and namespace match with the details given the SEI class.

  

<route>

     <from uri="timer:foo?period=5000" />

     <setHeader headerName="operationName">

            <constant>generateText</constant>

    </setHeader>

    <setHeader headerName="operationNamespace">

       <constant>http://com.test/generateservice</constant>

   </setHeader>             

  <to uri="cxf:bean:generateService" />

 <log message="The message contains ${body}" />

</route>