Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Securing APIs With Zato and Vault: Part I

DZone's Guide to

Securing APIs With Zato and Vault: Part I

Vault stores and makes use of secrets that offer support for common authentication-related workflows and policies describing what action a secret holder can perform.

Free Resource

Modernize your application architectures with microservices and APIs with best practices from this free virtual summit series. Brought to you in partnership with CA Technologies.

One of the fundamental principles of programming with Zato is that one's services are typically insulated from the inner workings of underlying data formats or security schemes. After all, why bother with mundane tasks such as authentication or authorization? It should be the platform's job. User services should focus on their own job.

Conversely, once a security definition is created in web-admin, it can be applied in multiple places without requiring any changes to Python code.

All of that applies to a newly added feature of Zato that lets one keep API secrets in Vault. This post introduces key concepts behind it.

Screenshot

What Is Vault?

Vault is a dedicated tool to store and make use of secrets that offers support for common authentication and authorization related workflows such as secure storage and broad or fine-grained secrets management as well as policies describing what action a given holder of a secret can perform.

The system is open to customizations and makes for a great companion to Zato in letting one easily express who can access what, for how long, and under what conditions.

Vault needs to be installed separately to Zato. This post assumes that there is a Vault instance running on http://localhost:49517, already unsealed, using the configuration below.

Essentially, this is a development server. However, unlike the Vault's default dev server, this one keeps data on disk instead of RAM.

disable_mlock = true

backend "file" {
  path = "./vault-dev.db"
}

listener "tcp" {
  address = "127.0.0.1:49517"
  tls_disable = 1
}

Creating Vault Connections

The easiest way to create a new connection is through web-admin. Simply fill out the form as below and a new connection to Vault will be created.

Screenshot

  • Name: An arbitrary name of the connection.
  • URL: Where Vault can be found.
  • Token: Vault token. Note that it should be possible for this token to look up tokens and credentials of incoming requests.
  • Default authentication method: Which authentication backend to use default to authenticate requests. Can be token, username/password, or GitHub. LDAP is coming up soon.
  • Service: A service that can be invoked if no default method was defined. The service can extract credentials from the request and indicate what method to use.
  • Timeout: How long to wait for responses from Vault.
  • TLS options: Whether TLS connections should be verified, and if so, using what CA certs unless default ones should be employed. Also, an optional client TLS key and certificate can be uploaded so that Zato itself authenticates with Vault using this key/cert pair.

Attaching Vault Connections to Channels

Authentication with Vault works with regular HTTP REST or SOAP channels as well as with WebSockets. Pick the newly created Vault connection from the list, click OK, and your channels will now be secured by Vault.

If you have already existing channels, you can swap out their current security definitions for Vault-based ones and things will just work without server restarts.

ScreenshotScreenshot

Policies

The above is everything that is needed to define API endpoints backed by Vault that will now, on behalf of Zato, authenticate users according to what was provided on input when invoking a service.

However, a complementary aspect is that of authorization. Assuming that in the incoming request, there were valid credentials and the service can be invoked at all, we can do one better We can go a step further and define Vault policies to express business relations between objects exchanged in API calls. This will let one store rules in a central place accessible to any API endpoint.

This part of the Zato-Vault interface is still under active development. Watch this space for more information!

The Integration Zone is proudly sponsored by CA Technologies. Learn from expert microservices and API presentations at the Modernizing Application Architectures Virtual Summit Series.

Topics:
zato ,vault ,apis ,integration ,tutorial

Published at DZone with permission of Dariusz Suchojad. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}