Token Binding specs are RFC: deploy NOW with mod_token_binding

Update 10/18/2018: Google Chrome actually removed Token Binding support in version 70 so you’ll have to be on an older version to see this work in action, or use MS Edge, also see here. See here to learn how to run two Chrome versions side-by-side.

Today the so-called Token Binding specifications have formally been promoted to proposed standards RFC by the IETF. Essentially those specs define how to securely bind tokens to the communication channel running between a client and a server. As simple as that sounds, it is an extremely important step forward in web security: tokens are used everywhere across the Internet today  (e.g. for SSO, APIs, Mobile Apps) but moreover, the ubiquitous HTTP cookie also falls into the security token category.

In this post we’ll focus on securing HTTP cookies in Web Applications. HTTP cookies are pervasive on the web yet the vulnerability window for stealing such a cookie is usually larger than the window for stealing a security token, the damage is typically larger and abuse is harder to detect. Applying Token Binding to HTTP cookies closes a vulnerability in the web application landscape and prevents session hijacking by stealing a session cookie. See for example a class of XSS attacks that will now fail: https://www.hackeroyale.com/cookie-stealing-xss/ but also retrieving a session cookie from application/server logs, from the network, or through malicious client software etc. is no longer effective.

Implementing the Token Binding protocol itself in your application by interfacing with the TLS layer is complex and may go wrong easily. So how can an application leverage Token Binding today without jumping through time-consuming and dangerous hoops . Well, applications on or behind Apache are catered for by mod_token_binding: they can leverage a header or environment value set by mod_token_binding in their session cookie (or in other tokens they generate for that matter). The hard protocol security bits are dealt with by mod_token_binding and a trivial 2-step implementation process remains for the application itself. See below for a sample in PHP:

  1. At session creation time: put the Token Binding ID provided in the environment variable set by mod_token_binding into the session state
$tokenBindingID = apache_getenv('Sec-Provided-Token-Binding-ID');
if (isset($tokenBindingID)) {
  $_SESSION['TokenBindingID'] = $tokenBindingID;
}

2. On subsequent requests: check the Token Binding ID stored in the session or token against the (current) Token Binding ID provided in an environment variable

if (array_key_exists('TokenBindingID', $_SESSION)) {
  $tokenBindingID = apache_getenv('Sec-Provided-Token-Binding-ID');
  if ($_SESSION['TokenBindingID'] != tokenBindingID) {
    session_abort();
  }
}

Et voila, we’ve bound the PHP session cookie to the TLS channel with the Token ID provided by mod_token_binding that’s all there is to it!

As another example is mod_auth_openidc, the OpenID Connect RP client for Apache HTTPd. This module already leverages this functionality for its own session cookie, its state cookie and the id_token, the latter if only supported by the Provider.

Anyone using mod_auth_openidc should look to deploy it in conjunction with the Token Binding module now! (but be aware that you need to upgrade your Apache server to >= 2.4.26 and build/deploy it with a OpenSSL >= 1.1.1 stack)

But also legacy applications may use Apache HTTPd with mod_auth_openidc deployed as a Reverse Proxy in front of their origin server so that their own session can only be started/accessed through an authenticated OIDC session cookie that leverages Token Binding. That makes them now effectively use Token Binding to protect themselves against session hijacking without touching the application and/or their own application session cookie [1].

Looking forward to lots of happy mod_token_binding usage!

[1] Note that the users’s browser also needs to support Token Binding to leverage all of this good work, but Microsoft’s Edge and Google’s Chrome already do this and support in other browsers such as Firefox is near.

Advertisements
Posted in Uncategorized | Leave a comment

A Security Token Service client for the Apache webserver

