On 13.12.2016 12.32, Hartmaier Alexander wrote:
I strongly advice to get context like this:
my $context = $p->{EAPContext};
Ok, I've changed our hooks to use this again like before, seems to not
make a difference both ways.
If you get context from $p, it does not matter if, for example,
EAP_UseState was enabled or note. It's easier and more reliable to get
it from $p.
Can you please add this to the reference guide?
Good idea. I think this discussion means we need to create an example
how to keep custom data that persists across resumed authentications.
The session_reused() call will tell this.
I've added logging and all resumed sessions are missing the reply
attributes we're adding with our hooks (mainly vlan id).
Does this check signal a successful resume or just the attempt to do so?
I am not sure if this has been strictly defined by the OpenSSL API. To
be sure, I would only check this after the TLS session has been
accepted. I'd check first that, for example, PostAuthHook result is
ACCEPT before continuing. Radiator only does this check for TLS sessions
that have been successfully established.
It seems the reply attributes added by the hook code for the first,
non-resumed authentication aren't stored in the EAP context.
Please advise if it is required to do that manually or if this is a bug
in 4.17.
You need to do it manually. This is why it got a special mention in the
release history.
What you could do is to write your custom attributes in the
resume_context when the authentication was successfully and
session_reused() indicates it was not a resumed. See
eap_save_resume_context in EAP.pm for an example.
The next time around when session_reused() indicates TLS did resume, you
can once again get the resume_context like above, but now just verify
the values are there and then use them.
When the next Radiator release is done, see the change history for the
possible helpers that you could consider using in your hooks instead.
One of the helpers could be the resume count I wrote about earlier.
For now I'd use the session_reused() check with the Hook.
This works, but we're not sure if it means the resumption was successful
or attempted, see above.
As I mentioned above, I would only check this if the result indicates
authentication success.
What comes to reliably saving state information across server restarts
and reloads, that is not currently supported. Saving the resume context
required by Radiator is doable. SQL, Redis and similar could be used for
this. Storing and and reloading TLS library's TLS sessions seems to be
possible, from a quick look at the openssl docs. As a downside, doing
this would not still help with FarmSize without more work there.
If you need to split load, maybe you could consider a front end proxy
that uses, for example, AuthBy HASHBALANCE to forward messages to a
number of workers where each worker is bound to its own port, as opposed
one port with FarmSize.
Thanks,
Heikki
--
Heikki Vatiainen <h...@open.com.au>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
_______________________________________________
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
