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

[Alan DeKok]

On Feb 11, 2019, at 5:48 PM, Stefan Paetow <Stefan.Paetow at JISC.AC.UK> wrote:
> 
> Hang on Alan, 
> 
> In 2016 you wrote this:

  Quoting my own words against me.  That's a winning tactic. :)

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

  OK.

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

  The Suffix module doesn't rewrite the User-Name, or the EAP identity.

  There's also the issue that re-writing User-Name without changing EAP identity is bad.  Most servers (including FreeRADIUS) will reject such packets.

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

  That's for non-EAP authentication, unfortunately.

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

  "foreach" doesn't work on configuration items.  You shouldn't need it though.  The idea being intermediate routing is that each stage only takes care of *one* realm.  It's not really good to say "here's a list of realms, pick one".

  IIRC, 802.11u does that for realm selection, but it's rather a bit different.

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

  OK.  But I'm still not clear why there's a list of realms separated by semicolons.

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

  Sure.

  Alan DeKok.