This Request for Comments (RfC) describes the reasons and thoughts that lead to a major change of the IdP as a Service business case activity.

...

Introduction

The original idea of an IdP as a service was born in the last GÉANT phase based GN4-2 based on a community survey which indicated the desire for such a service.  During the first half During GN4-2 an architecture was chosen and a prototype was developed, which was then handed over to the Incubator.
In the first 3 months of the incubator cycle, a lot of effort was invested in understanding the software used for the prototype. At the same time the incubator analyzing again the needs of the community on the one hand and technical possibilities on the other. After these results were presented  

The Incubator presented its findings to the community at TNC2019 and discussed when discussing with representatives, it turned out that these the former GN42 assumptions were no longer true. The initial idea was had been to deliver a fully fledged IdP as a Service solution to organisations by creating automate the deployment of independently hosted Idps for organisations. For this it was envisioned a platform hosted by either GÉANT or NRENS would be needed. During the course of this activity it turned out that this does not match the demand of the R&E community. Although there Based on the new requirements, it was concluded there is a potential market for an IdP as a Service offering, especially for small and medium sized institutions, this . This solution should be very lightweight in a way that is is really easy to use, to deploy and support supports basic functionality only.

In addition, there There is also no real demand for a GÉANT hosted service or supported product, because especially since the time to market is considered a critical aspect by the community. There is also It was noted that several NRENS and organizations have already started working on their own approaches to create an IdP as a Service offer. There is a high interest in combining locally hosted software with commercial such offer with existing products in using either on campus or by enable offerings from cloud service providers.

Finally it was noted during the community consultation the Incubator would to well to collect and describe the technical requirements for a IdP as a Service solution as well as the required capabilities for the IdP(s) it spawns. Such a list of requirements could be used by NRENs for procurement of an IdPaaS service commercially, or would serve as a reference point for NREN developed software solutions and NREN offerings, which requires a highly modular software design.

Assessment

It is clear there is a need for a hosted IdP solution, especially for smaller institutions who have no means of operating and managing an IdP themselves. Operating in this case is not just limited to the technical operations of the IdP software itself, but the whole enterprise of running an IdP, including managing IdM, dealing with (custom) attribute release, software updates and maintenance etc. It is deemed unlikely all of these elements can be managed by the aforementioned small institutions. Therefore, the solution provided by this activity should no longer try to provide a fully fledged service, but a lightweight software product that enables NRENS and other organisations to create and support such an offer on their own. To achieve this goal, this activity should work on the following two tasks:locally. At the same time, elements of the IdP operations should also be able to leverage existing campus infrastructures like a user LDAP or AD, yet also allow easy use of such tools when provided via the cloud, e.g. AzureAD.

Due to this new situation it follows that the previous approach based on the Campus IdP prototype cannot be pursued any further. Its design is aimed at automating the deployment of IdPs in any distributed environment and providing customers with a fully functional Shibboleth IdP. The entire functional range of the platform and IdPs provided, which still requires a lot of development work before a first release, would go far beyond what is expected from the community. An adaptation of the software to the new requirements would require fundamental architectural changes, which would result in a disproportionately high effort.

Taking into account these new facts and their impact on the activity, the following approach is proposed:

Campus IdP engagement discontinued

• Disengage the work on the Campus IdP as started in GN4-2. The sources will still be available to the community under an open source license. We will not provide support on these components.
• Stop investigating the business case for a GÉANT hosted IdPaaS platform offering.

IdP as a Service Software Design

...

• Create a software design package for a software solution that includes a specification and reference architecture.
  The specification will define the features and requirements needed according to a

...

• Minimal Viable Product  definition of an IdP as a Service platform in the context of Research and Education.
  Based on this specification a technical reference architecture will be designed, which supports these requirements and

...

• aligns with into existing R&E T&I software.

...

• The MVP will be

...

• evaluated together with the

...

• community and delivered as a report.

This way we offer value as we set the baseline for any requirements and potential procurement by NRENs or federations. For the creation of this, we can heavily reuse work done in he first phase of this incubator activity.

Creation of a Reference implementation

...

• Create a reference software

...

• implementation. 
  This reference implementation provides a simple, easily deploy-able

...

• product that includes all specified features using the reference architecture. This solution will be provided to the community as a publicly available open source software including technical documentation. This software is intended to be used by NRENS to create their own IdP as a Service offering for institutions in their country. We have already, again as part of previous work in this activity, identified a software product (SAMLidP.io) that is being used by some members of the NREN community and seems to have a broad coverage of the required features. We were not able to identify other products readily.  We think this product will provide a very good starting point, though it still needs some enhancements to fully meet MVP requirements.  We will upstream all our changes to existing product. The incubator will not necessarily continue to support the product or its further development after this incubator cycle.
  

By providing a reference implementation we create a ready to pick up product for NRENs to use and start shared development on. It may also be picked up by commercial entities who wish to offer services relevant to our community.

Community Initiation

• Community engagement
  Several NRENs currently operate or plan to operate an IdP as a Service platform. Together with Task 4, the incubator will investigate the feasibility of starting an IdPaaS operators special interest group. After initial investigation, the Incubator will handover this activity to task 4.

Decision

Based on the described reasonsthe steps proposed in the assessment, the Incubator activity will change it's course of action drastically. There won't will not be any official product, service or software support provided by GÉANT. The further development of this reference design and software is up to the community. The usage of these resources won't be restricted, so everyone and every organization is free to build their own solution on top. This applies to non-profit organizations as well as commercial vendors, which may offer similar products.

The implications of this decision choice are listed below.:

...

...

Do's

...

...

In order to reflect this major change, the activity will be transferred from IdP as a Service Business case to IdP as a Service Software Solution.