Zero Trust API Security Architect

The cybersecurity threat landscape has changed dramatically in the last couple of years. Every day new kinds of threats are coming and impacting the organization’s business. Infosec/Security teams have always had challenges with this new threat to find the root cause and mitigate these risks.

To mitigate and overcome these constant/real-time threats and risks, the security fraternity introduces Zero Trust Architecture (ZTA) Or Zero Trust Strategy (ZTS).  ZTA is not a product or application, but it is a concept and practice to mitigate any risk for your organization.

What is ZTA/ZTS?

Zero Trust is an information security model that denies access to applications and data by default. Threat prevention is achieved by continuously validating for security configuration and posture before being granted or keeping access to applications and data across users and their associated devices. All entities are untrusted by default; least privilege access is enforced; and comprehensive security monitoring is implemented.

Here are the basic properties for ZTA/ZTS

  • Default deny
  • Access by policy only
  • For data, workloads, users, devices
  • Least privilege access
  • Security monitoring
  • Risk-based verification

How API implement ZTA/ZTS?

API Security focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of Application Programming Interfaces (APIs). In API security we establish certain rules and processes to mitigate security risks.  These rules and processes are around Zero trust architecture or strategy. Here are a few basic strategies in API security to implement ZTA.

  1. All API communications are secured regardless of network location – This risk can be mitigated by ensuring all communication happens over an encrypted communication channel (TLS) and implementing a proper Cross-Origin Resource Sharing (CORS) policy. The endpoint for API needs to be exposed through the HTTPS protocol.
  2. All API endpoints are authenticated regardless of their environments (Prod, QA, Dev) — By default, all APIs need to be authenticated and authorized using username/password, JSON Web Token (JWT), OAuth, OpenID Connect, or third-party services.
  3. All API resources are protected and restricted to all users by default — Running multiple versions of an API requires additional management resources from the API provider and expands the attack surface. As per ZTA, make sure all API versions and their resources are restricted if it is not used by the user. Always validate and properly sanitize data received from integrated APIs before using it.
  4. Access to API resources is determined by dynamic policy including the client identity, application/service, and the requesting asset – Any API requires resources such as network bandwidth, CPU, memory, and storage. It is easy to exploit these resources by simple API calls or multiple concurrent requests. According to Zero Trust Architect, all APIs must implement API policies like:
    • Client identity (ClientID/Client-Secret)
    • Execution timeouts (Rate limiting)
    • Maximum allowable memory
    • Maximum number of file descriptors
    • Maximum number of processes
    • Maximum upload file size
  5. Implement or configure API monitoring posture and API Alert system — API monitoring helps identify and resolve performance issues as well as security vulnerability issues before they negatively impact users, which can impact user experience. The alert system notifies the operation team to mitigate risk quickly.
  6. Continuous API security risk assessments – Continuous risk assessments help the Infosec/Security team identify any security risk gap. By conducting the security risk assessments, organizations establish a baseline of cybersecurity measurements, and such baselines could be referenced to or compared against future results to improve overall cyber posture and resiliency further and demonstrate progress. A Free Security assessments tool VAT is available to mitigate any security risk for your organization.

https://www.vanrish.com/secassessment/

Organizations that have adopted the Zero Trust API model, see trust as fundamental to creating a positive, low-friction work culture for their clients and empowering the organization at all levels. Many of our Vanrish Technology clients, we worked with have many of the technologies in place that can be leveraged toward full Zero Trust architect model adoption.

API Security

Modern-day APIs are the building block for integration and application for any organization. Every day organizations are using APIs to unlock new features and enable innovation. From banks, retail, and transportation to IoT, autonomous vehicles, and smart cities, APIs are a critical part of modern mobile, SaaS, and web applications and can be found in customer-facing, partner-facing, and internal applications.

