2010/1/26 Sam Crawford <samcrawf...@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
_______________________________________________
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