I’ve recently been working on mod_sts a so-called Security Token Service client for the Apache web server. This module allows for exchanging arbitrary security tokens by calling into a remote Security Token Service (STS). It operates as a so-called “active” STS client, i.e. a non-browser, non-interactive STS client. The STS function allows for creating a split between tokens presented from remote security domains (customers, clients, partners, consumers) and tokens generated and used within an internal (or in any case, a different) security domain. So why would you want to do that:

  • a split between external (“source”) tokens and internal (“target”) tokens may be enforced for security reasons, to separate external requests/tokens from internal requests/tokens whilst keeping “on-behalf-of-a-user” semantics; backend services would never see/obtain customer tokens directly, which may satisfy a compliance/regulatory obligation or just good security practice because internal services woud not be able to impersonate the original client
  • for legacy reasons in case your backend only supports consuming a proprietary/legacy token format/protocol and you don’t want to enforce support for that legacy onto your external clients that use a standardized token/protocol (or vice versa…)
  • when the backend service needs to call a 3rd-party service to fulfill its function it is good security practice to obtain a new token “on its own behalf” rather than calling the remote service with the source token obtained from its client; this use case is often handled with a static service credential but in that case the (verifiable) context of the original user is lost; the STS allows for obtaining a new token for calling a 3rd-party service whilst retaining the “on-behalf-of” semantics for the original client/user

This module can be used in scenario’s where an Apache server is put in front of an origin server as a Reverse Proxy/Gateway that consumes “source” tokens presented by external clients but needs to forward those requests presenting a different “target” security token, turning around and acting as its own client to a backend service. Note that the backend service can also be an application that is hosted on the Apache server itself, e.g. a PHP application or a 3rd-party provided application.

I turned out as a pretty generic and powerful module catering for “delegation”, “impersonation” and “legacy wrapping” scenario’s as described above, dealing with:

  1. arbitrary incoming token formats and protocols e.g. OAuth 2.0 access tokens, cookies, JWTs, legacy tokens in headers etc.
  2. arbitrary outgoing token formats and protocols e.g. OAuth 2.0 access tokens,  vendor specific or legacy cookies/tokens, JWTs etc.
  3. a few types of – somewhat standardized – STS protocols i.e. WS-Trust, but also the new OAuth 2.0 Token Exchange protocol, a work in progress and even a “twisted” Resource Owner Password Credentials grant that I’ve seen a number of times in the field being used for that purpose

You’ll be pleased to know that it plays nicely with mod_auth_openidc in OAuth 2.0 Resource Server mode, consuming a verified access token from an environment variable set by mod_auth_openidc.

Happy STS-ing with mod_sts and let me know if you have questions, suggestions or need support.

Posted in Uncategorized | 1 Comment

Access Control using Reverse Proxy XACML PEPs

Following the previous post that I wrote a while ago about authenticating reverse proxies in front of resources you want to protect with OpenID Connect or OAuth 2.0, this post is about the next step: access control using those proxies. Whilst the plugins that I talked about have basic access control possibilities built in to them, it may be that you want to integrate it with a central XACML Policy Engine that your company already deploys. To facilitate that, I have developed plugins that implement the XACML 3.0 Policy Enforcement Point logic into NGINX and Apache HTTPd.

In this way you can write and maintain advanced access control logic in XACML policies using your XACML 3.0 Policy Administration Point and enforce those policies directly in your reverse proxy web servers that protect your business assets. The communication between the web server PEP and the PDP engine is done using the XACML 3.0 REST and JSON Profiles, so it has minimal overhead in terms of processing and payload.

Look here for the NGINX plugin: https://github.com/zmartzone/lua-resty-xacml-pep

There’s a similar plugin for Apache 2.x that can be purchased under a commercial agreement. For details contact: info@zmartzone.eu

Posted in Uncategorized | Leave a comment

OAuth 2.0 and OpenID Connect for existing APIs and Web Applications

TLDR; deploy a reverse proxy with OAuth 2.0 and OpenID Connect capabilities in front of your existing API and web applications to secure those assets with the modern security and access control standards without having to touch them.