Organizations are exposing sensitive data, such as Personally Identifiable Information (PII) through APIs, and because of this have increasingly become a target for attackers. Due to this organizations are concerned about their API security & compliance. API Security focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of Application Programming Interfaces (APIs). According to the Open Web Application Security Project (OWASP) 2023, these API threats are categorized into 10 different categories

  1. Broken Object Level Authorization (BOLA) – Object-level authorization is an access control mechanism that is usually implemented at the code level to validate that a user can only access the objects that they should have permission to access.
    Comparing the user ID of the current session (e.g. by extracting it from the JWT token) with the vulnerable ID parameter isn’t a sufficient solution to solve Broken Object Level Authorization (BOLA).

    For example, any API providing a listing of all school revenue based on the school’s name of any county could be a security threat like this API endpoint: /county/{schoolName}/revenues.
    Hacker simply manipulates {schoolName} in the above endpoint’s school name to get all revenue details for all schools.

    To mitigate this risk Use the authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses an input from the client to access a record in the database.
  2. Broken Authentication – API authentication is very vulnerable and an easy target for attackers. Attackers can gain complete control of other users’ accounts in the system, read their personal data, and perform sensitive actions on their behalf.

    API authentication flow and process need to be well protected and “Forgot password / reset password” should be treated the same way as authentication mechanisms. Make sure you know all possible flows to authentication to API (Mobile/Web/any link) and it gets well protected with authentication.
  3. Broken Object Property Level Authorization – When authorizing a user to access an object using an API endpoint, It is very important to validate that the user has permission to access the specific or all object properties.
    An API endpoint is considered as vulnerable if :
    • The API endpoint exposes properties of an object that are considered sensitive and should not be read by the user.
    • The API endpoint allows a user to change, add/or delete the value of a sensitive object’s property which the user should not be able to access.

      When you are exposing any API endpoint, always make sure that the user has access to the object’s properties you expose and avoid using any generic methods like to_json() and to_string().
  4. Unrestricted Resource Consumption – Enabling any API request, requires resources such as network bandwidth, CPU, memory, and storage. These resources have limited bandwidth and money associated with these resources.

    It is easy to exploit these resources by simple API calls or multiple concurrent requests. An API is vulnerable if at least one of the following limits is missing or set inappropriately.
    • Execution timeouts
    • Maximum allowable memory
    • Maximum number of file descriptors
    • Maximum number of processes
    • Maximum upload file size
    • Number of operations to perform in a single API client request (e.g. GraphQL batching)
    • Number of records per page to return in a single request-response
    • Third-party service providers’ spending limit
  5. Broken Function Level Authorization If any of the administrative API flows like delete, update, or create expose to unauthorized users it will be an easily vulnerable API endpoint. The best way to find broken function level authorization issues is to perform a deep analysis of the authorization mechanism while keeping in mind the user hierarchy, different roles or groups in the application, and asking the following questions:
    • Can a regular user access the administrative endpoint?
    • Can a user perform sensitive actions (e.g. creation, modification, or deletion) that they should not have access to by simply changing the HTTP method (e.g. from GET to DELETE)?
    • Can a user from Group X access a function that should be exposed only to users from Group Y, by simply guessing the endpoint URL and parameters?

      To mitigate this risk, the enforcement mechanism(s) must deny all access by default, requiring explicit grants to specific roles for access to every function.
  6. Unrestricted Access to Sensitive Business Flows — When you create an API endpoint some endpoints are more sensitive and critical than others. It is very important to understand which API endpoint and business flow you are exposing to the customer. Any restricted business flow exposed to clients can harm your business. In general, technical impact is not very severe but business impact might hurt your company’s credibility.

    For example, if your company offers a discount for one customer 20% and another customer 30% through API, if the first customer knows this discount variation, it will impact the credibility of the company as well as revenue loss.
    The mitigation planning should be done in two layers:
    • Business – identify the business flows that might harm the business if they are excessively used.
    • Engineering – choose the right protection mechanisms to mitigate the business risk.
  7. Server-Side Request Forgery – Server-Side Request Forgery (SSRF) vulnerability occurs when you are consuming remote APIs and resources without validating the remote endpoint or user-supplied URL. SSRF enables attackers to force the application to send formatted requests to an unknown destination even if protected by a firewall. Successful exploitation might lead to internal services enumeration (e.g. port scanning), information disclosure, bypassing firewalls, or other security mechanisms.

    The SSRF risk cannot be eliminated but you can mitigate these risks by isolating the resource fetching mechanism in your network, accepting media types for a given functionality, disabling HTTP redirections, Validating and sanitizing all client-supplied input data, and Using a well-tested and maintained URL parser to avoid issues caused by URL parsing inconsistencies.
  8. Security Misconfiguration — Security Misconfiguration vulnerability occurs when the latest patches are missing on the server or systems are outdated, Transport Layer Security (TLS) is missing, A Cross-Origin Resource Sharing (CORS) policy is missing, Error messages include stack traces or expose other sensitive information. Attackers often attempt to find unpatched flaws, common endpoints, services running with insecure default configurations, or unprotected files and directories to gain unauthorized access or knowledge of the system. These Security misconfigurations not only expose sensitive user data but also system details that can lead to full server compromise.

    Security misconfiguration risk can be mitigated by a repeating hardening process leading to fast and easy deployment, ensuring all communication happens over an encrypted communication channel (TLS), and implementing a proper Cross-Origin Resource Sharing (CORS) policy.
  9. Improper Inventory Management — It is important for organizations not only to have a good understanding and visibility of their own APIs and API endpoints but also how the APIs are storing or sharing data with external third parties. Multiple versions of APIs need to be properly managed, secure, patched and well-documented. Hackers usually get unauthorized access through old API versions or endpoints left running unpatched and using weaker security. requirements.
    Improper Inventory Management security vulnerability can be mitigated by documenting all hosted APIs for all environments (Prod or Non-Prod), Generating documentation automatically by adopting open standards and avoiding using production data with non-production API deployments.
  10. Unsafe Consumption of APIs — Unsafe Consumption of APIs vulnerability occurs when your developers tend to adopt weaker security standards, for instance, in regard to input validation, sanitization, URL redirections and not implementing timeouts for interactions with third-party services.
    This vulnerability can be mitigated by implementing proper data validation, and schema validation. Ensuring all API interaction happens on secured communication channels like TLS. Maintain an allowlist of well-known locations integrated APIs may redirect yours to do not blindly follow redirects.

Generative AI: How API making powerful customer experiences

Generative AI is more like a child where you instruct child that don’t bounce basketball inside home, but child goes to bounce a soccer ball inside home. But this was not your expectation from child and then this action falls outside of your expectation. Now you add more parameters with your instruction then the child is more likely to get the response that you want.

Generative AI is the same, the more context and parameter we can give to generative AI the better our service replies, the better emails, the better product recommendations get from your Generative AI Models.

We’re all seeing some amazing demos of generative AI these days. Models trained on the whole internet are able to hold a conversation, explain their reasoning, and perform well at a broad variety of tasks.

You’ve probably started to play with Chat GPT, Google Bard, or Microsoft Bing. In your company folks are already experimenting with different ways of data to use it in their work.

These chat interfaces, as an initial proof of concept, are truly amazing. it’s already becoming clear, the ability to create significant business value and it will be dependent on your ability to INTEGRATE and MANAGE these systems and data.

But there are multiple barriers standing in the way of our ability to implement AI.

  • Fragmented data is hard to ingest into AI models.
  • Missing context leads to poor recommendations.
  • Lack of trust in how the LLMs will use your data.
  • Difficulty in acting on the recommendations because AI is completely detached from business processes.
  • And of course, overall security risks of accessing data across various systems.

Technology is moving fast, and the recent introduction of AI innovation is exciting, especially with the promise of increased productivity. If you look at a public source like Hugging Face, there are over 250k AI models compared to only 32 significant industry-produced machine learning models in 2022. If you pair these figures with the fact that the average enterprise has over 1000 applications, suddenly you have a lot of API integrations to account for.

Without addressing your system integration challenges, you risk deploying AI that results in generic data in, and generic insights out.

Generative AI and API ecosystem

Let’s find how API fits into this Large-language models (LLMs) or generative AI space.

You can start with an LLM of your choice, such as Salesforce CodeGen or OpenAI’s CoPilot.

A large language model (LLM) is a deep learning algorithm that can perform a variety of natural language processing (NLP) tasks.

As you know, big models incur big cost, and LLM’s are expensive.

So large language models are exposed as APIs to reduce cost. As we know, APIs are the easiest way to get data in and data out from these LLM. These LLM’s are open for anyone to use. These APIs are also pulling data from your existing system as well as legacy system. Now you are enabling APIs which is required for your business process and adding data context which is make sense to business use-case.

Next, you can establish control over the APIs for your LLM by applying governance and security policies using Universal API Management. In this way, you can assure that your organization is leveraging AI while remaining secure and conformant. Once your APIs are secured then you can add automation and integration flow with your APIs which communicate with your internal systems. Enabling AI data through API You can push and pull data from a variety of data sources, including 3rd party applications, to ensure that you are using the latest data with the latest technology and building a complete 360 view of your customer.

API Safely unlock generative AI capabilities through a layer of trust Use Universal API management (UPIM) to provide security and governance for AI driven systems. The integration and automation tools also ensure the customer 360 is all up to date with the latest data, making powerful customer experiences possible.

Recession: Impact in Software as a Service(SaaS) 

Global uncertainties continue to dominate headlines. Inflation is expected to reach the highest levels of ~3.5% in the US and Europe by the end of 2023. To ease inflation, Central Banks need to dampen demand, by making it expensive (for financial institutions, businesses and households) to borrow by increasing Federal Reserve interest rates . We are expecting a federal rate hike of 4.75% – 5.0% by the end of 2023. These are all data showing we are heading toward recession. The US labor market was robust last quarter but this quarter it is not very promising. Everyday we are hearing layoff news from different sectors.

IMF inflation forecast

These inflation and layoff news are impacting our tech market. Many companies have a growth challenge: They expect to get as much as 50 percent of their revenue from new businesses and products by 2026 but are not on a path that will take them there. Current economic conditions are forcing high-growth yet unprofitable tech startups to tighten their financial belts.

There are few realities, software companies are facing for their growth.

US-based Venture capitalists backed software startups slowed down – VC are very clear of high valuation and demanding that companies spend less, improve profit margin and high output. Unicorn creation also slowed in 2022 Q4. This is one of the lowest quarterly count since the first quarter of 2020.

