The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Stefan Winter <address@concealed>]

Hi,

>   So indeed the installer has a problem. We did not think of a situation
> where an IdP would be using inner identifiers like user@staff
> We have been asked many times to add some identifier checks and we have
> two new options on that - the admins now can test if the realm in user's
> identifier matches the realm provided in the configuration or even
> prefill the username field with "@realm". With no options set, we still
> run some basic checks like multiple @ signs or a dot immediately after @
> or no dot in the realm part. This last test causes the error in Paolo's
> case. It looks like we have no choice but to drop this one test as it
> may be doing more harm than good.

Just for the sake of making an argument, I'd like to point out that
something@staff is not a valid user identifier in the sense of the
IETF's "Network Access Identifier (NAI)" RFC. Nor is something with two
@@ signs in it or an @. .

If this kind of identifier is used /without/ enabling outer identity
with a correct NAI, it leads to actual breakage when roaming. I'm
assuming that this IdP has thus turned on outer identities, making this
internal use "okay".

So, I think in general we have a point in testing for these conditions.
But since reality shows us that these identifiers are in actual
deployment, and our sense for standards-correctness is getting in the
way of real deployments, I'm okay with removing the check.

Greetings,

Stefan

Attachment: 0xC0DE6A358A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature