On Oct 2, 2016, at 7:32 AM, Stefan Paetow <Stefan.Paetow@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@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@intermediate.realm. Authenticate locally at 'intermediate.realm'.
Yes.
Scenario 2: Outer = realhome.realm!username@intermediate.realm. Route on to 'realhome.realm'. Authenticate locally at 'realhome.realm'.
The key here is *who does this*. If you have "realm1!user@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@realm1". At which point the AAA server for "realm2" can forward the packet to "user@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.