Depressed company valuations – Private company valuations are cooling down. Over the last 4 quarters, we have seen public valuations compressing.

 Software companies have three critical revenue streams.

  1. License / Subscription Revenue – When the customer pays for the right to own and use a copy of the software/hardware product or subscribe/access  software platform
  2. software or hardware product – Customer pays for ongoing support or premium support.
  3. Cloud based licensed software – Customer pays the software provider for specific deliverables such as software implementation or technical training.

In the current world all these 3 revenue streams are shrinking. Companies are using only essential services to run their business. This is directly impacting software revenue, which is leading these companies into low valuation.

Infrastructure Maintenance –  SaaS companies are providing the software as a service. This means the customer does not have to purchase hardware to run the software—that cost is transferred to the SaaS provider. This is implying continuous software running coast. This cost is not going anywhere.So due to inflation this SaaS running cost increases tremendously.

API Security

API is a key component of digital transformation. API is the interface of your legacy and SAAS data. The goal of APIs is to facilitate the transfer and enablement  of data between your system and external users. APIs are typically available through public networks like the internet to communicate to external users and expose your data into the public domain.

Since your data is exposed into the public domain through APIs, It can lead to a data breach. APIs can be broken and expose sensitive personal as well as company data. An insecure API can be an easy target for hackers to gain access to your system and network. Rise of IOT devices and usage of APIs by these IOT devices, APIs are now more vulnerable. 

According to owasp, these are 10 main API vulnerabilities.

  1. Broken Object Level Authorization – Expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue.
  2. Broken User Authentication – Authentication mechanisms are implemented incorrectly.
  3. Excessive Data Exposure – Developers  expose all object properties without considering their individual sensitivity
  4. Lack of Resources & Rate Limiting – APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user, lead to Denial of Service (DoS) attack on APIs
  5. Broken Function Level Authorization Complex access control policies with different hierarchies lead to authorization flaws.
  6. Mass Assignment – Without proper properties filtering based on an allowlist, usually leads to Mass Assignment.
  7. Security Misconfiguration – Misconfiguration or lack of Security configuration  is commonly a result of insecure APIs
  8. SQL Injection SQL Injection occurs when untrusted data is sent to an interpreter as part of a command or query.
  9. Improper Assets Management – APIs tend to expose more endpoints than traditional web applications lead to improper expose APIs.
  10. Insufficient Logging & Monitoring – Insufficient logging and monitoring fail to find your vulnerability and broken integration.

How to mitigate API security risk?

  • API supports secure sockets layer (SSL), transport layer security (TLS), and Hypertext Transfer Protocol Secure (HTTPS) protocols, which provide security by encrypting data during the transfer process.
  • Apply Basic Auth minimum with API or  if you want to more secure your API then enable 2 way authentication through OAuth framework . 
  • Apply Authorization on each API resource to more control on API security through external Identity and access management provider (IAM).
  • Use encryption and signatures to all your API exposed personal and organizational sensitive data.
  • Apply API throttling through API manager to control number of user access per API (Rate Limiting).
  • Implement best practice of exception handling on your APIs to hide all your internal server and database information to mitigate SQL injection security risk.
  • Use Service Mesh to manage different layers of API management and control.
  • Audit your APIs and remove all unused API from your API catalog.
  • Add proper logging, Monitoring and Alerting on your APIs to keep track of your APIs activity.

Conclusion: APIs are a critical part of modern AI, mobile, SaaS, IOT and web applications. APIs Security should be the main focus on strategies and solutions to mitigate the unique vulnerabilities and security risks .

Covid 19 :Digital Transformation

Digital Transformation

The coronavirus (COVID-19) outbreak is one of the worst pandemic in recent history. This pandemic is affecting almost every person in the world. This pandemic is changing our living style, working style and also affecting our society.

This pandemic crisis raised a number of unique challenges among small and enterprise businesses. Organizations are navigating the business and facing unique operational challenges and delivering their product to their customers during the pandemic. 

During this COVID-19 pandemic crisis here are few business challenges 

  • Resource Management 
  • Client Management 
  • Digital/online transformation 
  • Employee Remote work management

In this pandemic crisis API is playing a pivotal role to help their customers to migrate their business into digital through digital transformation solutions. API is playing a pivotal role to expedite digital transformation. API is also providing a platform  and solution for crisis management during this pandemic.

Here is API solution for business

  • Make decisions — APIs are creating open platforms that expose critical COVID and organization data to enable organization proper management and tracking.These API enable data are helping to create dashboard and AI model. These dashboard and AI models help organizations to  take decision or forecast their future strategy.
  • Respond and deliveries — Tracking and Management APIs are  enabling organizations to respond quickly for any crisis and deliver their product on time.This helps any organization to expand their business and digitalize their legacy system & assets.
  • Return to work — APIs, templates and connectors are helping to unlock employee data. Organizations are integrating with ERP systems through APIs and unlocking their employee and resources data during pandemic. It is also facilitating/helping their employees to return their work during pandemic time either remote or onsite.
  • Simplify delivery — Enabling APIs, templates and micro-services are helping to simplify and  improve their business process during pandemic.This is also helping to enable new innovation within organization and opening new business opportunity.

