...
| Title | Discovery for Attribute Authorities (AAs) |
|---|---|
| Description | Users can select their IdP via discovery, therefore the SP can potentially receive users from thousands of IdPs. There is no such facility for AA-s however, meaning that SP-s need to hard-configure which AAs they query. Also, query all the configured AAs for all users all the time. In GN4-1-JRA3-T1 it has been established that this is a serious bottleneck, as maximum 2-3 AAs can be queried without breaking the entire login session. A better approach is needed. The SPs need to query AAs selectively, based on either user input or some alternative means, like some VO lookup service. Otherwise all SPs will just stick with the biggest AAs like eduTEAMS basic membership service or hexaa.eduid.hu and not query alternative entities, making single-tenant AAs very unattractive. |
| Proposer | Mihály Héder |
| Resource requirements | This is a hard one. Currently there is no support for any elements of this whatsoever
|
| +1's |
| 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) connect 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. Right now, such potential hotspots are not serviceable by eduroam infrastructure. 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> |
| Title | Attribute Authority Metadata policy development for eduGAIN |
|---|---|
| Description | While for IdPs and SPs eduGAIN metadata requirements are well described, no such requirements exist for AAs. We have however already 5 of these entities in eduGAIN. It would also be a good idea to consider/define what it would mean for an AA to claim CoCo, R&S and Sirtifi support |
| Proposer | Niels van Dijk |
| Resource requirements |
|
| +1's | |
You do not have to fill in every field, just give as much detail as you have right now if you know them.