Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Small components that should be shared at least through common base classes we can override to deal with differences or regressions that arise:

    • LoggingService → interface fits in java-support today

    • LogbackLoggingService → implementation fits in spring-extensions today

    • Reloadable AccessControlService → implementation fits in spring-extensions today

    • Metrics → some bits probably could move down fairly low

    • Property-aware ApplicationContextInitializer → fits in spring-extensions today

    • OpenSAMLConfigBean → probably could migrate to OpenSAML (it’s not Spring-aware, just a bean)

    • Some CLI classes might have some applicability to the SP, are located in idp-core

    • XMLObject implementations for Shibboleth metadata extensions

    • Plugin/module supporting classes

  • Larger components that might warrant a new, full-fledged, multi-module project:

    • Metadata classes (Spring parsing, supporting classes)

    • Attribute classes, transcoding/registry, resolver, filter

      • Arguably separating the modules as the IdP does now may not even be beneficial, but probably not worth collapsing either?

      • includes XML Schemas and configuration formats

    • Relying party layer

      • This is probably not going to be directly applicable but there are overlaps with the SP and the way we model proxying that might warrant it

    • Session layer

      • Clear overlaps to some extent between IdP and SP, though likely differences too

    • NameID consumption / Subject C14N

      • Definitely used by proxy functionality so may be somehow adaptable to SP

Proposals in Flight

Discussed again on 6/3 call. Made initial plans to work on reorganizing projects as follows:

  1. Create a new top-level “shared/utility” repo with java-support and spring-extensions moved into subdirectories of a new multi-module project, with history rewritten via reposurgeon to reflect those locations. Any commit signatures will be removed. Tags and branches will be renamed for uniqueness. Code can be moved around and new modules created at that point. Some of the code may then be migrated into new top-level repos if desired.

  2. Begin to create new top-level projects for large IdP subsystems we need for the SP by cloning the IdP repository and removing content. History can be cleaned up after that point to eliminate the deleted content.