Varnish extensions for SSO support

[Laurence Rowe]

2010/1/26 Sam Crawford <samcrawford at gmail.com>:
> Hi Laurence,
>
> Caching personalised content that uses cookies for identification is
> already possible with a bit of VCL magic. But, this is cached based
> upon a hash of their cookies, so if they open lots of browser sessions
> (with different cookies), then you get multiple copies of the content
> per user, which is a bad thing!
>
> So yes, if we could effectively put an SSO agent (that could validate
> tokens/tickets and extract the authenticated username) then you could
> cache on a per user basis (which would also be a use case I'd be
> interested in). Or, perhaps even more preferably, cached based upon a
> group or role basis (providing that data was made available).

Moving content authorization to the network edge is the interesting
one for me. A mod_auth_tkt cookie is essentially:

    <md5_digest><timestamp><userid>!<token_list>!<user_data>

The digest is created by hashing the ticket contents together with an
optional ip address and a shared secret. It is validated on every
access by the webserver by validating the digest with the shared
secret.

One obvious option for the token_list is to store a user's groups or
roles. In vcl_recv, after validating the ticket, you would unpack the
data and set X-Remote-User, X-Auth-Tokens, X-User-Data. A user might
then have:

    X-Remote-User: jbloggs
    X-Auth-Tokens: user:jbloggs,role:Editor,group:LondonOffice
    X-User-Data: Joe Bloggs

A page of content could be served by your appserver with a header:

    X-Allowed-Tokens: role:Manager,group:LondonOffice,group:BerlinOffice.

In vcl_deliver you just need a routine that checks that
req.http.X-Tokens intersects with resp.http.X-Allowed-Tokens. If not,
it just return an unauthorized page.

Laurence