Applying the same rule to multiple values in an attribute/config value

Alan DeKok aland at
Mon Feb 11 18:59:08 CET 2019

On Feb 11, 2019, at 11:41 AM, Stefan Paetow <Stefan.Paetow at JISC.AC.UK> wrote:
> So, we're reviving the old RFC7542 chestnut because we've found that there is appetite for it. The basic policy for it is done, but a question was raised about the capability to apply the functionality to multiple realms. 

  RFC 7542 doesn't allow for multiple realms in an NAI.  Section 3.3.1 explicitly recommends against this:

   In RADIUS-based environments, the use of decorated NAI is NOT
   RECOMMENDED for the following reasons:

	... lots and lots ...

> The basics are this:
>  if (&request:User-Name =~ /([a-zA-Z0-9\.-]+)!([a-zA-Z0-9\.-]*)\@(.+)/) {
>    #  Store the three parts of the User-Name, store the original User-Name too
>    update control {
>      RFC7542-User-Name := &User-Name
>    }

  The RFC 7542 format is "utf8-username at utf8-realm".

  The "utf8-realm" portion is pretty much a valid DNS domain name.

  The "utf8-username" is opaque, and has no meaning outside of the "owning" domain.

  As for the FR config ,the whole rewrite / suffix / re-write back thing should be avoided.  If you are going to mark up the "utf8-username"  portion with routing information, it's best to modify the "suffix" module configuration.

  i.e. pick out the realm you want to use, and look that up.  Don't munge the User-Name.

> The question now is the '$policy.rfc7542_suffix' bit. This is currently just defined as a simple value, i.e. 'blahblah.realm'. If we were to define it as a multiple value (semicolon-separated), would it make sense to use a foreach() loop across it, turn each entry into a variable and just check if the value is contained in the regex?

  I'm not sure what you're trying to do here...

> The worry I have here is that there's a lot of processing to do, a lot of looping, and if the powers that be (Alan, Arran, Matthew et al) have a better suggestion, I'd love to hear it. Please remember, this is for 3.0.x, with looking at upstreaming this to you guys to give FR RFC7542 capabilities.

  FreeRADIUS already supports RFC 7542.  That RFC largely documents prior practices going back to 1996.  It doesn't really define anything new, other than saying "don't use decorated NAIs".

  So I'm not clear what you're doing here, or why.  Why is there a need to mangle the User-Name?  Is it to add realm routing information?

  See RFC 7542 Section 3.3.1 for reasons why explicit routing paths are problematic:

  Alan DeKok.

More information about the Freeradius-Users mailing list