[JIRA] (JCOMOIDC-45) Add a Decrypter for JWE tokens similar to the opensaml Decrypter

Thu Jul 14 01:33:16 UTC 2022

Brent Putman ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A97de0981-adc3-4044-95ed-131622fad81e ) *commented* on JCOMOIDC-45 ( https://shibboleth.atlassian.net/browse/JCOMOIDC-45?atlOrigin=eyJpIjoiNWQxNThmNmRkOTFjNDhkNzg2ZTFmYmRhMTM0MzE2MmQiLCJwIjoiaiJ9 )

Re: Add a Decrypter for JWE tokens similar to the opensaml Decrypter ( https://shibboleth.atlassian.net/browse/JCOMOIDC-45?atlOrigin=eyJpIjoiNWQxNThmNmRkOTFjNDhkNzg2ZTFmYmRhMTM0MzE2MmQiLCJwIjoiaiJ9 )

The main thing I’d comment on so far is in how the parameters' CredentialResolvers are being used. All the various methods use a pattern like this:

final CriteriaSet criteria = buildCriteria(List.of( new UsageCriterion(UsageType.ENCRYPTION)));

try {
 for ( final Credential cred : params.getKEKCredentialResolver().resolve(criteria)) {

The only criteria passed in is the usage type (and I guess additional criteria that can be carried in the params?). So they can’t and don’t take into account any of the information/hints from the headers as to the exact key to use to decrypt, like key name or (for RSA) the public key corresponding to the private key used. So the only way the cred resolvers can work is by just returning all the ones it knows about and you loop over them until one works.

I think Scott might do that in the native SP, but I personally dislike that approach b/c it seems at best inefficient, and at worst might break in unexpected ways. I’d rather winnow the possible decryption keys that are tried down to ones that match what the headers say.

Also, while this approach technically seems to have historically worked reliably for direct/symmetric and RSA keys (albeit inelegantly IMHO) - because it is possible to just apriori have the actual private/symmetric decryption key already - it’s less clear for the key agreement case. I see that they have the special ECDHDecrypter, which presumably does all the agreement and derivation stuff, based on the headers. But I’m not sure what happens if you just try the key agreement with an incorrect private key. Maybe it works reliably (by failing in the expected way and falling through), maybe it doesn’t.

To be safe, and head off any unknown unknown types of issues, I’d suggest considering doing the following, similar to what we do for SAML:

* The cred resolvers in the parameters should be instances of the new JOSEObjectCredentialResolver
* In the JWTDecrypter you should always add the EncryptedJWT to the criteria using the JOSEObjectCriterion

The actual cred resolver impls would then be a specialized subtype of that interface (probably of BasicJOSEObjectCredentialResolver), which knows how to resolve the local cred (secret or private key) based on the info/hints from the headers.

For reference, in SAML this is precisely what the LocalKeyInfoCredentialResolver impl is for, relative to the “normal” BasicProviderKeyInfoCredentialResolver impl. It resolves the public on-the-wire stuff from the KeyInfo, then uses that as criteria for input to an injected “local” CredentialResolver to resolve the cred(s) containing the corresponding private or symmetric key.

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

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#100202- sha1:e905ae5 )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20220714/269237ff/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-c00dd41c-2e81-4c2d-9201-f83db46828a8
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220714/269237ff/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-f09a2ab4-db48-4adb-b1f5-36eb64ed3a27
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220714/269237ff/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-0efe60b8-4b25-4a7e-88a4-d22311536fa3
Type: image/png
Size: 468 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220714/269237ff/attachment-0005.png>