NLX has authorization features for both the inway and the outway. This document describes these features.
Authorization on an outway
When you want to restrict which of your applications can communicate with other services using your outway, you can setup authorization on the outway. To enable authorization on an outway, organizations can plug-in their own authorization service. Once configured, all requests will be authorized by this service before routing the request to the targeted API in the NLX network.
How it works
Once an authorization service is configured the outway will, after receiving a request from an application, extract all the HTTP-headers from the request. Only the HTTP headers along with the destination organization and service will be send to the authorization service. The authorization service can use this information to determine if authorization should be granted. The authorization service will send the result back to the the outway. If the authorization is granted the outway will strip the HTTP headers starting with
X-NLX from the request and continue sending the request (body + HTTP headers) to the destination inway.
The authorization interface
In order to keep the NLX components as flexible as possible, each organization will have to implement the "authorization interface" on their own authorization service. Implementing this interface will enable communication between the outway and the authorization service. We have described this interface using Open API Specification (OAS). This specification can be found here. A reference implementation has also been made available in the NLX repository.
Configuring the outway
After you have implemented the authorization interface on your authorization service, you will have to configure the outway to use it. This can be done by setting the environment variable
AUTHORIZATION_SERVICE_ADDRESS in the docker image of the outway. This variable should contain the URL of your authorization service.
For example, the URL of our authorization service is
https://auth.nlx.io, we can start the outway by running the following docker command:
docker run --rm \
--name my-nlx-outway \
--volume ~/nlx-setup/root.crt:/certs/root.crt:ro \
--volume ~/nlx-setup/org.crt:/certs/org.crt:ro \
--volume ~/nlx-setup/org.key:/certs/org.key:ro \
--env DIRECTORY_ADDRESS=directory-api.demo.nlx.io:443 \
--env TLS_NLX_ROOT_CERT=/certs/root.crt \
--env TLS_ORG_CERT=/certs/org.crt \
--env TLS_ORG_KEY=/certs/org.key \
--env AUTHORIZATION_SERVICE_ADDRESS=https://auth.nlx.io \
--env AUTHORIZATION_ROOT_CA=~/nlx-setup/root.crt:/certs/root.crt:ro \
--env DISABLE_LOGDB=1 \
--publish 80:8080 \
Please note we are also setting the environment variable
AUTHORIZATION_ROOT_CA. This variable contains the path to a root Certificate Authority(CA). To keep everything as secure as possible, your authorization service must only accept connections with TLS enabled. The configured root CA will be used by the outway to verify the certificates of your authorization service.
HTTP-headers are used to pass around authorization information. NLX provides a set of HTTP-headers which will be logged in the transaction-log and stripped from any request as soon as this request leaves the organization.
X-NLX-Requester-Usershould contain information about the user, for example a userID
X-NLX-Requester-Claimsshould contain claims granted to the user
Proxy-Authorizationshould contain the credentials to authenticate a user or application with a server. For example, a JWT token. This header will always be stripped, even if the request does not leave the organization. Take a look at the Mozilla Proxy-Authorization header documentation for more information about this header.