Cached attributes

[Alan DeKok]

On Feb 25, 2016, at 7:29 AM, Paul Seward <Paul.Seward at bristol.ac.uk> wrote:
> 
> On 25 February 2016 at 12:19, Jonathan Gazeley <
> Jonathan.Gazeley at bristol.ac.uk> wrote:
> 
>> 
>> - whether they have been suspended for being naughty
>> 
> 
> This is the one which means we're reluctant to cache the vlan attribute
> between authentications.

  In 3.1, you can update the cache remotely, especially if you use redis or memcached.  That can be used to delete existing sessions.

  Or, use CoA, and if the server receives a CoA, delete the cache entry for that user.  That way you can nuke the cache by sending a CoA or Disconnect-Request to the server.

> To make the decision about whether or not the user needs to be "contained"
> we need their actual username (ie from the inner) and not whatever they
> happen to tell us their username is in the outer.

  Exactly.

> Which is when we have a "resumed" session which doesn't run the inner
> (because it's being resumed from the tls cache) we're failing to do the
> right vlan calculations.

  If you cache the Inner-User-Name,  and key off of that for all VLAN decisions, you should be safe.

  e.g.

1) authenticate user, update Inner-User-Name

  a) cache this

  b) in post-auth, send VLAN based on Inner-User-Name

2) on resumption

  a) get Inner-User-Name from the cache

  b) in post-auth, send VLAN based on Inner-User-Name

  Alan DeKok.