Move RelyingParty "layer" into java-shib-profile
Description
Environment
is related to
Activity
Scott Cantor March 2, 2023 at 3:40 PM
Collapsed out the “separate” RelyingPartyConfiguration class with responderId, I’m going to try and reuse that. That eliminates a number of other cases of IdP-specific classes.
I did mark getResponderId nullable, which is potentially an issue somewhere, but this is never going to be null in the IdP in practice and our null cleanup should catch anything obvious we’re doing. Most access is via a Function that was already nullable anyway.
I am considering a move to deprecate responderId in favor of entityId but TBD.
Scott Cantor March 2, 2023 at 2:09 PM
During further design work, I decided to revisit some of the additional IdP/SP distinctions I was considering.
Scott Cantor February 28, 2023 at 8:42 PM
The core class that builds RelyingPartyConfigurations is now moved, with some class parameterization for the IdP-specific part, should be reusable for SP now.
I’ve walked through most everything now save for the action beans, which will raise a later consideration. We’re going to want to reuse the action logic a lot, but it will require either creating a limited sort of WebFlow-like orchestration layer or creating yet another abstraction in between to move the business logic into. I probably favor the former. Many of the IdP beans that don’t make use of IdP-specific classes may be possible to move down and turn back into OpenSAML ProfileActions, which don’t actually know about SWF.
Scott Cantor February 22, 2023 at 3:34 PM
SAML classes have been refactored and split into shared interfaces, IdP-specific interfaces, and the classes. All classes now in idp-saml-impl and no references to them are intended in any classes save tests and the configuration service itself.
Scott Cantor February 15, 2023 at 6:39 PM
Moving into SAML packages, the main goal is to identify the (minimal) subset of common settings between IdP and SP to share some high level profile configs and more importantly the various lookup functions and predicates used to access them.
After further review, I’ve prototyped a refactor of the RelyingPartyResolver and associated config/context classes and managed to extricate it from the IdP so proposing we do this to allow sharing of core logic with the SP, including (eventually) migrating out a lot of the lookup functions and predicates for shared use.
As part of this work, I also collapsed out the “extra” resolver classes. The basic interface and service implementation can be made CriteriaSet-based, eliminating the “extra” delegating version Brent wrote. I revised the root interface to expose signing and encryption credentials, allowing those CredentialResolvers to be streamlined.
Also elimiinated the extra wrapper class that hides the ReloadableService layer, and rewrote the consuming actions and classes to directly consume ReloadableService<RelyingPartyConfigurationResolver> instead of RelyingPartyConfigurationResolver, which is something we probably should do elsewhere to eliminate extra wrappers.