Organizations these days have an obvious choice when it comes to developing new applications and APIs and securing them: modern standards such as OAuth 2.0 and OpenID Connect provide an easy and standardized way to protect their assets in a future proof and secure manner. Things become more complicated when dealing with the existing landscape of applications and APIs. Embedding them in the same modernized security environment would make them benefit from the same advantages in the areas of standardization, cost reduction and security. Yet the existing applications are often hard to modify and extend with support for the modern security protocols so how to deal with that?

Enter reverse proxy: by leveraging the well-known, mature and widely deployed concept of a reverse proxy in front of the assets you want to protect you can make this happen. The reverse proxy doesn’t just allow you do put your sensitive existing applications/APIs behind it in an unmodified way, but also provides an architectural advantage: by externalizing access control from your application you can advance the implementation on either side independently. Thus it allows you to upgrade your access control capabilities without touching your application and you can upgrade your applications without risking changes in the access control layer.

There’s probably a lot of reverse proxy deployments in your organization today: you may be able to leverage the OAuth/OIDC capabilities that come with them to implement this scenario. When it comes to Apache and NINGX deployments, take a look at mod_auth_openidc and lua-resty-openidc respectively. These components can extend your existing (and unprotected or proprietary secured) APIs with OAuth 2.0 capabilities and your Web Applications with OpenID Connect capabilities. Things become even better when you can deploy and manage these functions as components in your microservices environment, see also my previous post about that.

Note that this “enhanced” reverse proxy (or: gateway) can work for API use cases – implementing the OAuth 2.0 Resource Server capability to verify access tokens – as well as for Web Access Management and SSO use cases – implementing the OpenID Connect Relying Party functionality to consume ID tokens. And one can deploy those capabilities alongside in a single instance possibly reusing that instance for many APIs and/or web applications.

Also note that this concept, as it adheres to standards, is independent of the Authorization Server (for API/OAuth 2.0 use case) or the OpenID Connect Provider (for Web SSO). The OAuth/OIDC Provider can be an on-premises deployment of a vendor specific product, or even a cloud-based service which allows you to lookup your on-premises applications to one of the various Identity-as-a-Service offerings through OAuth 2.0/OpenID Connect.

The microservice variant (e.g. a dockerized version of such an Apache/NINGX system) is IMO the most attractive way forward for new deployments: you can have your lean-and-man-Web-Access-Management-and-API-security-gateway-in-a-box today by leveraging mod_auth_openidc or lua-resty-openidc! Stay tuned for a follow-up post on how to deal with (fine-grained) access control in this reverse proxy deployment.

Posted in Uncategorized | Leave a comment

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…

Posted in Uncategorized | 1 Comment

Token Binding for the Apache webserver (part 2)

Last year I blogged about some experiments with Token Binding support for the Apache webserver here. Token Binding essentially secures cookies by binding them to an HTTPs connection so they can’t be used or replayed outside of that connection. Recently I went a bit further on that and developed an Apache module that implements Token Binding here: https://github.com/zmartzone/mod_token_binding.

The Token Binding module verifies the token binding material from the TLS connection and the HTTP headers. It then sets environment variables with the results of that verification so that other modules can use that to bind their cookies to the so-called Token Binding ID. As mentioned before, mod_auth_openidc would greatly benefit from such a feature, hence I’ve added support for Token Binding to release 2.2.0. Both “state” and “session” cookies can be bound to the TLS connection now.

But it is not just “co-located” modules that may benefit from the Token Binding termination that can be done with an Apache server now. There’s a work-in-progress by Brian Campbell on exposing Token Binding information to backend services via headers using the Apache server as a Reverse Proxy in front of those services. An implementation of this proposal via one of the environment variables set by mod_token_binding is as easy as using mod_headers with the following snippet in your HTTPd config:

RequestHeader set Token-Binding-Context "%{Token-Binding-Context}e"

