A (draft) General Model of an E-infrastructure
16 June 2014 at 3:58pm
At the recent Working Group meeting I presented this diagram, which I've been using to get my head around the various components of an e-infrastructure and how they fit together. It's very much a work in progress: the typefaces show areas I'm reasonably confident of (in Roman) versus those (in Italic) where the implementation, and in some cases even the best combination of functions, are less clear to me. I'm still refining the diagram so comments and suggestions are welcome.
Comments
The more I think about this the more i am convinced that the "swamp" in the AuthZ space compared to the AuthN space is because at the moment the options are all software options rather than protocols. However reading the SAML specifications these certainly do consider stand-alone Attribute Authorities which would allow SAML to be used for communicating group membership information between Group-management and Services independently of the IdP. I'm not sure how well supported this is in practice but the following paper looks promising in the shibboleth space http://www.cesnet.cz/wp-content/uploads/2013/12/saml-aa-shibboleth.pdf
One way forward would be to try and build an ecosystem of interoperable tools by increasing SAML support in existing tools. VOMS already maps SAML attributes into the x509 space.
Stephen
I think you're right. And it's even worse because not only does there seem to be a different protocol per group management tool, but there also seems to be a multiplicity of approaches on the server side. Talking to some of the people trying to write standalone group management tools at TERENA they were having to configure individual handlers for each service provider they tried to bring in :(
I'll try to take some soundings on whether there's a particular flavour of SAML we could implement that might increase interoperability. And if anyone reading this wants to chip in, please do...
I think the place to start is with Shibboleth because its widely deployed and can already do a lot of the necessary operations. Shibboleth could handle the merging of IdP and VO attributes so any shibboleth enabled application could pick up the groups in the normal way. Once you had a solution in the shib space you could map this to other use cases. For example I think VOMS can already translate shibboleth attributes to attributes encoded in a x509 certificate so any group manager that exposes groups to shibboleth automatically becomes a VOMS enabled group manager.
The way I would do this for SAFE data is write a shibboleth IdP plug-in to make SAFE group information available as attributes and then run an Idp as a stand-alone AttributeAuthority along the lines of the paper I linked to above. However this approach needs common identifiers between the AA and the SPs that consume the attributes.
If you have services that are only concerned with a single VO you could run a full IdP for that VO. This would NOT be part of the federation but a single IdP that you bind services to directly. You could use the normal federation as the back-end authentication mechanism so users still get single-sign-on. This would be ok for distributed services dedicated to a single VO but no good shared services.
It'd be good to get some sort of feel for what sort of information needs to be passed from the group management system(s) to the service provider(s). For instance there were a couple of mentions of VOOT at the TERENA conference: that seems able to pass a list of group members with up to three pre-defined roles for each (member, manager, admin). Those roles actually map what's available on Community (no idea if that's a coincidence!) so are clearly enough for some collaboration applications. And services would appear to have the flexibility to map them to specific local functions, e.g. read, read-write, read-write-create-delete.
On the other hand I don't think they'd be enough for a service where you needed to send additional per-user information, e.g. CPU or storage quotas perhaps? But I don't know if there are sufficient services that could fit within the simple VOOT scheme to make it worth further investigation?
[it struck me that the ability to delegate group management - e.g. to allow a colleague to add additional researchers - probably doesn't need to be communicated between the group management system and the service. I *think* that's a function that can stay within the group management system?]
Has anyone documented the group information that they need to pass to their services? That'd be really useful to avoid us adopting a syntax that's more complex than we need.