On 2016-12-13 14:45, Heikki Vatiainen wrote:
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.
I've removed EAP_UseState from our config since everything works as
before. Can the nested auth of PEAP-TLS cause this in conjunction with
the state ID generation?
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.
Thanks!
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.
Our PostAuthHook already has this at the very top since the beginning.
Is this the correct way to check?
my $p = ${$_[0]};
my $rp = ${$_[1]};
my $result = $_[2];
my $reason = $_[3];
return
unless $$result == $main::ACCEPT;
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.
Yes, but it only points to EAP.pm which didn't change much since 4.16.
How should they be persisted after writing to $context?
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.
So basically write to and read from
$context->{eap_resume_context}->{foo} instead of $context->{foo}?
As this doesn't use an accessor method I'd like it at least documented
somewhere so we can be sure it doesn't break without notice on one of
the next updates.
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
Cheers, Alex
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
_______________________________________________
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
