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

[Stefan Winter <stefan.winter AT restena.lu>]

Hello,

> This can be achieved in at least 2 ways:
> 
> 1. cat.eduroam.org implementing a per-institution sub-CA and crl
> 
> 2. an institution-hosted, auto-upgradable CAT instance implementing its
> own sub-CA and crl
> 
> Solution 2 seems more robust and scalable to me because your radius
> server does  not depend on a remote crl and you decentralize computation
> for generating certificates on the fly.
> 
> This way users does not even need to input username or password.
> 
> Is anybody already working on similar paths?

That's a very good train of thought.

Option 1 would mean we concentrate lots of valuable keying material on
our servers. I wouldn't want to be responsible for the proper operation
and security of someone else's CA; it's already enough that we have
/one/, and our own, for client credentials in our system.

But option 2 certainly is very appealing. As you know, our code is on
GitHub and can be taken and used by anyone. In fact, one NREN in Europe
is already doing this in a prototype stage; they want to use the
codebase as a backend, steer it by the API, and put their own frontend
on top of it. That front-end will authenticate users with SAML and hand
out eduroam credentials if the user attributes match the system's
expectations.

And another NREN is just asking about options to scale usage of the
system beyond the 10K users we foresee in our own hosted solution.
Obviously, one way of getting around that is again to deploy their own
instance.

So, yes, people are working on this. With a bit of luck, someone might
come up with an Ansible script or Docker image of the software.

If nothing else, I can also say that we ourselves have a scripted
installation for Continuous Integration purposes. We use Scrutinizer,
and have a .scrutinizer.yml script which installs a CAT instance,
generates institutions and profiles, generates installers for all
platforms, and validates if the generated installers are within expected
parameters. That happens on every single push of code.

For version 2.1, we have expanded the checks to generate all installers
*in all available languages* to catch some of the "wrong quotation marks
lead to broken Python" etc. problems which were reported here lately.

Given the apparent popularity of the Managed IdP feature set I think I
will further expand on the automated testing to also verify Managed IdP
cert and installer creation.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

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

Attachment: signature.asc
Description: OpenPGP digital signature