Covid 19 is also expediting digital transformation in healthcare. It is reshaping the way humans interact with technology in healthcare and Public Health Agencies  or Federal Regulators. COVID-19 is also pushing healthcare organizations to embrace the idea of digital health and intelligent data integration as a tool. “Contact tracing” during pandemics is only possible through enablement of APIs. Federal and state governments are getting “contact tracing” patient data through API and using this data to trace down the source of pandemic.

API is also enabling pharmaceutical industries to deliver medicine fast and on time. It is also helping to manage and track medicine dose and availability. 

Conclusion: Covid is disrupting whole industries and pushing companies to digital transform their process forever.

Mulesoft Performance Tunning

API Performance Tunning
  1. Keep the application synchronous if possible. Synchronous flows avoid serialization/deserialization of messages sent through VM queues, do not cause context switches, and do not cause contention when messages move across thread pools.
  1. Store as little as possible in variables. The vars are serialized and deserialized every time a message crosses an endpoint, even if it is a VM endpoint. This will impact performance overhead in direct proportion to the size of variables and the number of endpoints. 
  1. Use Dataweave Java payloads whenever possible. The usage of a canonical data model is recommended for projects that deal with data (mapping, transformation etc.). It is also recommended to create them in Java objects as dataweave whenever possible, as this provides the fastest format to access fields and change information and to convert to other formats.
  1. Encourage dataweave  languages. For better performance, use Dataweave for simple data extraction from messages, and Java components with dataweave for everything else. 
  1. Use flow references instead of VM endpoints. To communicate between flows internally within an application, use flow references instead of VM endpoints. The VM connector, even though it is an in-memory protocol, emulates transport semantics that serialize and deserialize parts of your messages, most notably the vars. This makes it slower than a flow reference, which just injects messages into the referenced flow with no intermediate steps. Please note that in some cases the usage of VM endpoints is preferred (see the chapter on reliability patterns). For example, a Mule cluster can load balance applications that use VM endpoints by deferring execution to another, available node in the cluster.
  1. Cache aggressively. Take advantage of Mule’s caching scope when making requests to external resources like Web services or databases. Also consider caching reusable assets such as security tokens or ephemeral API keys and cookies. Mule’s Notification subsystem can additionally be used to “warm up” a cache when Mule starts. For example, consider doing this for situations where an initial cache miss is not acceptable.
  1. Configure message processors and endpoints at the global level. Some connectors allow you to configure some parameters at both the global and the endpoint/message processor level. We recommend placing the configuration at a global level to avoid repeated initialization of resources. 
  1. Avoid creating a large volume of business events. Business events incur performance overhead in Mule and in platform when platform’s internal event buffer overflows. Thus, avoid using either default flow level business events or a large volume of custom business events in a high message volume project.
  1. Consider using message compression. For communicating between Mule applications over the network consider using Mule’s compression processors to compress/decompress the message payloads before they hit the wire if their sizes are large.
  1. Consider using VM queues instead of an external message broker. VM queues are fast and have some guaranteed delivery semantics in a cluster. Consider using these instead of going out to an external messaging broker for inter-application Mule communication.
  1. Use the async scope when appropriate. If a flow is performing processing on a message that is neither modifying the message nor changing how it is routed, then it could be wrapped in an async block. This will cause the processing to occur in a different thread and will avoid adding unnecessary overhead to processing the message.
  2. Use connection pooling for connectors because the performance cost of establishing a connection to another data source, such as a database, is relatively high.
  3. Optimize your logging within your mule flows. Too much logging will slow down your process and too less logging will hard to debug.
  4. Encryption and decryption of data is very costly. Whenever your Mule application really needs then apply encryption/decryption on your data.

Anypoint Platform: External (OKTA) Identity Management

Anypoint Platform acts as a client provider by default, but you can also configure external client providers to authorize client applications. As an API owner, you can apply an OAuth 2.0 policy to authorize client applications that try to access your API. You need an OAuth 2.0 provider to use an OAuth 2.0 policy. You can configure more than one client provider and associate the client providers with different environments. If you configure multiple client providers after you have already created environments, you can associate the new client providers with the environment. 

MuleSoft supports client management by identity providers that implement the OpenID Connect Dynamic Client Registration open standard. MuleSoft explicitly verifies support in Anypoint Platform for Salesforce, Okta, and OpenAM v14 Dynamic Client Registration. The following table contains examples of the URLs you need to supply, depending on your provider, during registration.

