Hi,
> On 5 Sep 2017, at 16.24, Karl Gaissmaier wrote:
>
> the documentation for VsaTranslationHook is missing, also the documentation
> for VSA translation in AuthRADIUS.
>
yes, during two past years we have been adding multiple new features and
unfortunately updating documentation is a bit behind,
we will try to improve the situation and get it in sync with the code.
However, goodies/vsa-translate.cfg config has some examples.
> -
>
> I'd like to solve the problem of different MAC address representations in the
> Calling-Station-Id attribute (and also other radius attributes), coming from
> different sources from all over the world via RADSEC in the eduroam
> federation.
>
> This makes searching in loggs difficult, sigh.
>
> I can't use VSA vendor and type translations since via the RADSEC clause a
> lot of different Client vendors are proxied to me as IdP. Btw, VSA
> Translation is not (yet) implermented for RADSEC.
>
> I need a generic rewrite ruleset for the different MAC address
> representations and that's what regexps are for, like:
>
># strip delimiters
>s/[^a-f0-9]+//ig
># insert colons
>s/(..)(..)(..)(..)(..)(..)/$1:$2:$3:$4:$5:$6/
>
> similar to RewriteUser.
>
> Bingo, I found VsaTranslationHook, but only in the sources of Client.pm and
> AuthRADIUS.pm and not in the corresponding RADSEC modules, AuthRADSEC.pm and
> ServerRADSEC.pm and also in ServerRADIUS.pm.
>
> You know, AuthRadius.pm and AuthRADSEC.pm are used for forwarding packets,
> Client.pm, ServerRADIUS.pm and ServerRADSEC.pm are all receiving clients.
>
RadSec does not currently have VSA translation implemented, but I created a
feature request for it.
>
>
> Btw, the Hook in AuthRADIUS.pm is bound to the condition that VsaTranslate is
> defined, that means I can't use just the Hook alone, that's not good.
>
> AuthRADIUS.pm
> =
>if ($host->{VsaTranslateIn})
>{
>Radius::Nas::translateVSAsIn($host->{VsaVendor}, $host->{VsaType},
> $host->{VsaTranslateIn}, $p);
>$host->runHook('Transplantation', $p, $p, 0) if
> $host->{VsaTranslationHook};
>}
>
> In Client.pm the Hook is called just if it is defined, fine!
>
> Client.pm:
> ==
>$self->translateVSAsIn($p) if $self->{VsaTranslateIn};
>$self->runHook('VsaTranslationHook', $p, $p, 0) if
> $self->{VsaTranslationHook};
>
> Please make this logic comparable.
>
I created a bug ticket for this. An orignal idea was VsaTranslationHook to be
additional to VsaTranslateIn,
but of course it can be used also without.
>
> Do you have any other suggestion for the problem of different attribute
> representations coming from the same input channel?
>
If you can’t differentiate a vendor based on a source, then the strategy should
be
either to unify received values systematically or try to identify the vendor
based on
other received (vendor specific) attributes and select a business logic based
on that.
E.g. different formats for Called-Station-Id and Calling-Station-Id:
AABBCCDDEEFF
AABBCC.DDEEFF
AABBCC-DDEEFF
AA:BB:CC:DD:EE:FF
AA-BB-CC-DD-EE-FF
Called-Station-Id can also contain WLAN SSID:
AABBCCDDEEFF:SSID
AABBCC.DDEEFF:SSID
AABBCC-DDEEFF:SSID
AA:BB:CC:DD:EE:FF:SSID
AA-BB-CC-DD-EE-FF:SSID
VSA translation feature was added originally to help unifying vendor specific
attributes,
as in some (broadband) cases a wanted value is in different attributes,
e.g. (Juniper) Unisphere-Pppoe-Description="pppoe 11:22:33:aa:bb:cc” or
(Cisco) cisco-avpair = "client-mac-address=1122.33aa.bbcc”, and a hook was
needed before
to do the mangling.
BR
--
Tuure Vartiainen
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
[email protected]
http://lists.open.com.au/mailman/listinfo/radiator