Support for Token Binding depends on the user’s browser but it is available in recent versions of Chrome and Edge. I.e. in Chrome one can enable it by setting the flag chrome://flags/#enable-token-binding to “Enabled”.

The server-side prerequisites are: OpenSSL 1.1.x with a one-line patch, an Apache 2.4.x mod_ssl patched for handling the TLS token binding extension and Google’s token_bind library with a patch that I’ve created a pull request for. If you’re interested in prototyping this, the README should get you started. There’s a sample Docker image to get you to a quick functional server setup with all of the prerequisites listed above. Feel free to open an issue on the Github project if you have any feedback or questions.

PS: ping me for a binary package or a link to a running test instance.

Posted in Uncategorized | Leave a comment

OpenID Connect for Single Page Applications

OpenID Connect is an identity protocol that was designed not just for traditional Web SSO but it also caters for modern use cases like native mobile applications and API access. Most of these use cases have a clearly defined an preferred pattern as to which “grant type” or “flow” can be applied to it. For a good overview of that you can visit https://alexbilbie.com/guide-to-oauth-2-grants/ which presents the flow chart below:

screen-shot-2017-02-24-at-10-53-18-am

When dealing with Single Page Applications (SPAs) things become a bit more blurry since they can be seen as a mix between traditional Web SSO and API access: the application itself is loaded from a – possibly protected – regular website and the Javascript code starts calling APIs in another – or the same – domain(s). The spec, like the previous diagram, points to the so-called “Implicit grant type” for passing token(s) to the SPA since that grant was specifically designed with the “in-browser client” in mind.

Apart from some “Identerati” changing their minds about recommending Implicit over Authorization Code with a public Client for this use case – that’s probably a topic for a different post – implementing the Implicit grant type is not very popular from what I have seen in the field. Its main drawbacks are:

  • Implicit requires validation of the ID Token by the Client which means that crypto is done in the browser; this requires relatively heavy-weight libraries and more importantly, increases complexity
  • because it is not possible to keep a client secret in the browser, Implicit means using a public client which is inherently more insecure than a confidential client, see: https://tools.ietf.org/html/rfc6749#section-1.3.2

In other words, it is cumbersome, error-prone and less secure… That basically defeats the primary purpose of OpenID Connect for which the starting point is the Authorization Code grant type that allows for simple, zero-crypto (well, apart from TLS) and more secure flows. So I’ve been asked about using a server-side implementation of the Authorization Code grant type with a confidential Client for SPAs. I have added a draft implementation for that to the Apache web server through a so-called “session info hook” for mod_auth_openidc. It then works as follows:

  1. The SPA is served from an Apache webserver that has the mod_auth_openidc module loaded and configured.
  2. Upon accessing the SPA, mod_auth_openidc will first send the user to the OpenID Connect Provider and run through the Authorization Code flow using the confidential Client authentication as configured as a regular web SSO Client. It then creates a application session plus associated cookie on the Apache server for the user who can now load your SPA in his browser.
  3. The SPA can call the session info hook at any time by presenting a valid session cookie to obtain a JSON object with information such as the Access Token, the Access Token expiry, the claims from the ID Token, claims from the UserInfo endpoint etc.
  4. The SPA can extract information about the authenticated user from the session info object for its own purpose and can call APIs in another or the same domain using the Access Token in there.
  5. When the Access Token expires, the SPA can call the session info hook again to refresh the Access Token and mod_auth_openidc will refresh it using a refresh token that was stored as part of the session information.

The end result is that the SPA is using a secure server-side OIDC flow to authenticate the user and obtain & refresh an access token without requiring any crypto or security-sensitive code in the SPA itself! Let me know if you’re interested to learn more: hans.zandbelt@zmartzone.eu

Thanks to John Bradley, Mark Bostley, Brian Campbell, Jonathan Hurd and George Fletcher for their input.

Posted in Uncategorized | 3 Comments