Automation of deployment and configuration of initial set of SPs for new federations

While supporting new federations in setting up their infrastructures, IdPs and SPs,  generally speaking, we still do not have much automation in place. All is done, still very manually, and takes much time. Talking specifically of the SPs, both for the installation and configuration of the services themselves, and the required operations to federate them (i.e. make them fully functional SAML2 Service Providers), in order to be able to provide them in a federated (e.g.eduAGAIN) fashion, pretty much all is still left to manual set up. 

It would be useful to enhance the level of support we provide to them with the aim of quickly being able to deploy an initial set of services, the ones which could de-facto start to attract users towards the newly deployed federation infrastructure and the federated IdPs. 

The idea here is to propose  a new cycle of T&I incubator task activities aimed at the following tasks:

1. Identifying an initial set of 2-3 services we’d like to promote as SPs to the new identity federations. (e.g.: Wiki, Moodle, Joomla, eduMEET, Filesender, ..)
2. Design a solution based on automation, possibly using containers, or automated deployment tools like Ansible, Puppet (which we should aim at making easy for early services deployers), for the services we’d like to deploy. Or any script with the corresponding clear, easy to use documentation which would do as much of the initial installation and configuration work as possible, leaving to a minimum the amount of residual manual interventions required. 
3. Define both technical and strategic roadmaps to ensure sustainability of these deployment solutions: how will they be upgraded/ported to new versions, which task, or permanent activity in the GN project, or the community could endorse the future work to keep the developed solution working also in future.
   
   This proposal is about using a full Incubator cycle  to develop an initial solution, work on it, and add some work to design in a clear way how things can be made sustainable after the T&I cycle would be over. 

More information on the proposal on https://docs.google.com/document/d/1pYN73FEbFApkPNAVgdbNIA1_87ekIEAt8HvzhhXkxrk/edit?usp=sharing  

It is noted some very similar requiremtents may serve Virtual Organisations. Arnount Terpstra from SURF writes:

"What I am basically looking for is a set of (fairly simple) "collaboration tools" which nearly every collaboration needs. (Since I am focusing on my service SURF Research Access Management (SRAM) which targets researchers, the type of collaborations I am dealing with are research collaborations, but of course such tools could be used by any type.) What do researchers / collaborations need regardless of which topic they are in? Some tool to do collaborative writing, to jointly make presentations, a date picker to plan meetings, a Wiki to keep meeting notes / documentation, etc. Most of such tools are already freely available (Google Docs, Doodle, etc.) but of course you pay with your privacy. Also, most institutions have something like Microsoft Office365 + Teams, but for some reason these tools are often inaccessible for people outside of their own institution. Thus: based on already available open source and privacy friendly tools, it would be nice to combine this with Mario's idea of making the deployment of these tools quick and easy such that different NRENs (or whoever) can (easily) offer it to their constituency. (BTW I recently stumbled upon this tool: Crypt Pad (https://cryptpad.fr/ for a hosted free demo), which seems to already contain 90%+ of the tools I'm thinking of. Maybe that's an option to start with?)
In my case, access management to these tools is or course handled by SRAM."

With respect to the implementation of this, there are a numer of scenarios, basically automating deployment as proposed by Mario above, where the focus is on creating deployment and integration scipts, or an approache as suggested by Niels whic introduces a proxy to aggregate the servces and potentially simplyfy the deployment and integration of tools, however, increasing the complexity in a way, as new comonents are added.
We have to describe these scenarios and weigth the imact in terms of technical complexity, maintainability, etc. The list of high level activiteis is:

• Describe scenarios and discuss with stakeholders
• Make an inventory of relevant services we would like to include
• Create proof of concept of at least one scenario and present to stakeholders
• Develop proof of concept infor useable product.

The following parties will use the results of this activity:

The following results were created and delivered: