Minutes eduroam meeting, Part 1: task internal
State of play of sub-tasks. Where are we, what's blocking where, and how to resolve it?
eaaS (IdP and SP)
- concentrated on IdP function
- we have the eaaS road map
- eaaS IdP pilot planned to start in Jan 2017
- SW explains/demoes how the current admin and user interface works
- Do we consider e-mail as a safe method for sending token and import password to the user? Yes (conclusion after a long discussion). Alternatives:
- Do not specify transport (current approach)
- send via email (good enough for pilot phase, change implementation to allow sending to email recipient)
- send via secure messengers (e.g. Facebook messenger). More secure than email! Would need to work out how to use third-party APIs for messenging.
- Token issuing and consumption: several approaches possible
- one issued, one to use (current approach). Issue more if user has more than one device.
- one issued, use for max. number of installs
- one issued, use for max, amount of time, arbitrary installs
- We have a running prototype; pilot will be started in January 2017
- will use real eduroam uplink
- use pilot testers to validate assumptions and make wise choices in the above points
- We need a final name, ideally without "as-a-service" nor "Cloud" in it
End-User Diagnostics
- SW explained monitoring architecture, what we can already monitor, and what's missing
- none of this is currently visible or usable for end users
- new tool gathers info from the monitoring sources and presents in a "very simple" way to end users.
- Tell them what they should do if they can do something themselves.
- or tell them that they can't do anything but wait; but inform via backoffice channel the one who can do something
- development work did not start yet, eaaS currently consuming bulk of time
- plan is to develop throughout 2017, with a pilot available Jan 2018
- suggested changes to monitoring infrastructure: duplicate monitoring hosts (several countries, anycasted or with mutliple client/server RADIUS definitions?)
- Probes: suggestion to make hardware-independent; maybe better base platform is OpenWRT rather than Raspberry Pi?
- Action on MM: find out the hardware reqs for eduroam probes. Is the major limitation speaking against OpenWRT that the file system space on OpenWRT devices is typically too small?
Minutes eduroam meeting, Part 2: Campus IdP and eduroam-as-a-service IdP