eduroam Development VC 2016-08-09, 1530 CEST
Side nodes:
I don't like the lifesize experience so far (a lot of noise, client problems that should have been in the past). I miss chat. This etherpad doesn't have everybody's focus, so it's not really interactive along with the meeting.
Attendance:
    Stefan Winter, RESTENA
    Paul Dekkers, SURFnet
    Marko Eremija, AMRES
    Žilvinas Vaira, LITNET
Philippe Hanset, ANYROAM
Tomasz Wolniewicz, PIONIER
Ingimar Jonssson RHnet
Juha Hopia, Funet
Maja Gorecka-Wolniewicz, PIONIER
Hideaki Goto, Tohoku University / NII
Scott Armitage, Loughborough University
Pedro Simões, FCCN 
  Louis Twomey, HEAnet
Apologies:
    Miroslav Milinovic, SRCE
    Mike Zawacki, Internet2
Agenda:
    
    1. Welcome, Attendance, Agenda Bashing
    2. Silverbullet administration UI
       (including points raised by Philippe in his mail)
       
       I don't think my audio is working: I'd say that scalability on the RADIUS part is trivial, and we should have EAP terminating IdP's all over the world, regardless of the web-interface running on just one place (if scalability on that level is hard).
       (not sure if anyone checks on these notes during the VC ;-))
       If the eduroam CAT app doesn't change much, it would still accept configuration files from other endpoints, so then it's only the IdP-finding code.
       
       (microphone audio isn't working, I can hear stuff :-P)
       I think we should keep the modulatity in mind, and then we could be fine: then it will remain scalable.
       
       The discussion was rather about deployability of the solution as a whole in a separate instance. This goal can be achieved by running a copy of the entire codebase. There are concerns about this codebase becoming too big and monolithic (and difficult to keep in sync if deployed). 
       These concerns are certainly valid - splitting the code base is probably a good idea. The splitting point would come natural on the diagnostics vs. configuration generation part. This reduces CAT to its core functionality, and removes much unneeded code for someone who merely wants to deploy CAT for Silverbullet purposes.
       Tomasz also notes that there is a hotfix branch which can be used to stay in exact sync with deployed production on cat.eduroam.org.
       EAPlab is also a code base that could be integrated; if the code is being split between diagnostics and and installer generation then this one would end up in the diagnostics part - again leaving that code base out of the concern of Silverbullet deployments.
       
       I would make a seperate page for silver-bullet kind of configuration, and set proper values in the normal admin pages (set things to TLS, and set the certificates correctly and so forth).
       
       We need to think about global support here; leave that at the actual institutions preferably (and keep termination of EAP indeed relatively local and give insight in the appropriate logging to NRO and IdPs for their users).
       
       Why multiple CAs; one CA that issues server certificates for woldwide use to validate EAP is fine, isn't it. OR the usernames should be somewhat local, so that your support can be done by the right parties, eg. the EU users should be uuid@tls.eu.eduroam.net or something, and maybe even @tls.nl.eduroam.net if we think we should have one in eg. NL. I think Tomasz just mentioned a similar thing.
       
       OCSP still doesn't work for TLS clients, right. It actually stalls the client on Mac OS/iOS.
       So, no microphone :-( but the client stalls authenticationf or about 15 seconds if there's OCSP links in the certificate, because Apple is silly, and the client is unable to contact the OCSP servers when there's no connectivity (because authentication is still taking place).
       So Stefan referred to questions around this.
       It's actually addressed inn one of the updates, but made me think that OCSP is silly anyway! Because there's no connectivity, so you can't check... I think it's solved in newer releases. Just.
       Also: OCSP in general can be ignored: if the OCSP servers cannot be reached, the client continues. Otherwise a denial of service would be very easy. (And this green color is indeed Paul ;-))
I agree with Scott; it does give more support questions to NRO level over IdP level. One more thing: suddenly the performance and availability of outside-IdP RADIUS infra is getting more important: right now, if the external connections would fail, only visitors would not get online...
       
       Re. CAT support; we've had a few institutions that just didn't know how to get the right certificates in. Or are confused about the configuration options.
       
       IMHO, EAP termination should be done in each country where the virtual IdP operative body exists and the users' credentials exist (virtually). This will mitigate the complexities about incidents handling (the authorities would need the log of AuthN). The UI may be centralized - it is rather recommended because of the updating problems. (You could remember the upgrading difficulties in SAML fed.)
       FYI, we've faced a difficulty with our centralized IdP in Japan about the sync of server certificate across multiple RADIUS servers. It would affect to the scalability (in maintenance). Having some replicas is strongly recommended for higher availability and scalability (of AuthN) reasons.
  Philippev (sorry, I'm color blind and those Etherpad colors are not easy): It is becoming common for organizations  (especially small ones) to rely on Google or Microsoft for their entire Directory Services. Do we intend to support OAuth in the Silver Bullet ?
  Hideaki -> Philippe: If the system will support visitor accounts, the collaboration with SNS accounts etc. should be attractive. But, the visitor support should be provided as an independent module. 
  This is not for visitor support but for insitutions using Google-Identities as their main Directory Services. They can's do SAML they can only do Oauth!
But you can make an IdP that supports this, can't you? SAML IdP that checks OAuth credentials, and then authenticates you to silver-bullet.  
  Yet more work ;-) Everything can be done with enough hacking time.
  This has been done before ;-) (I think, at least I know I have one other application that needs this, I should check with our fed. people but I'm quite confident this is easy) (but you're right)
  
  
  Louis > eduroam CAT is great, it has made my life easier for sure. But successful services at some point need support perhaps. When my clients have issues with something involving eduroam CAT they will talk to me rather than use the mailing list. It's a user education issue to one extent, a resource challenge too.
  Hideaki -> Louis: That's not limited to eduroam CAT. Even with the raw eduroam, people's complaints go to twitter :<  We need to show a correct and clear path to the end-users. (GeGC matter?)
  
    3. AOB
  • No labels