[JIRA] (JCOMOIDC-48) Move OIDC.SSO profile bean to commons

[Philip Smart (Jira)]

Philip Smart ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=5afecdc1eb3ffa0c596652c4 ) *commented* on JCOMOIDC-48 ( https://shibboleth.atlassian.net/browse/JCOMOIDC-48?atlOrigin=eyJpIjoiODI2Mzg1YWRhNmRhNGI0YjkyOWQ5MmQ5MzIwMGRjNmMiLCJwIjoiaiJ9 )

Re: Move OIDC.SSO profile bean to commons ( https://shibboleth.atlassian.net/browse/JCOMOIDC-48?atlOrigin=eyJpIjoiODI2Mzg1YWRhNmRhNGI0YjkyOWQ5MmQ5MzIwMGRjNmMiLCJwIjoiaiJ9 )

I’ve made some progress with this. I added back the relying-party postconfig.xml to oidc-commons profile-api (removed from the RP). If I co-load the RP and OP (RP as the authn flow to the OP), it works, but spring is obviously replacing all the OIDC.SSO settings set on the OP with those on the RP (replaces the entire bean definition, not just any properties that overlap). So:

* I harmonized the AbstractOIDCProfile bean and, importantly, the default security configuration between the RP and OP. Notably:

* They both now use the exact same security configuration.
* They use the same key pairs for signing and encryption
* The same algorithms and algorithm includes and excludes lists
* The same credential resolvers. That is, a combination of those the RP used to fetch Provider metadata, and the OP used to fetch client information.

* In the RP case, the client information resolver will not produce a result because it is not sent the client information criterion.
* In the OP case, the provider metadata resolver will not produce a result because it is not sent the provider metadata criterion.
* I think it is fine for them to co-exist for both OP and RP, and they can choose which criterion to input.

* As both use the same key pairs, they both use the same oidc-credentials file. That file, or another the RP installs, needs to include the default client_secret credential for the RP.

* Hamronized all the properties. They are now the more generic variant from the OP e.g. shibboleth.oidc.DefaultSecurityConfiguration as opposed to shibboleth.authn.rp.oidc.DefaultSecurityConfiguration.

* Sometimes this affects the OP e.g. idp.oidc.rodecrypt.config → idp.oidc.decrypt.config

* Between the OP and the RP, the OIDC.SSO and AbstractOIDCSSOProfile **beans only overlap in one property setting; tokenEndpointAuthMethods. The OP uses this to describe what it supports. The RP uses it to determine which token authentication method to use when talking to the upstream OP. The other properties do not overlap, so it seems feasible to be able to set both on the same bean.
* Both RP and OP use the OIDC.Keyset profile. Given the default security config can be shared, these are identical in both cases.

* Of interest, both the RP and OP expose a keyset flow at different locations profile/oidc/rp/keyset and profile/oidc/keyset. I am not sure there is much point in having them separate if they, by default, share the same keys.

* I am not sure what happens if you created your own relying party security config override and use different keys. The keyset flow will still point to the global ones (I digress)
* Given the security config and basic profiles are inside oidc-commons, maybe commons could supply the keyset flow? which is enabled by the OP or RP on install in some way.

* It seems a good idea (as Scott suggested) to have a generic oidc properties file, and separate ones for the RP and OP. Maybe commons could install the generic OIDC properties file? (this properties file is not be used by DuoOIDC of course, so that would look a bit messy if you only installed commons with Duo).

( https://shibboleth.atlassian.net/browse/JCOMOIDC-48#add-comment?atlOrigin=eyJpIjoiODI2Mzg1YWRhNmRhNGI0YjkyOWQ5MmQ5MzIwMGRjNmMiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/JCOMOIDC-48#add-comment?atlOrigin=eyJpIjoiODI2Mzg1YWRhNmRhNGI0YjkyOWQ5MmQ5MzIwMGRjNmMiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100214- sha1:634fa42 )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20230126/0e3b1374/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-5cb0d393-19ec-47c0-a8f2-e7ea6cf0bb00
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230126/0e3b1374/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-8ee77414-73ce-47a6-92bb-a34bbab3861e
Type: image/png
Size: 448 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230126/0e3b1374/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-788b5564-44d5-40d4-930d-6485f16e7402
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230126/0e3b1374/attachment-0005.png>