URL NameOkta Example URLOpenAM Example URLSalesforce Example URL
Base https://example.okta.com/oauth2/v1 https://example.com/openam/oauth2 https://example.salesforce.com/services/oauth2
Client Registration {BASE URL}/clients {BASE URL}/connect/register {BASE URL}/register
Authorize {BASE URL}/authorize {BASE URL}/authorize {BASE URL}/authorize
Token {BASE URL}/token {BASE URL}/access_token {BASE URL}/token
Token Introspection {BASE URL}/introspect {BASE URL}/introspect {BASE URL}/introspect
URL Name Okta Example URL OpenAM Example URL Salesforce Example URL

Steps to Create External Client Provider

  • Log in to Anypoint Platform using an account that has the organization administrator role.
  • In Anypoint Platform, click Access Management.
  • In the menu on the left, click Client Providers.

  • Click Add Client Provider, and then select OpenID Connect Dynamic Client Registration.
    The Add OIDC client provider page appears.
  • After obtaining values from your identity provider’s configuration, complete the following required fields in each section:
    • Dynamic Client Registration
      • Issuer: URL that the OpenID provider asserts is its trusted issuer.
      • Client Registration URL: The URL to dynamically register client applications as a client application for your identity provider.
      • Authorization Header
        • For Okta, this value is SSWS ${api_token}, where api_token is an API token created through Okta.
        • For ForgeRock, this value is Bearer ${api_token}, where api_token is an API token created through ForgeRock.
        • For Salesforce, this value is Bearer ${api_token}, where api_token is an API token created through Salesforce. In Advanced Settings you can also select:
      • Disable server certificate validation: Disables server certificate validation if your OpenID client management instance presents a self-signed certificate, or one signed by an internal certificate authority.
      • Enable client deletion in Anypoint Platform: Enables deletion of clients created with this integration.
      • Enable client deletion and updates in IdP: To use this option, you must also select the Enable client deletion in Anypoint Platform option.
    • Token Introspection Client
      • Client ID: The client ID for an existing client in your IdP capable of introspection of all tokens from all clients.
        • For Okta, this value should be a “Confidential” client.
        • For ForgeRock, this value should be a “Confidential” client.
        • For Salesforce, this value should be a “Confidential” client.
      • Client Secret: The client secret that corresponds to the client ID.
    • OpenID Connect Authorization URLs
      • Authorize URL: The URL where the user authenticates and grants OpenID Connect client applications access to the user’s identity.
      • Token URL: The URL that provides the user’s identity, encoded in a secure JSON Web Token.
      • Token Introspection URL: endpoint that returns metadata about the access token, including expiration and token active state.

Mule 4: Consume a SOAP Webservice

The Web Service Consumer is an existing connector in Mule 4 that you can configure to point to a SOAP based web service. Webservice consumer call webservice hosted elsewhere as WSDL SOAP services and get response. This connector simplified process and encapsulated all the feature to consume SOAP based webservice. When no connector is available specific to any product (like Service-Now, Workday etc.), which is hosted as SOAP based webservice then this webservice consumer Connector enables any services to consume.

The main feature of this connector is

  • Consuming DOC Literal Web services.
  • SOAP multipart messages.
  • SOAP Headers.
  • DataSense support for SOAP Headers, SOAP Body, and Attachment.
  • Embedded DataWeave transformations inside the operation.
  • Support and Unified experience for SOAP with attachments and MTOM handling.
  • Custom HTTP configuration as transport (runtime and design time).
  • Web Service Security (WS Security) support.

Connector Configuration- In this section we define connector configuration to communicate with SOAP based webservice end point. By default, connector uses a simple non protected HTTP configuration to send all outgoing SOAP message.  In connector configuration you can select your SOAP version from drop down  and provide WSDL location. Connector extract and populates Service, Port and webservice endpoint address from WSDL file.

But if you are using secure endpoint address with HTTPS you need to configure custom Transportation Configuration for HTTPS.

These are the steps to enable your secure HTTPS endpoint.

  • Create jks file with keytool command
 keytool -keystore clientkeystore.jks -genkey -alias client 
  • Download certificate from WSDL HTTPS endpoint and add this certificate in your JKS file with below command
keytool -importcert -file certificate.cer -keystore clientkeystore.jks -alias "Alias"
  • Now configure TLS Context for Webservice consumer connector.
<tls:context name="TLS_Context" doc:name="TLS Context" doc:id="f634b824-2695-4d5f-8789-7a309b1511cb" >
           <tls:trust-store path="certificate/clientkeystore.jks" password="xxxxxx" type="jks" />
     </tls:context>
  • Now configure HTTP Request configuration for HTTPS endpoint.
<http:request-config name="HTTPS_Request_configuration" doc:name="HTTPS Request configuration" doc:id="02db1fd9-9f04-4eae-83cf-df43effd25d2">
           <http:request-connection protocol="HTTPS" host="service.vanrish.com" port="443" tlsContext="TLS_Context">
     	   </http:request-connection>
	</http:request-config>

  • If TLS and HTTPS configuration configured then you can select HTTP request configuration from Webservice consumer
