Configuration-Managed Web Access Policies

Traditional Web Access Management (WAM) is heavily centralized because of legacy implementation restrictions. Access policies are defined, created and maintained in a centralized way by the IT department that runs a so-called access policy server. The policies execute at runtime by having endpoints call in to the Policy server, possibly caching the result for a while for performance reasons. The policy itself however remains on the policy server, in a central location. Clustering techniques would be used to scale the policy server itself.

Yet there are a number of recent developments (I’m counting 4) that have brought changes to this world: the micro-services paradigm, containerization technology like Docker, Dev-Ops methodologies, and software configuration management tools such as Ansible, Chef, Puppet, Vagrant etc.

This allows one make an interesting shift wrt. access policy execution. Since the vast majority of policies is fairly static those policies can actually be pushed out at configuration time to the endpoints themselves. The endpoints can then execute and enforce policies on their own at runtime without needing to callout to an external server. This greatly benefits performance and resilience. Changes to a policy would involve re-creating an updated configuration file for the application, pushing it out via the software configuration management tool and restarting the application server. Some may even go as far as creating new binary container images from the configuration files and restarting updated containers with new policies that replacing the original ones.

Especially when running a bunch of reverse proxy servers in front of your services and APIs to handle security such as OAuth 2.0 and/or OpenID Connect termination and token validation this presents an pattern that has architectural and business advantages over plain performance and resilience advantages. It allows one to avoid getting locked into vendor specific protocols that have dominated the web access control market for the last decades because of the lack of standardization (or adoption (read: XACML)) of open standards between Policy Enforcement Points (PEPs) and Policy Decision Points (PDPs).

The tooling around creating application specific configuration files with access control policies is freely available and widely deployed for a range of reverse proxies and applications. See e.g.: https://hub.docker.com/r/evry/oidc-proxy/

Just to make sure: I’m well aware that static policies may not be everything a modern environment needs in the near future. Policies based on dynamic data are becoming more important as we speak with user behavior analytics, aggregated log analysis etc.. Runtime behavior can only be aggregated and analyzed in a centralized location and needs to be consulted at policy execution time. But that does not change the fact that static policies (say 95% today) can be realized in the way as described.

So what does the future hold? Well, expect a blend. The vast majority of web access management policies deployed today is ready for a “distributed configuration managed” deployment using modern technologies as mentioned. We’ll see what the future brings for the dynamic part. For the record: I’m calling this paradigm C-WAM. (pronounced as Shhwam!)

PS: I’m sure you’ve noticed how mod_auth_openidc and Apache httpd.conf fits in the world as described…

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s