Welcome
Background
The diagram below sketches how authentication and authorization is handled in most of today’s applications.
Figure 1. Typical deployment scenario
On the one hand it allows the backend service to fully control the corresponding security requirements. On the other hand it has some limitations:
It works as long as there is just one authentication system.
When there are multiple backend services, which is typically the case in modern architectures, it requires each backend service to repetitively implement security related capabilities in its code, and related to this
it requires the backend services to communicate to further systems to e.g. get additional (context) information about the request and the subject (the user the request belongs to).
All this pretty often leads to the fact that up to 60% of the implementation efforts are spent on security topics and only the smaller rest on the actual business requirements. In addition, these limitations imply a lot of effort if there are changes to authentication and authorization requirements. So, what would you do if you have to use multiple authentication systems, e.g. for your customers and for your system admins, or backoffice stuff? What would you do, if e.g. our business would like to introduce a new service subscription model for its customers? What does this mean in sense of coordination-, implementation efforts and time-to-market?
Heimdall’s Promise
Heimdall addresses the aforesaid challenges companies and developers face, especially with a distributed or microservices architecture. Whether you’re building from scratch or migrating existing applications, heimdall can help and allows you to transparently add security capabilities related to authentication and authorization without adding them to your own code, but nevertheless, by completely retaining control. It can do so standalone, but also integrated into available infrastructure.
How It Works
Heimdall intercepts all your application related network traffic, allowing a broad set of application aware authentication and authorization features based on the rules you define. This is done by routing each request through a rule specific pipeline as depicted in diagram below.
Figure 2. Request Pipeline
This pipeline ensures that, according to the needs of the particular backend service endpoint,
each request is authenticated (so, you know who the subject of the request is),
the required contextual information about the subject is available (like e.g. current location based on IP, roles or groups membership information, etc.), so that
the subject can be and is authorized and
the information about the subject is transformed into a format, required by the backend service. So that irrespectively of the used authentication or authorization system, the subject information is always provided in the same stable representation.
And all of that can be controlled by each and every backend service individually.
Last updated on Dec 13, 2022