...
| Title | Attribute Authority scoping information in Metadata |
|---|---|
| Description | It seems that AARC-JRA1.4A will propose "scoping of group membership information". However, there is no element in the SAML metadata that contains the scope of an AA, therefore, there is nothing to verify the scoped membership information against. The only way today is to learn about the scopes used by an AA entity via word-of-mouth and then apply those scopes in attribute value level filtering and access control rules, maintained manually in the SP config. Obviously this does not scale. |
| Proposer | Mihály Héder |
| Resource requirements |
|
| +1's |
| Title | eduroam SP-as-a-service |
|---|---|
| Description | With eduroam Managed IdP, there is a service which takes all RADIUS hassle off of Identity Providers. There is no equivalent for eduroam SPs. I.e. a future eduroam SP either needs to set up a local RADIUS server and connect it to the NRO, or (if the NRO supports it) connectd the Wireless Controller directly to an NRO server - losing all advanced features such as VLAN assignment. For small hotspots, there is a possible additional complication if the hotspot has a dynamic IP address, which makes the interconnection via RADIUS' shared secrets infeasible. The goal of this activity is to create a self-service web portal where any prospect SP can register his hotspot (requiring sign-off by the NRO; comparable to eduroam Managed IdP) - regardless whether he has a static IP address, a dynamic one, or doesn't even know what an IP address is in the first place. The new hotspot's RADIUS connectivity is tested in real-time (e.g. using a credential from eduroam Managed IdP, a good complement to this service) and the new SP is instantly connected to the eduroam infrastructure. Where the NRO admin confirms that a particular hotspot maps to a specific realm or Managed IdP instance, the SP can even get VLAN ID assignments for his own users (that part of the use case is possibly a bit weak as an SP who does not know about setting up a RADIUS server likely also doesn't know about VLANs to begin with). For the technicalities of the uplink itself, there should be support for multiple attachment anchors (=RADIUS servers behind the web interface) because geographical proximity to the hotspot is important for performance reasons. The remaining complexity for the SP which this service will not take away is: phyiscal installation of APs, controllers, and the configuration of those so that they are providing proper local eduroam. To ensure service quality on such "no clue" SPs, it could be made mandatory to install a probe at the site so eduroam Operations can monitor the hotspot quality. |
| Proposer | Stefan Winter |
| Resource requirements | VM for web interface, VMs for RADIUS attachment anchors, a clever idea how to handle registering hotspots with dynamic or unknown IPs |
| +1's | <for others to voice their support - add your name here> |
You do not have to fill in every field, just give as much detail as you have right now if you know them.