<wsc:config name="BookService_Web_Service_Consumer_Config" doc:name="Book Web Service Consumer Config" doc:id="59fd0d73-f90d-4cf0-9855-c008307067a2" >
 <wsc:connection wsdlLocation="wsdl\bookservice.wsdl" service="BookService" port="BookServicePort" address="https://service.vanrish.com:443/service/BookService">
  <wsc:custom-transport-configuration >
    <wsc:http-transport-configuration requesterConfig="HTTPS_Request_configuration"/>
  </wsc:custom-transport-configuration>
 </wsc:connection>
</wsc:config>

Connector Parameter- If connector configuration is configured properly, your operation parameters are available from WSDL as drop down options.

In Message section there are three parameters available

  1. Body – The Body is main part of the SOAP message. The body element accepts embedded DataWeave scripts as values so that you can construct the XML request without having a side effect on the message or having to use multiple components to create the request.
  2. Headers – The headers element contains application-specific information (like authentication, payment, and so on) about the SOAP message . This elements accepts embedded DataWeave scripts as values.
  3. Attachment – The attachments element enables you to bind attachments to the SOAP message. This element also accepts embedded DataWeave scripts as values.

Since you configured custom HTTPS connector for your webservice consumer Connector you can configure Transport Configuration. In Transport header section you can select “Edit inline” and add all your header parameters in line

<wsc:consume doc:name="Consume" doc:id="ca5a1247-7cf6-4c7f-a442-b6fd037c13c9" config-ref="BookService_Web_Service_Consumer_Config" operation="AddBook">
       <wsc:transport-headers >
          <wsc:transport-header key="SOAPAction" value="AddBook" />
          <wsc:transport-header key="Content-Type" value="text/xml; charset=UTF-8" />
          <wsc:transport-header key="Authorization" value="${book.authorization}" />
       </wsc:transport-headers>
 </wsc:consume>

Here is webservice consumer flow diagram

Code for this flow

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
	xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:tls="http://www.mulesoft.org/schema/mule/tls"
	xmlns:wsc="http://www.mulesoft.org/schema/mule/wsc"
	xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/wsc http://www.mulesoft.org/schema/mule/wsc/current/mule-wsc.xsd
http://www.mulesoft.org/schema/mule/tls http://www.mulesoft.org/schema/mule/tls/current/mule-tls.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">
	
	<wsc:config name="BookService_Web_Service_Consumer_Config" doc:name="Book Web Service Consumer Config" doc:id="59fd0d73-f90d-4cf0-9855-c008307067a2" >
            <wsc:connection wsdlLocation="wsdl\bookservice.wsdl" service="BookService" port="BookServicePort" address="https://service.vanrish.com:443/service/BookService">
	            <wsc:custom-transport-configuration >
					<wsc:http-transport-configuration requesterConfig="HTTPS_Request_configuration" />
				</wsc:custom-transport-configuration>
            </wsc:connection>
     </wsc:config>

	<tls:context name="TLS_Context" doc:name="TLS Context" doc:id="f634b824-2695-4d5f-8789-7a309b1511cb" >
           <tls:trust-store path="certificate/clientkeystore.jks" password="changeit" type="jks" />
     </tls:context>

    <http:request-config name="HTTPS_Request_configuration" doc:name="HTTPS Request configuration" doc:id="02db1fd9-9f04-4eae-83cf-df43effd25d2">
           <http:request-connection protocol="HTTPS" host="service.vanrish.com" port="443" tlsContext="TLS_Context">
     	   </http:request-connection>
	</http:request-config>

	<sub-flow name="addbook-ServiceSub_Flow" doc:id="511f0969-0b7d-4b7e-a113-60ef03e97648" >
             <logger level="INFO" doc:name="Logger" doc:id="e6bd0106-e512-4fdd-97cf-1dbd77e1e0e7" message="Entering into AddBook flow"/>
                             <ee:transform doc:name="Transform Message" doc:id="06cc17de-86a9-4c53-a2f4-167d9561bed9" >
                                           <ee:message >
                                                          <ee:set-payload ><![CDATA[%dw 2.0
 output application/xml skipNullOn="everywhere"
 ns n0  https://www.service.vanrish.com/BookService/
  ---
   n0#AddBook:
         {
                 n0#Book : {
                 	ID: payload.id,
                 	Title : payload.title,
                 	Author : payload.author
                 }
         }]]></ee:set-payload>
                                           </ee:message>
                             </ee:transform>
                             <logger level="INFO" doc:name="Logger" doc:id="ce84f628-7b38-4d2d-b5e3-9fdded2c9289" message="soap request --> #[payload]"/>
                             
