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 GN4-2 based on a community survey which indicated the desire for such a service. 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. 

The Incubator presented its findings to the community at TNC2019 and when discussing with representatives, it turned out that the former GN42 assumptions were no longer true. The initial idea had been to deliver a fully fledged IdP as a Service solution to 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. 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 solution should be lightweight in a way that is is really easy to use, to deploy and supports basic functionality only.

In addition, there is no real demand for a GÉANT hosted service or supported product, especially since the time to market is considered a critical aspect by the community. 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 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.

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 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 steps proposed in the assessment, the Incubator activity will change it's course of action. There 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 choice are listed below:

Do'sDont's

Deliver a report containing a specification and design for an IdP as a Service offering

There won't be a service or product provided or supported by GÉANT

Development of a simple software product that implements the specification, which will be provided as open source software on GitHub

The created software won't be owned software or supported by GÉANT

The provided solution will enhance the already existing open source software samlidp.io

The development of the Campus IdP prototype implemented during GN4-2 will be stopped

The results of this activity will be provided completely to the community for further support and development

There won't be a business plan regarding a hosted solution

The community will be informed about the availability of this open source software during the runtime of this activity

After delivering a design and software solution, the activity ends and there won't be any further actions for the Incubator

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.

5 Comments

  1. Davide Vaghetti

    Nice write up. Some comments:

    1. IMO it is necessary to give account of the separation of the Campus IdP activity in Campus IdP Platform and the so-called Campus IdP Toolkit, which is nothing but an ansible playbook to install and configure a shibboleth IdP in an eduGAIN-ready fashion (SAML Profile/R&S/CoCo/etc.). The Campus IdP Toolkit is part of the eduGAIN service and it is curated by GARR, see https://github.com/GEANT/ansible-shibboleth
    2. It should be clear that the above is the continuation of the "Campus IdP Platform" activity.
    3. IMO one of the reason for which the previous "Campus IdP Platform" activity did not complete was the will to seamlessly integrate it in a cloud environment, which both exponentially augmented the required development effort and, more importantly, introduced to many requirements for the possible adopters.
    4. I didn't understand if the IDMS(aaS) is part of the proposed service it or not.
    5. While it's very clear what the Incubator activity is committed to do, it's not clear to me how the work will continue, that is under which organization the cited IdPaaS SIG will be formed? REFEDS?
    6. Given that this is a very specific piece of software, hardly reusable in other contexts, IMO it is necessary to specify who are the adopters (or who are we doing the work for).

    1. Michael Schmidt

      1./2. Yes, you are absolutely right.

      4. We won't offer IDM directly as a Service. Our idea is that the software will contain a lightweight integrated IDM, so that the IdP can be used as a standalone service. Furthermore, we want to offer some kind of interface to allow the use of a remote database, which is controlled by the instituiton and might be hosted locally or even at a commercial provider. However, it won't be possible to use the integrated user management with a remote database, so the user has to choose.

      5. That is not yet decided. We hope to define the best format of collaboration and build a community is something Maartens task could do. However, we don't see it as the Incubators primary goal to form this group or ensure that someone continues work on this software. There are already some organizations using the open source software we plan to extend, so there is a potential basis for a community that maintains this software.

      6. Our target group are NRENS willing to offer an IdP as a Service, especially to integrate small organizations which are not yet part of their federation due to a lack of resources. From our point of view it's not the goal that all NRENS use this software, they might as well fork the software, create their own one based on the specification or negotiate with commercial service providers to provide them with this or a similar service.

  2. Justin Knight

    1. What was the market research (other than at TNC19) that informs the view that the work done under GN4-2 is of no use? Is it worth investigating this further to ensure that the work that went into GN4-2 is not in vain?
    2. +1 to Davide's comment #6. I would say this is a pre-requisite to starting an Incubator development cycle.
    3. Is there a case to utilise the already existing NREN service offerings and increase community take-up, rather than building something new?

    1. Michael Schmidt

      1. There was no in-depth market analysis performed. Our knowledge is mostly based on the mentioned TNC meeting and individual talks to persons in the community during the last year. It might be that further research brings up other interested parties who could make some use of a service as designed in GN4-2. However, not only to proceed development would require much effort, but such an marked analysis as well. For now, we think it is more valuable to deliver a lightweight but usable product until end of this cycle. If one things that it worth investing into an in-depth market analysis, there is still the option to propose this as a new activity to the Incubator. The source code created during GN4-2 is on GitHub, so it is potentially possible for any task to contunuie the work if required.

      3. At the moment it seems that most of these solutions are under development as well. There are very different approaches, from commercial services to proxy solution to manual configuration everything seems to be on the table.
      The solution we want to use (samlidp.io) is already a sound product that includes most functionalities we need, so we don't start from scratch. This product is already in use by some organizations, which makes it easier to build a community around this.

  3. Maarten Kremers

    1. +1 to Davide's comment #6.
    2. Task 4 is more aimed at enabling current existing user communities with T&I services rather provide supporting in building a community of suppliers (NRENS)for a very specific T&I component. I won't say is impossible, but with the current amount of people and manpower available we have assess what work we can do. I expect that  building a community for a specific T&I tool with some uncertainties on how the future has lower impactfactor then other activities in task 4, and given the already fragmented manpower i rather do couple of activities well than more activities half done.
    3. Even if task 4 has time, the community participants themselves have to be active. The work is reciprocal. The potential community participants must able to organise themselves in the end to get futher. Task 4 can help in setting up a community under REFEDS, GEANT community, but the community itself will out of scope for WP5 as WP5 isn't a stakeholder (NRENS are). I propose to change "Community Engagement as follow:
      "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, of which T4 wil take the lead. After initial investigation, WP5 (incubator and EnCo) will handover this activity to community itself."