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

[Stefan Paetow]

Hang on Alan, 

In 2016 you wrote this:

> > 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 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".
:
:
>    
> 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.

So, this is what we've done in the end.

> > 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:

It doesn't explicitly forbid it, it recommends against it (and I totally get the reasons why this should be avoided). However, Section 3.3.1 of the RFC uses exactly that kind of example, but explains that the username must be rewritten to the standard NAI format sans decoration. That was what I still had to figure out (or try and get away with non-standard unlang processing to make sure that it didn't start looping). 

> 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.

Ok, I'll look at that again and see what can be done, but I'm not sure whether that's allowed if the EAP identity is originally set to 'home.realm!anonymous at another.realm'. Suffix doesn't rewrite that, does it?

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

There was no objection in 2016, but I'll take your point. :-)

> > 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...

Ok, the way the current unlang is written is that it uses *one* value in an if statement. If I now provide a list of values i.e. the configuration option rfc7542_suffix is defined as say 'realm1.org;realm2.net;local.realm', how can I do a simple "check the regex against what's defined in that list"? Of course if the 'suffix' module configuration allows me to work with the realms I have defined in proxy.conf, then the point is moot, but if not... I'll have to construct a loop of sorts, no? But does foreach() work on configuration items? I don't think so?

>      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?

The original User-Name has 'routing information' (i.e. 'home.realm!anonymous at another.realm'). The EAP identity has the same set (because it's an EAP conversation). We 'munge' the User-Name to 'anonymous at home.realm' to get suffix to route it correctly. Then, to avoid the 'Identity does not match User-Name. Setting from EAP identity' error message, we restore the User-Name to what it was before routing, i.e. 'home.realm!anonymous at another.realm'. 

On the target system, the same happens, but at that point, the target system identifies that 'home.realm!anonymous at another.realm' is destined to itself and everything in the rest of the conversation stays the same.

One thing that I *have* forgotten is that RFC 7542 says that the inner identity MUST NOT be decorated. That's what I failed to do... I'll have to revisit this.

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

I am aware of these reasons, yes. We know they are problematic, but again, given that this is the only way to say 'You MUST go there first' (which stems from a FR conversation in 2016 where I asked this and was told to read the RFC in question and then started a discussion on the list about it), this is what we have...

I hope this helps? 

Stefan Paetow
Consultant, Trust and Identity

t: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: stefanp at jabber.dev.ja.net
skype: stefan.paetow.janet

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.