<wsc:consume doc:name="Consume" doc:id="ca5a1247-7cf6-4c7f-a442-b6fd037c13c9" config-ref="BookService_Web_Service_Consumer_Config" operation="AddBook">
                                           <wsc:transport-headers >
                                                          <wsc:transport-header key="SOAPAction" value="AddBook" />
                                                          <wsc:transport-header key="Content-Type" value="text/xml; charset=UTF-8" />
                                                          <wsc:transport-header key="Authorization" value="${book.authorization}" />
                                           </wsc:transport-headers>
                             </wsc:consume>
                             <logger level="INFO" doc:name="Logger" doc:id="680d69e0-2b01-480c-afe7-660ca22b2f9f" message="AddBook Output-->#[payload]"/>
                             <ee:transform doc:name="Transform Message" doc:id="72d26561-107a-4c6e-a7d4-85bd18e0d316" >
                                           <ee:message >
                                                          <ee:set-payload ><![CDATA[%dw 2.0
ns ns0 https://www.service.vanrish.com/BookService/
 

output application/json skipNullOn="everywhere"
---
payload.body.ns0#AddBookResponse]]></ee:set-payload>
                                           </ee:message>
                             </ee:transform>
                             <logger level="INFO" doc:name="Logger" doc:id="ea517185-efa4-4bf2-a03f-e8bd4d308e80" message="Output AddBook --> #[payload]"/>
              </sub-flow>
</mule>

Mulesoft: FedRamp Compliance Cloud Integration for Government

Fiscal year 2019, government estimated $45.8 billion on IT investments at major civilian agencies, which will be used to acquire, develop, and implement modern technologies.78% of this budget goes to maintain existing IT system. In a constantly changing IT landscape, the migration of federal on-premise technologies to the cloud is increasing every year. Federal agencies have the opportunity to save money and time by adopting innovative cloud services to meet their critical mission needs and keep up to date with current technology. Federal agencies are required by law to protect any federal information that is collected, maintained, processed, disseminated, or disposed of by cloud service offerings, in accordance with FedRAMP requirements.

What is Federal Risk and Authorization Management Program (FedRamp) ? 

FedRamp is a US government-wide program that delivers a standard approach to security assessment, authorization, and continuous monitoring for cloud products and services. The stakeholders for FedRamps are 

  1. Federal Agencies
  2. FedRamp PMO & JAB(Joint Authorization Board)
  3. Third Party Assessment Organization

FedRamp Process There are 3 ways a cloud service can be proposed for FedRamp Authorization.

  1. Cloud BPA — Cloud Services through FCCI BPAs
  2. Government Cloud Systems — Services must be intended for use by multiple government or government approved agencies.
  3. Agency Sponsorship — This is the most popular route for cloud service providers (CSPs) to take when working toward a FedRAMP Authorization. CSP to establish a partnership with an Agency and agree to work together for an Authority to Operate(ATO).

Mulesoft FedRAMP Authorize Integration Platform

Mulesoft recently announced, FedRAMP process implementation of Anypoint Platform. MuleSoft is one of the first integration platform companies with FedRamp authorization and enabling both on-premises and cloud integration in the federal government and state government. Enablement of FedRamp of Mulesoft Anypoint platform, government IT teams can leverage the same core Anypoint Platform benefits in the cloud to accelerate their project delivery via reusable APIs.Anypoint Platform allows all government integration assets to be managed and monitored from a single, secure, cloud based management console, simplifying operations and increasing IT agility. 

Mulesoft Anypoint platform enables FedRamp-compliant iPAAS for government organization. Government IT integration project deploy in Anypoint platform within Mulesoft Government cloud 

  1. Accelerate government IT project deliveries by deploying sophisticated cross-cloud integration applications and create new APIs on top of existing data sources
  2. Project deliveries improve efficiencies at lower cost by allowing IT integration teams to focus on designing, deploying, and managing integrations in the cloud and allowing agencies to only pay for what they use, .
  3. Reduce risk of your IT project integration and increase application reliability by using of self-healing mechanism to recover from problems and load balancing.  

What is Mulesoft Government Cloud?

Mulesoft government cloud is a FedRamp-compliant, cloud based deployment environment for Anypoint platform. 

  1. It is built on AWS GovCloud with FedRamp control. 
  2. Mule Runtimes configured in secure mode to support the highest encryption standards and FIPS(Federal Information Processing Standard)  140-2 hardware and software encryption compliance.
  3. It is FedRamp-compliance at the moderate impact level.
  4. It is continuous 3rd party(3 POs) auditing and monitoring of security control.

Mulesoft government cloud can be access through this link https://gov.anypoint.mulesoft.com/login/ . Mulesoft Government cloud resources are available through Anypoint exchange. Mulesoft Government cloud exchange URL is https://gov.anypoint.mulesoft.com/exchange/ .

If you are accessing FedRamp-compliant Anypoint platform, after logging you get end user agreement as a consent. It is very typical for FedRamp-compliant government application.  

Conclusion — Executing any government or state project and working on different integration as well as API enablement, FedRamp-compliant Anypoint platform is one of the best options. It accelerate IT project deliveries, improve efficiencies and reduce IT risk .