Move OIDC.SSO profile bean to commons
Description
Environment
Confluence content
mentioned on
Activity
Philip SmartMay 5, 2023 at 1:18 PM
Moved into its own plugin and tested.
Philip SmartFebruary 10, 2023 at 9:35 AM
After discussion with @Scott Cantor and @Henri Mikkonen this work has moved into a new plugin java-idp-plugin-oidc-config. Commons will not contain any shared configuration. The RP and OP will directly depend on the new module (id: idp.oidc.config.1) which will depend on oidc-commons. They will need to be installed in the correct order with the possibility of the installer handling this in the future.
We also removed the properties files and conf/ XML configuration from the plugin and back into the OP and RP. Consequently, the new plugin only holds JAR-based configuration automatically applied by the IdP.
Further updates on this issue will refer to java-idp-plugin-oidc-config.
Philip SmartFebruary 3, 2023 at 10:11 AM
I merged the branch into main. We can adjust it from there.
Philip SmartFebruary 2, 2023 at 2:04 PMEdited
The only remaining issue with the OIDC.SSO bean is the use of the DefaultJWTClaimsValidator bean as the claims validator. The RP does not supply that, so the config will not load without the OP. I propose using the getObject syntax for this, such that it could be null if not supplied.
Obviously, we need to check the OP does not just ignore JWT validation if the bean is null (although once the OP is installed it should pick it up).
Philip SmartFebruary 2, 2023 at 2:01 PM
After speaking to @Henri Mikkonen, it seems best not to make commons V2.2.0 responsible for a shared security properties file, so that it does not confuse deployers on upgrade. This could be added back for commons V3.0.0.
Both RP and OP use the OIDC.SSO
http://shibboleth.net/ns/profiles/oidc/sso/browserprofile. Hence, both use the same profile bean. However, the OP and RP install this separately into the IdP inside theservices/relying-party/postconfig.xmlconfig hook. This could lead to nondeterministic (or just unknown) behavior regarding which settings get pulled in for an RP flow compared to an OP flow.The OP and RP use compatible overlapping (to be confirmed) settings, or settings unique to themselves. As @Scott Cantor suggested in https://shibboleth.atlassian.net/browse/JOIDCRP-18, it might be beneficial to centralize the profile config into oidc-common such that both RP and OP can share the same profile config bean.
@Henri Mikkonen this will need some coordination with the OP to get right.