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:
- arbitrary incoming token formats and protocols e.g. OAuth 2.0 access tokens, cookies, JWTs, legacy tokens in headers etc.
- arbitrary outgoing token formats and protocols e.g. OAuth 2.0 access tokens, vendor specific or legacy cookies/tokens, JWTs etc.
- 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
Happy STS-ing with mod_sts and let me know if you have questions, suggestions or need support.