squid
squid copied to clipboard
squid-cache
RFC 6750 OAuth 2.0 Authorization Framework: Bearer Token Usage
Adds a minimal implementation of Bearer authentication scheme to Squid. It consists of three components:
-
Squid build system infrastructure for building Bearer authentication module and helpers.
-
Bearer authentication library ("module") for Squid.
-
implements the logics for squid.conf "Bearer" auth_param scheme and necessary configuration options.
-
implements the helper management and API for Bearer helpers.
-
implements logics for www-auth and proxy-auth header parsing and generating.
- An authentication helper which takes Bearer tokens needs to be implemented. No helpers are provided in this update.
At present no restriction between HTTP and HTTPS is defined by Squid. Challenges will be made for both. Admin can configure the protocol restriction on scheme challenges using auth_schemes directive. Otherwise it is left to the client to ensure adequate security on the connection it sends Bearer tokens.
- implements helper driven TTL for token caching.
Due to significant security risks with Bearer tokens the TTL is not configurable from squid.conf. Instead the helper is expected to provide a ttl= parameter from the auth backend explicitly determining the time in seconds for which each response may be cached and re-used. In absence of ttl= value the helper response is treated as already expired (a nonce).
- uses a default token scope of "proxy:HTTP" for generic HTTP proxies
NOTES:
-
At present no web browsers implement Bearer authentication in response to a proxy-authenticate challenges. However some of the common browsers should support Bearer with reverse proxies over HTTPS (Firefox and IE apparently, not Chrome).
- command line tools and AJAX / XHR implementations which allow header customization can be scripted to support Bearer.
-
This is only a minimal implementation, emitting only the realm= and scope= parameters to clients.
- The key_extras mechanism can be used to pass extension client request parameters to the Bearer helper.
- Extension parameters in Squid responses is not supported.
-
Bearer authentication to cache_peers is not supported explicitly.
- implicit support exists with login=PASSTHRU, which may be used to relay Bearer tokens for SSO to multiple proxies.
Since this PR appears to be stuck on our disagreement of LRU behaviour: That "unless" case is now being checked for and objects not added to the LRU when they would overflow its memory limit. I have added a build option (-DSQUID_LRU_STRICT=1) to enable builds to strictly obey LRU algorithm behaviour if the admin wants to use that instead of having some random entries silently turned into nonces.
Note that this change is likely to have the largest effect on TLS/SSL certificate generator helper responses, which use this LruMap. Currently those certificates would be added to the LRU and purge old(est) entries, now they will not be stored by Squid at all.
Hello, Do you have any news on this PR? We would also like to play with JWT and Squid (same use case than in http://squid-web-proxy-cache.1019090.n4.nabble.com/Bearer-Authentication-in-Squid-3-5-28-4-2-td4686341.html). Thanks!
It is still stuck on the LRU performance issues and other work has taken precedence for now. It should be usable - but as always for alpha code, test first. I will shortly rebase the branch so it gets all the security and bug fixes from current Squid-5.
Amos: PR 30 blocked because the reviewer wants author to fix bugs in pre-existing code.
[I am responding to the above squid-dev statement here because the statement and this PR have nothing to do with the stalled PRs discussed on that thread.]
If you think this PR is blocked incorrectly, please discuss your objections in the corresponding change request. In general, requesting old bug fixes can be in the PR scope. This specific PR was active too long ago for me to remember exactly what happened here, but I am willing to resume any old discussions you want to resume. As you know, the ball is on your side here.
Closed all discussions around changes to src/base and src/ssl code. Those parts are unrelated to Bearer and have been handled separately by other PRs.
It looks like I forgot to update the PR labels after the review, and the PR had a stale S-waiting-for-reviewer label. I fixed that.
yadij added the S-waiting-for-QA label This PR is blocked waiting for PR #774 to be merged.
I removed S-waiting-for-QA because this PR does not wait for the QA team action. It may be waiting for another PR (among other things), but we do not have a label for that. We can add such a label (e.g., S-waitting-for-another-PR). It is also possible to mark this PR as "draft PR" until its prerequisites are satisfied -- GitHub supports marking draft PRs natively these days, and Anubis has been updated to recognize GitHub markings.
Status update: The branch has been updated, based on latest v7. It builds.
TODO:
- testing that it works as intended.