Welcome / Agenda Bashing
CAT code (CAT / Managed IdP / Managed SP)
CAT API questions/remarks
There are multiple identifiers for institutions
problem: NRO cannot identify their own IdPs by the identifiers they assign themselves - only foreign identifiers present
see: https://github.com/GEANT/CAT/issues/226
SW to check the DB VIEWs whether the NRO-provided identifiers are now visible to CAT; and expose them in DATADUMP-FED subsequently
SW to investigate the DATADUMP-FED API call - incorrectly delivers data from other federations
TWOLN to enable the APIKEY for Arnoud in cat-test to verify on current code => Bug not more present in CAT 2.1
update on geteduroam.app and CAT handling of external vs internal identities, realms and insight on how to attain harmony/consistency betwixt them.
different realms for inner and outer IDs are a really bad idea. Difficult to find use cases for it.
-> One possible use-case we thought about, is: How to prevent users from not using CAT?. Obviously, using EAP-TLS could be one way, but adds more complexity on the IdP side. Another (dirty?) solution, could be to set an outer realm, that doesn’t match the inner realm (outer: anonymous@eduroam-unversity.tld / inner: john.doe@university.tld). Like so, users not using CAT, that just click on eduuroam on Windows, enters email/password, and click on “Accept certificate” blindly, won’t be able to connect anymore
EK/CANARIE : We are utilizing anonymous outer IDs with specific values we assign and I have a sample config for MSFT NPS to enforce the outer ID (e.g. anonymous584129@institution.tld) for auth to proceed. This is ‘security by obscurity’ at its finest but it does mean we can drive towards trying to make CAT profiles mandatory. Hit me up on Slack to discuss details further!
CP/CANARIE: This technique is inspired by DFN and eduroam.de’s technique they applied. The anonymous######@inst.tld means that we can make informed observations within our NRO’s realm (.ca) as to which devices were truly set up in an optimal fashion. It is possible to hand craft the config of course but you have to try REALLY hard to circumvent or mirror the application of the outerid.
Like Ed mentioned, we’re happy to share the technique and experiences. It hasn’t been hard to set the ##### elements (it’s arbitrary) however it’s more difficult to insist on the profile in place on their own volition. What can happen is an NRO can configure RADIUS realm rules in the RADIUS proxy that only traffic with outerid’s can pass (within their realm). This has not been applied yet. CP
CAT doesn’t currently allow different realms there.
geteduroam doesn’t have an issue so long as it consumes config files generated in CAT
Issue can arise only if config is generated from outside CAT.
OS-specific mangling would ideally in sync CAT-side and geteduroam.app-side - let’s make sure it is.