Conveners:Niels van Dijk, Arnout Terpstra, Mads Petersen
Abstract:Some topics and challenges in Federated Identity Management are specifically interesting to Hub+Spoke Federations. Last year, a successful separate H+S side meeting was organised that can be repeated again this year, albeit in another form (since there is no room for another side meeting). Instead, come to this session to discuss both technical and non-technical stuff concerning H+S Federations.
Tags: Hub-and-Spoke Federations, Federation Policy
Notes
Niels van Dijk: Surfnet (NL): stuff that we're working on
Proposal: questions, discussion
Bullet points:
1 hub&spoke <-> mesh
2 hubs + education?
3 identifying institution
Aud: hub&spoke federations: should keep the acronym. 'hub&smoke, full mesh' (haha)
Aud: beginning to get the sense what h&s federations are not
Need to do some contract. Process for each federation.
Lucas: if you’re h&s fed and not publishers that want to offer services to uni users...link term attributes. Publishers don’t have contracts with all the org. how do h&s fed. Deal with these features?
Niels: not a feature but an attribute.
Mads: slides: WAYF hybrid architecture, thinking of changing the architecture of WAYF.
'This is a full mesh'...
Scoping element: I’m not going to talk to the hub but the BA? Not a good idea --> you have to have a proxy. -> The 'hub scoping'
It is going the other direction. A lot of the federations are making it easier for other federations to join. They’re making SP proxies. This is how we started with WAYF. We have service providers and identity providers.
Aud: registered at WAYF. When the user has to confirm and has to choose.... they have to choose WAYF to get to Copenhagen
WAYF+eduGAIN today
Why do we only do it on the IDP side, why not on SP side as well?
Service provider hub <> ID providers
Making a tick box in our registering, expose meta data for this SP for the meta data feed. Only one connection to WAYF. This is visible to rest of the world.
Meta data wise: a mesh, otherwise: a hub
Should ask: 'do you want to join as a hub or superordinate entity?'
Flows into current situation. They’re starting to build SP proxies. In order to be able to make a consent, you need to do it with the proxy enterprise.
Niels: your SP proxy - you must be including all the existing info into eduGAIN, right? You can’t beforehand know what IDP has access to your proxy. Do you allow services to be SPs to be on eduGAIn only? Connecting outside.
Mads: I don’t know.
Arnout: ORCID is only doing eduGAIn for good reasons. Connectivity. There’s nothing against that from our perspective. Do you have that scenario? Do you support it?
Mads: TNC: were registered locally, were in eduGAIN. We are cross-federating them. If we have approved it, there’s no diff if it comes from ourselves or not. Included eduGAIN, not in WAYF.
Aud: we only have separate SPs there, publishing directly to eduGAIn, to meta data streams. 1 local version, 1 eduGAIN set. They can choose.
Aud: do you have a policy for service providers? Do you have direct contact with service provider? For pre-registration, now that you're publishing?
Niels: it could be there is diff stuff in the contract than what eduGAIN is providing. We could have additional requirements that they don’t have to fulfil. We do write how to implement that. We do prefer the SURFconnect route if we can. Contracts are almost on par.
Aud: SPs or IDPs:
In WAYF: we have to approve by hand given a sponsor from one of the IPs
Has nothing to do with fed architecture, it’s a technical thing
There’s a technical component to this. We as a hub are enforcers of that policy. it would have been the institutions who do that.
Mads: NL and Denmark: basically same. But: we do it also the same way as the Swiss
Niels: can point to the actual (financial) contracts proposed to the servers.
Mads: identifying IDP? We do it for all the IDPs.
Lukas: can they consume any attributes? In your case and in WAYFs case this is true.
Mesh federations: what they accept and not accept as identifiers.
Would it be false to say now there is a consensus on...?
Niels: that would be my recommendation
Lucas: Denmark etc. are doing it
Niels: communication in research (--> flipchart). In this case, IDP is the same as a SP federation. Hub&spoke: different entities (Google, Microsoft, Elsevier, ...)
Middle part (Clarin, Elixir, Géant...) between IDP and SP controlled by the same entity. They’re not going to add services in the middle part though. Need to negotiate on that. What is the purpose of the attributes that are being provided between IDP and the middle part?
Evil, wrong, should not be allowed: moving IDP data to Google. Contracts would be brittle.
Aud: is this about outsourcing companies? Does EGI have to have the hardware for this?
Aud: in the US, there are contracts with Google. Research projects also have outsourcing contracts with Google.
Niels: you’re correct. Example doesn’t necessarily need to be Google. Contract needs to be sign specifically at a certain point.
Aud: In Italy there are two proxies and you can’t see them. SP-proxy: IDP thinks it is talking to services etc. but if EGI has contract: you lack visibility of that. Potential danger. Is that what you're trying to say?
Niels: yes.
Aud: EGI could be violating this contract, uploading data on the website.
David: if you break any of these, you'll get into trouble. This is feasible. Never trust in the agreements that you have. Contracts: they’re not allowed to re-use the information without the user's consent.
Niels: data in the back, e.g. Amazon, must be given in the contract.
David: obligation of SP.
Niels: our contract says that.
Laura: SP. what happens with the discovery side?
Niels: how our service is being discovered? Here, multiple learning systems already exist. Legal perspective: stand up to the SP to live up to the rules. eduGAIN - trivial. Metadata: you only need one entity. SP does something like make a domain name. Google does the same thing.
From a policy perspective, it's up to the SP to make up the rules. In the US: interesting.
