Example of how to use caching (Cached-Session-Policy)?

[Phil Mayers]

On 04/20/2011 10:13 PM, John Douglass wrote:

> What exactly am I supposed to store into the attribute
> "Cached-Session-Policy"? Is this referring to a policy within the file
> "policy.conf" that will run and extract attributes according to the
> function there or is it something else?

Based on a quick glance at the source: You store anything you want, and 
then you write policy to act on it. The server doesn't do anything 
specific with the attribute beyond storing it and allowing you to read it.

For example:

post-auth {
   if (reply:Cached-Session-Policy =~ /group=(.+),building=(.+)/) {
     update reply {
       My-Vlan = "%{sql:...some sql based on the %{1} and %{2} values}"
     }
   } else {
     # do your policy work, then
     update reply {
       Cached-Session-Policy := "group=staff,building=admin"
     }
   }
}



>
> The notes also say:
>
>     # You probably also want "use_tunneled_reply = yes" when using fast
>     session resumption.
>
> And I have turned that on everywhere I could find, but it doesn't appear
> to be even saving the 1st values of Tunnel-Private-Group-Id.
>

Hmm.

AFAICT from the source, the common TLS code (used by EAP-TLS and 
PEAP/TTLS too) will only cache User-Name, Stripped-User-Name and 
Cached-Session-Policy. Arbitrary valuepairs aren't stored in the cache.

In some respects, this makes sense - you might set the VLAN based on the 
switch they're on; you need to re-calculate those values because you 
can't guarantee that session resumption takes place on the same switch.

Basically, if you set reply variables based on some kind of lookup (e.g. 
SQL) the safe option is to store the "key" in Cached-Session-Policy, 
then set the reply variables (vlan etc.) in post-auth based on the key.