User-Name return glitch in FR 3.0.17?

[Alan DeKok]

On Apr 24, 2018, at 7:29 AM, Stefan Paetow <Stefan.Paetow at JISC.AC.UK> wrote:
> Eh? Sorry Alan, but it does have one! See the quoted bits:

  Sorry, I didn't see that.

> This is the problem. There are *two* User-Name attributes now. 'root' came from the inner-tunnel as expected. The User-Name of '@idp.test.assent' is unexpected.

  It likely comes from the outer session, and is the anonymous identity sent in the EAP Identity packet.

  The issue before 3.0.17 was that it was *supposed* to add the outer request User-Name to reply:User-Name.  It did, but *not* if there was also an outer request Stripped-User-Name.

  The fix in 3.0.17 was to always copy outer request User-Name to outer reply User-Name.

  I suspect your rules added User-Name to the reply when it didn't already exist.  Now that it exists in 3.0.17, your rules run into issues.  That's really the main issue here.

  The secondary issue is that you probably want the session-state attributes to over-ride the EAP module copying the request User-Name to the reply User-Name.  That isn't done right now, because the EAP module adds the reply User-Name in the "authenticate" section, not in "post-auth".

  The fix to that is simple:

post-auth {
	if (session-state:User-Name && reply:User-Name && request:User-Name &&
    		(reply:User-Name == request:User-Name)) {
		update reply {
			User-Name !* ANY
		}

		... copy session-state to reply ...
}

> What I *would* expect is to see the flow in FR 3.0.15 in FR 3.0.17.

  3.0.15 would sometimes not send a User-Name in the reply.  That was wrong.

  It worked for you because you *manually* added a User-Name.  But that shouldn't be necessary.

  Alan DeKok.