I want my PEAP and TTLS outer handlers' AuthLog messages to include the inner
EAP identity (for both success/accept and failure/reject). The accept case is
fairly straightforward using %{Reply:User-Name}. The reject case is more
difficult, but now that I'm running the latest Radiator I can take advantage of
$p->{EAPContext}.
I see that EAP_21 (TTLS) sets $context->{inner_identity} immediately when
constructing the tunneled request, so I can easily use a PostAuthHook on the
outer handler to read it and fake it into a request attribute for FailureFormat.
However, EAP_25 (PEAP) only sets $context->{inner_identity} in replyFn after
the inner authentication succeeds. In order for it to be available in case of
reject, I'm experimenting with using a second PostAuthHook on the inner handler
to _set_ {outerRequest}->{EAPContext}->{inner_identity}. This seems to work in
my testing so far, but I'm worried that it might have unintended consequences.
I was wondering: is there an important reason that EAP_25 does *not* set
$context->{inner_identity} as soon as the identity is available (or at least
also in the reject case of replyFn)?
If yes, there's something going on that I don't understand, in which case
setting it myself via PostAuthHook could cause problems and I should consider
altering my plan. If no, then my plan is sound, but setting it in EAP_25 would
be even better and save me a PostAuthHook. :)
Thanks,
David
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
