Uploaded image for project: 'Identity Provider'
  1. Identity Provider
  2. IDP-1481

Single deployment workflow for an IdP with multiple extensions



    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Completed
    • Affects Version/s: None
    • Fix Version/s: 4.0.0
    • Component/s: Build
    • Labels:


      We (SWITCH) deploy IdPs with extensions, mostly our own, but more importantly more than one per IdP. Installing/updating several extensions on a running IdP is where this starts being awkward. Each extension has it's own separate build and deployment pipeline which ultimately drops the extension's JAR in edit-webapp/WEB-INF/lib and calls bin/build.sh. That's all right for one extension, but with more there could be several instances of the deployment pipeline running and competing to rebuild the WAR. Moreover, removing the previous versions of an extension from edit-webapp/WEB-INF/lib is necessary and scripting it is error-prone (rm edit-webapp/WEB-INF/lib/myextension-*.jar) and subject to the same concurrency issues. On top of that, dependencies from extensions themselves must also be installed (more hackish scripting!) and extensions may ship different/conflicting versions of the same libraries. I would like to unify deployment of an IdP with extensions by packaging everything into a WAR file (idp.war) and take advantage of Maven's dependency management to declare which extensions go in and enforce dependency versions. This should reduce (re-)deploying an IdP to dropping idp.war in my Servlet container.

      I could achieve this today with Maven WAR overlays: insert extension JARs and their dependencies, or even upgrade IdP dependencies (Spring Framework security upgrades, for example), then repack the WAR. All of that using Maven's dependency management and resolution, so I can express which version of which extension/library goes in. This process is declarative, reproducible and produces one artifact to deploy, which fits nicely into modern CI/CD pipelines. However this is not an officially supported installation method, so I'd like to see more support for this kind of deployment from the project. For example, runtime dependencies that are installed by the installer, like Logback, could be declared as dependencies of idp-war instead.

      Pushing the idea further, in this situation, the whole installer and scripts like bin/build.sh are no longer needed. Likewise, "system" configuration could be packaged inside the WAR since deployers aren't supposed to modify it. Going even further, the IdP could be shipped as an executable JAR with an embedded Servlet container, à la Spring Boot, expecting to find its configuration at $IDP_HOME/conf. This would further simplify deployment (no non-idempotent commands to execute), especially on container platforms.


        1. idp-war-distribution.bundle
          3 kB
          Etienne Dysli-Metref
        2. idp-war-distribution.patch
          3 kB
          Etienne Dysli-Metref

          Issue Links



              tzeller@shibboleth.net Tom Zeller
              cp+akh4hcy23wzvoqzqp+bp6+ao=@https://aai-logon.switch.ch/idp/shibboleth Etienne Dysli-Metref
              3 Start watching this issue



                  Time Tracking

                  Original Estimate - Not Specified
                  Not Specified
                  Remaining Estimate - Not Specified
                  Not Specified
                  Time Spent - 15 minutes