As you might have noticed, the last few posts are all about identity and the so called Secure Hybrid Access solutions. This one fall under that same category and is not sponsored by, but I did get a test account from them….

Active Directory or any identity store is usually used as the primary source for authorizations. This is (usually) based on groups or dynamic groups based on roles. But the actual implementation of that authorization is usually within the application itself. Whether it is on the SQL table, the folder or file and sometimes even method in an application, the application owner can grant or deny permissions. With more and more microservices based applications being developed, keeping an eye on the roles and permissions users (or API’s) have becomes a challenge. So, what if we can push the ruleset for access out to another service. One that is scalable and able to manage all my applications and determine based on rulesets and claims who gets access to what? That is where Datawiza comes into play. The architecture is fairly simple, you have a cloud based management engine where the rules are defined, an agent that is deployed in front of your application(s) and (optionally) an identity provider (such as Azure Active Directory or Okta or Ping.. or .. ) to provide the authentication.

The proxy agents are hosted in Docker or Kubernetes and while the applications might be hosted there as well that is not mandatory any backend URL will work, as long as these agents can connect to it. You don’t have to configure each proxy agent individually for the front-end port or backend application, the only configuration to be given to the agents is an application identity and key (to authenticate to the management portal), and this can be done in the deployment file. By using containers, you can create as many as you need as well, without thinking about load balancing or individual configurations as this is handled by (in my case) AKS.

Management Portal

The management portal is where administrators create deployment configurations. Obviously in the time of pure DevOps the portal can also use API calls to automate any deployment.

Each deployment can have one or more applications and in the future also administrators. API access is per deployment itself for automation integration. Each deployment has the deployed proxy agents and each application then has a port to listen on as well as the backend URL where the agents need to connect to.

URL authorization is also available per application and this specifies access to URL’s based on for example IdP attributes so administrators can allow/deny access based on input claims method from the identity provider, but also external LDAP groups lookups, time and date, source IP or HTTP which URL paths are available. Using multiple combinations, we can for example only allow HTTP POST actions during specific time windows.

Which is awesome for protecting your website according to the actual requirements for the website, currently if the rule results in a deny you will receive a generic error message, but in future releases you can set an alternative URL.

To make the claims from the IdP available in the backend application, administrators can choose to forward each attribute as a header or add them in a cookie to the backend. This allows for a flexible implementation inside the published application itself and makes it easier for developers to work with the attributes such as name, company, etc directly in the code and removes the need for integrating the application directly with the IdP.

While today there is only a single administrator role, the roadmap is to have different Admin roles available in the system to for example have a single IdP administrator, or allow access to only certain applications via web (this is already available via the API per deployment).

Conclusion

So the verdict.. by removing the identity and access configuration from applications and into a separate service, DataWiza has realized the separation of development and identity and access. Developers are good at creating code to execute as fast as possible, with microservices coming in more and more, the complex world of identity and security needs to be simplified and centralized and not be in the way of development and innovation. Now you could argue that other proxy services could do the same. As I’ve mentioned a few times on my blog already, F5 is very capable of managing a similar architecture with their APM module. But I think the mindset behind it is very different. While F5 is a pure proxy solution that happens to also provide identity services and can implement URL authorization the way they do this is a bit more cumbersome and almost requires coding skills for the F5 iRule logic. Datawiza have managed to make it easy for integrating Identity, URL authorization rules and developers for managing identities and security to their application. There’s just a few more items to be solved (admin roles, custom error messages etc..) and this is an awesome product to publish your web/API applications.