[java-oidc-common] branch main updated: Remove redundant test for symmetric key in JOSE headers

[Phil Smart]

This is an automated email from the git hooks/post-receive script.

philsmart pushed a commit to branch main
in repository java-oidc-common.

View the commit online:
http://git.shibboleth.net/view/?p=java-oidc-common.git;a=commit;h=16836dfc25b01b837b3a7f23655c723acc6a70e5

The following commit(s) were added to refs/heads/main by this push:
     new 16836df  Remove redundant test for symmetric key in JOSE headers
16836df is described below

commit 16836dfc25b01b837b3a7f23655c723acc6a70e5
Author: Phil Smart <philip.smart at jisc.ac.uk>
AuthorDate: Fri Oct 28 11:32:46 2022 +0100

    Remove redundant test for symmetric key in JOSE headers
    
    Nimbus no longer allows a symmetric key to be present in the header -
    which is good. It used to, so previously we wanted to test if the trust
    engine correctly handled situations where it did.
---
 .../impl/ExplicitKeySignedJWTTrustEngineTest.java  | 64 ++--------------------
 1 file changed, 6 insertions(+), 58 deletions(-)

diff --git a/oidc-common-crypto-impl/src/test/java/net/shibboleth/oidc/security/impl/ExplicitKeySignedJWTTrustEngineTest.java b/oidc-common-crypto-impl/src/test/java/net/shibboleth/oidc/security/impl/ExplicitKeySignedJWTTrustEngineTest.java
index 1dddf1e..36a7550 100644
--- a/oidc-common-crypto-impl/src/test/java/net/shibboleth/oidc/security/impl/ExplicitKeySignedJWTTrustEngineTest.java
+++ b/oidc-common-crypto-impl/src/test/java/net/shibboleth/oidc/security/impl/ExplicitKeySignedJWTTrustEngineTest.java
@@ -45,9 +45,7 @@ import com.nimbusds.jose.crypto.MACSigner;
 import com.nimbusds.jose.jwk.AsymmetricJWK;
 import com.nimbusds.jose.jwk.Curve;
 import com.nimbusds.jose.jwk.ECKey;
-import com.nimbusds.jose.jwk.OctetSequenceKey;
 import com.nimbusds.jose.jwk.gen.ECKeyGenerator;
-import com.nimbusds.jose.util.StandardCharset;
 import com.nimbusds.jwt.JWTClaimsSet;
 import com.nimbusds.jwt.SignedJWT;
 
@@ -62,7 +60,10 @@ import net.shibboleth.utilities.java.support.resolver.ResolverException;
  * 
  * <p>Note, there is not explicit test for the 'none' algorithm as Nimbus will
  * not created a SignedJWT (as required by the trust engine) if the 'none' algorithm
- * is used.
+ * is used.</p>
+ * 
+ * <p>We can not test a JWT with an in-line symmetric key (oct type) JWK as Nimbus will not (correctly)
+ * parse it. Hence we assume the trust engine could never be passed such an invalid JWT.</p>
  */
 public class ExplicitKeySignedJWTTrustEngineTest {
 
@@ -83,6 +84,7 @@ public class ExplicitKeySignedJWTTrustEngineTest {
             + "Ku8Yx+aYhYITnq5yyPiJpyHfgDj6MVlA1vUWqB9MwlvKOywLNCFfDZj6+TCjzCJF\n"
             + "XQIDAQAB";
     
+
     /** The client_secret.*/
     private static final String CLIENT_SECRET = "Xp2s5v8y/B?E(H+MbQeThWmYq3t6w9z$";
     
@@ -232,28 +234,7 @@ public class ExplicitKeySignedJWTTrustEngineTest {
                 criteria);
         assertTrue(valid);
     }
-    
-    /**
-     * A shared secret would never come via a JWK, but test in case of forgery.
-     * We should not support shared secrets in JWKs. If we did, it should also
-     * not validate against one that is store locally and trusted (as it is the
-     * attackers keys).
-     * 
-     * @throws Exception on error.
-     */
-    @Test
-    public void testInvalid_WithInlineSharedSecretJWK() throws Exception {
-        
-        final CriteriaSet criteria = new CriteriaSet();
-        criteria.add(new UsageCriterion(UsageType.SIGNING));
-        
-        final var jws = createMACSignedJWTWithInlineJWK(CLIENT_SECRET, key.getKeyID(), JWSAlgorithm.HS256, 
-                "https://op.example.com/", "https://rp.example.com");
-        
-        final var valid = engine.validate(jws, criteria);
-        assertFalse(valid);
-    }
-    
+
     @Test
     public void testInvalid_WithUntrustedInlineJWK_CVE_2018_0114() throws JOSEException, SecurityException {
         
@@ -359,39 +340,6 @@ public class ExplicitKeySignedJWTTrustEngineTest {
     }
 
     
-    /**
-     * Create an MAC signed JWS with inline JWK. This should never be a thing
-     * in reality, you should not put a shared secret into a JWK.
-     * 
-     * @param secret the secret to use to create the MAC.
-     * @param keyId the keyId to describe the key to use in the header.
-     * @param algo the key algorithm.
-     * @param issuer the issuer.
-     * @param audience the audience.
-     * @return the signed JWT
-     * @throws JOSEException on error.
-     */
-    private SignedJWT createMACSignedJWTWithInlineJWK(final String secret, final String keyId, 
-            final JWSAlgorithm algo, final String issuer,
-            final String audience) throws JOSEException {
-
-        final OctetSequenceKey key = new OctetSequenceKey
-                    .Builder(secret.getBytes(StandardCharset.UTF_8))
-                     .algorithm(JWSAlgorithm.HS256)
-                     .keyID(keyId)
-                     .build();
-        final var header = new JWSHeader.Builder(algo)
-                .type(JOSEObjectType.JWT)
-                .keyID(keyId)
-                //.jwk(key) //TODO: FIXME: Nimbus doesnt't allow injecting secret keys into header anymore
-                .build();
-        final var payload = buildStandardClaims(issuer, audience);
-
-        final var signedJWT = new SignedJWT(header, payload);
-        signedJWT.sign(new MACSigner(secret.getBytes(StandardCharset.UTF_8)));
-        return signedJWT;
-    }
-    
     /**
      * Create a EC signed JWS without a JKU or inline JWK.
      * 

-- 
To stop receiving notification emails like this one, please contact
the administrator of this repository.