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

Thu Jul 14 09:29:33 UTC 2022

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

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

Many thanks for the detailed comments, Brent Putman ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A97de0981-adc3-4044-95ed-131622fad81e ) , they are very useful. Here are some replies, although in short, I agree with what you suggest and will look to build improvements to the credential resolvers.

> 
> 
> 
> The only criteria passed in is the usage type (and I guess additional
> criteria that can be carried in the params?).
> 
> 

Yes, I use a criterion to pass in the direct encryption key/secret as that comes from the client_secret on the profile config at runtime. There is a simple resolver that pulls that out.

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

Yes, you are right. Currently, that is all they are doing. There is logic in the Decrypter to match the JOSE Header ‘alg’ (Algorithm) and ‘enc’ parameters from the JWT to the resolved credentials one by one. But as you suggest, that should be passed into the resolvers and they can filter those out.

> 
> 
> 
> But I’m not sure what happens if you just try the key agreement with an
> incorrect private key
> 
> 

Neither do I, I am not sure of the extent of what Nimbus catch/report - they suggest all errors, but that maybe does not cover the unchecked type. I will look to test this.

> 
> 
> 
> The cred resolvers in the parameters should be instances of the new
> JOSEObjectCredentialResolver
> 
> 

Agreed, I will switch those over. And create a new one that supports the EvaluableCredentialCriterion.

> 
> 
> 
> In the JWTDecrypter you should always add the EncryptedJWT to the criteria
> using the JOSEObjectCriterion
> 
> 

OK, so I assume you mean to add the whole object rather than just the JOSE headers, or picking out the keyID and ‘alg’ as separate criterion?

> 
> 
> 
> eval of that criteria input is done auto-magically by one of the abstract
> base classes of resolver called
> AbstractCriteriaFilteringCredentialResolver
> 
> 

Yes, I already have this for the OIDC Provider Metadata resolver for the sig trust engine. So have some experience. That also builds an EvaluableKeyIDCredentialCriterion which is indeed automatically filtered by the base class. So I need to add that detail to the local key decryption resolvers.

So yes, perhaps the AbstractCriteriaFilteringCredentialResolver could be moved into API.

I think this work could be useful - in the long run - to the OIDC OP as well.

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

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/1b90a688/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-38e82a91-e5d9-4a70-a1da-5a58ab56833e
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220714/1b90a688/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-878ccaff-69f5-4311-9e39-1e839e0ac5ee
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220714/1b90a688/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-12db0438-df30-4f3d-9f0f-564b632eed66
Type: image/png
Size: 468 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220714/1b90a688/attachment-0005.png>