...
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
...