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

[John Douglass]

Awesome Phil, that was exactly the kind of example that is awesomely 
useful :)

I see that by default the username is stored along with this.

[peap] Adding cached attributes to the reply:
     User-Name = "jd187"
     Cached-Session-Policy = "vlan=316"

Do you know exactly how the session resumption is determined? In the 
debug output I see:

[peap] eaptls_process returned 3
[peap] EAPTLS_SUCCESS
[peap] Session established.  Decoding tunneled attributes.
[peap] Peap state TUNNEL ESTABLISHED
[peap] Skipping Phase2 because of session resumption
[peap] SUCCESS

Would ANY authentication for "jd187" get the cached applied or does 
freeradius have some concept of uniqueness when it comes to different 
sessions by the same user?

The documentation (in eap.conf states):

#  The cache contains the following information:
#
#  session Id - unique identifier, managed by SSL
#  User-Name  - from the Access-Accept
#  Stripped-User-Name - from the Access-Request
#  Cached-Session-Policy - from the Access-Accept
#

#
#  On session resumption, these attributes are copied from the cache, 
and placed into the reply list.

So I am assuming that session id is some combination of attributes that 
uniquely describe a single particular connection/authentication (I would 
hope). In my environment, if the cache is purely based off username, 
this would break our entire system.

Figured I would bring this to see if anyone has any insight on how this 
session ID is created, managed, and applied to the subsequent 
session/authentications. I'll be running some experiments on this early 
next week but figured I might ask if anyone has any ideas on how/when 
the caching is applied (as configured by the eap.conf variables).

Thanks in advance,
- John Douglass, Georgia Tech

On 04/20/2011 07:18 PM, Phil Mayers wrote:
> 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.
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html