Routing new RFC7542-style realms

[Alan DeKok]

On Oct 2, 2016, at 7:32 AM, Stefan Paetow <Stefan.Paetow at jisc.ac.uk> wrote:
> I'm looking at how to configure FreeRADIUS to be able to handle
> RFC7542-style usernames (i.e.
> "realhome.realm!username at intermediate.realm").

  Those were defined long before RFC 7542.  It just tried to fix some long-standing issues.

> At the same time, that same
> FreeRADIUS server must be able to handle the standard RFC4282 NAI, and
> authenticate NAIs that are local to it. The inner identity obviously
> remains the standard NAI for the real home realm, unless someone else has
> a better idea:

  The inner user-name is always either unqualified ("bob'), or qualified with a local domain name.

> Scenario 1: Outer = username at intermediate.realm. Authenticate locally at
> 'intermediate.realm'.

  Yes.

> Scenario 2: Outer = realhome.realm!username at intermediate.realm. Route on
> to 'realhome.realm'. Authenticate locally at 'realhome.realm'.

  The key here is *who does this*.

  If you have "realm1!user at realm2", then the packet MUST be routed by third parties to "realm2".  Because it is the domain name which appears after the "@".

  "realm2" then notices that the user portion is in a special format.  A format which it understands.

  The AAA server for "realm2" can then decompose the "realm1!user"  string into "realm1" and "user".  And then re-compose it into "user at realm1".

  At which point the AAA server for "realm2" can forward the packet to "user at realm1".

> Scenario 1 works just fine... But Scenario 2?

  Magic... lots of magic. :)

> I can define a prefix/suffix that works on the bang (!), so I can handle
> one or the other... But not both?

  The existing "realm" module isn't smart enough to do this kind of double lookup.  Though I suppose it shouldn't be too hard to add (hint hint).  Just have it check for a realm, and if the realm is local, do *another* check for realm on the user portion.

  It can be done manually in "unlang".  But it means replicating the logic in rlm_realm, and re-writing it unlang statements.

  Alan DeKok.