Cached attributes

[Alan DeKok]

On Feb 25, 2016, at 9:39 AM, Jonathan Gazeley <Jonathan.Gazeley at bristol.ac.uk> wrote:
> In inner post-auth we are doing this to populate session-state from the current set of attributes:
> 
>        update outer.session-state {
>                User-Name := &User-Name
>                Inner-User-Name := &User-Name
>        }

  That will update the outer session state.  But I'm wondering why you need to cache the User-Name twice.

> Is this sufficient to ensure Inner-User-Name ends up in the TLS cache? This previous posting from Arran seems to suggest it is:
> 
> http://lists.freeradius.org/pipermail/freeradius-users/2016-January/081598.html

  If you're using 3.1...

> In outer post-auth we are doing this to copy the session-state back before acting upon the information:
> 
>        update {
>                &reply: += &session-state:
>        }

  That should cause the User-Name in the Access-Accept to be the User-Name from the inner tunnel.
 
> Here's today debug log: http://pastebin.com/ZD1nmAvC

  Which shows that the cache_tls_session module is caching TLS-Session-Data, and not much else.

  Did you edit raddb/mods-available/cache_tls to cache the attributes you want cached?

> I'm looking at line 4576 (a resumed session) where the outer post-auth is supposed to copy attributes to reply from session-state and fails to do so. The session-state list should be being populated in inner post-auth but the server seems to skip this for resumed sessions and the list is empty.

  Again, the session-state list is for the *current* authentication session, and ONLY the current authentication session.  The cache_tls_session module caches attributes across *multiple* TLS sessions.

  The session-state list is NOT cached across multiple TLS sessions.

  Stop looking at session-state.  Go modify  raddb/mods-available/cache_tls, and tell it to cache the attributes you want cached.

  Alan DeKok.