vendor-neutral configuration of MP-JWT

[Scott Stark]

A proposal for the vendor-neutral configuration of MP-JWT  issue consists of defining the following:

package org.eclipse.microprofile.jwt.config;

/**
 * Constants for the names of the MP-config properties that MP-JWT implementations must support externalization
 * of to ensure portable setup of MP-JWT implementations.
 */
public class Names {
    /**
     * The PEM encoded public key of the MP-JWT signer
     * TODO: decide if this should be dropped. If not, a standard Converter<PublicKey>
     *     should be provided with the appropriate META-INF/services/... definition
     */
    public final static String verifierPublicKey = "org.eclipse.microprofile.authentication.JWT.verifierPublicKey";

    /**
     * The expected iss claim value to validate against an MP-JWT
     */
    public final static String issuer = "org.eclipse.microprofile.authentication.JWT.issuer";
    /**
     * The expected iss claim value(s) as an array to validate against an MP-JWT
     * TODO: are both a single and array values needed?
     */
    public final static String issuers = "org.eclipse.microprofile.authentication.JWT.issuers";

    /**
     * The allowed clock skew in seconds to use when validate the MP-JWT exp claim
     */
    public final static String clockSkew = "org.eclipse.microprofile.authentication.JWT.clockSkew";

    /**
     * The URI of an endpoint providing a JSON Web Key Set (JWKS) for the allowed signers of the MP-JWT.
     * The type of this property is a String or URI
     * The keys in the returned key set must include the following parameters:
     * "kty": "RSA",
     * "use": "sig",
     * "alg": "RS256",
     * "n" (Modulus) Parameter
     * "e" (Exponent) Parameter
     */
    public final static String verifierJwksURI = "org.eclipse.microprofile.authentication.JWT.verifierJwksURI";

    /**
     * The interval in minutes that the contents of the verifierJwksURI may be cached without reloading.
     */
    public final static String verifierJwksRefreshInterval = "org.eclipse.microprofile.authentication.JWT.verifierJwksRefreshInterval";

}

The note in the spec that states a future spec may define how MP-config should be used will be replaced with:

## Configuration of MP-JWT implementations using the MicroProfile Config Feature

To ensure portable setup of applications using the MP-JWT feature across implementations, we rely on the MicroProfile config feature. An MP-JWT implementation MUST support the following properties to allow the verification of MP-JWTs to be externalized in a consistent manner:

... descriptions of the property names and usage similar to that above in the Names class comments.

This also incorporates the JWKS support we talked about introducing.

Comments/questions?

[Ladislav Thon]

Few comments inline.

2018-04-12 7:31 GMT+02:00 Scott Stark <sst...@redhat.com>:

A proposal for the vendor-neutral configuration of MP-JWT  issue consists of defining the following:

package org.eclipse.microprofile.jwt.config;

/**
 * Constants for the names of the MP-config properties that MP-JWT implementations must support externalization
 * of to ensure portable setup of MP-JWT implementations.
 */
public class Names {
    /**
     * The PEM encoded public key of the MP-JWT signer
     * TODO: decide if this should be dropped. If not, a standard Converter<PublicKey>
     *     should be provided with the appropriate META-INF/services/... definition
     */
    public final static String verifierPublicKey = "org.eclipse.microprofile.authentication.JWT.verifierPublicKey";

1. Is this consistent with how other MP specs construct their MP Config keys? I don't think there's a lot of precedents, but MP OpenAPI seems to use mp.openapi.*, which is at least considerably shorter.

2. Being able to set an entire public key literal is nice, but what about being able to set a file name / classpath resource name?

How do the last two properties interact with the verifierPublicKey ?

LT

 

}

The note in the spec that states a future spec may define how MP-config should be used will be replaced with:

## Configuration of MP-JWT implementations using the MicroProfile Config Feature

To ensure portable setup of applications using the MP-JWT feature across implementations, we rely on the MicroProfile config feature. An MP-JWT implementation MUST support the following properties to allow the verification of MP-JWTs to be externalized in a consistent manner:

... descriptions of the property names and usage similar to that above in the Names class comments.

This also incorporates the JWKS support we talked about introducing.

Comments/questions?

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/0598077a-9468-4277-8d86-751161b20e78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Scott Stark]

On Thursday, April 12, 2018 at 6:20:41 AM UTC-7, Ladislav Thon wrote:

Few comments inline.

2018-04-12 7:31 GMT+02:00 Scott Stark <sst...@redhat.com>:

A proposal for the vendor-neutral configuration of MP-JWT  issue consists of defining the following:

package org.eclipse.microprofile.jwt.config;

/**
 * Constants for the names of the MP-config properties that MP-JWT implementations must support externalization
 * of to ensure portable setup of MP-JWT implementations.
 */
public class Names {
    /**
     * The PEM encoded public key of the MP-JWT signer
     * TODO: decide if this should be dropped. If not, a standard Converter<PublicKey>
     *     should be provided with the appropriate META-INF/services/... definition
     */
    public final static String verifierPublicKey = "org.eclipse.microprofile.authentication.JWT.verifierPublicKey";

1. Is this consistent with how other MP specs construct their MP Config keys? I don't think there's a lot of precedents, but MP OpenAPI seems to use mp.openapi.*, which is at least considerably shorter.

Good question. I thought there was a convention of using the package qualified, but I'll raise this question to the architecture group level to start a converstation on consistency.

 

2. Being able to set an entire public key literal is nice, but what about being able to set a file name / classpath resource name?

 

We need to define a sequence of tests to determine the type of value a string property represents; first is it an embedded pem, next is it a classpath resource, next uri... . Again probably another topic for the arch group discussion.

They do not interact as they should be mutually exclusive. If you specify the JWKS values, you are using an external key source that provides the verification info. I would not expect to fallback to a locally defined key if the JWKS cannot be loaded.

[Ladislav Thon]

Well I agree they should be mutually exclusive, but if the user specifies both, what's gonna happen? Will one of them be just ignored? Is it a deployment error?

LT

[Scott Stark]

I would vote for just logging a warning that the verifierPublicKey property will be ignored as it conflicts with the JWKS values. An exception is too severe, and silently ignoring it too lax.

[Ladislav Thon]

2018-04-12 17:29 GMT+02:00 Scott Stark <sst...@redhat.com>:

I would vote for just logging a warning that the verifierPublicKey property will be ignored as it conflicts with the JWKS values. An exception is too severe, and silently ignoring it too lax.

Sounds good to me.

LT

 

On Thursday, April 12, 2018 at 8:24:05 AM UTC-7, Ladislav Thon wrote:

2018-04-12 16:36 GMT+02:00 Scott Stark <sst...@redhat.com>:

On Thursday, April 12, 2018 at 6:20:41 AM UTC-7, Ladislav Thon wrote:

How do the last two properties interact with the verifierPublicKey ?

They do not interact as they should be mutually exclusive. If you specify the JWKS values, you are using an external key source that provides the verification info. I would not expect to fallback to a locally defined key if the JWKS cannot be loaded.

Well I agree they should be mutually exclusive, but if the user specifies both, what's gonna happen? Will one of them be just ignored? Is it a deployment error?

LT

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/acaee17a-73fb-46bc-8f0f-dc3bfe5bd040%40googlegroups.com.

[Rudy De Busscher]

So there is only 1 publicKey supported?

Shouldn't we allow for more than one and based on the kid value of the JWT header we can select the appropriate one.

If we need to use a 'storage for multiple keys' we can use the Java KeyStore or the JWKSet concept. Both having a 'name'/id for each key.

Rudy

On Friday, April 13, 2018 at 12:44:11 PM UTC+2, Ladislav Thon wrote:

2018-04-12 17:29 GMT+02:00 Scott Stark <sst...@redhat.com>:

I would vote for just logging a warning that the verifierPublicKey property will be ignored as it conflicts with the JWKS values. An exception is too severe, and silently ignoring it too lax.

Sounds good to me.

LT

 

On Thursday, April 12, 2018 at 8:24:05 AM UTC-7, Ladislav Thon wrote:

2018-04-12 16:36 GMT+02:00 Scott Stark <sst...@redhat.com>:

On Thursday, April 12, 2018 at 6:20:41 AM UTC-7, Ladislav Thon wrote:

How do the last two properties interact with the verifierPublicKey ?

They do not interact as they should be mutually exclusive. If you specify the JWKS values, you are using an external key source that provides the verification info. I would not expect to fallback to a locally defined key if the JWKS cannot be loaded.

Well I agree they should be mutually exclusive, but if the user specifies both, what's gonna happen? Will one of them be just ignored? Is it a deployment error?

LT

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Scott Stark]

If you using the verifierPublicKey there is only a single key supported. The verifierJwksURI to access a JWKS is what you would need to use for the scenario your describing. Are you also suggesting that we need to support configuration of a KeyStore?

[Rudy De Busscher]

Ok, if the URI can point to a JWKS we can have indeed multiple keys (I thought the URI would also point to a PEM) Then we can also use the OpenIdConnect Provider JWK set URL.

KeyStores are also very popular and can be read by Cora Java classes (no external library needed) So I think it would be a good addition to support them also. (By means of an SPI so that it becomes extensible ?)

Rudy

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/q00-CgU50xI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/22e01619-4d12-4ca1-9c73-b717d3375772%40googlegroups.com.

[Chunlong Liang]

It is difficult to maintain code in production environment if hard coding PEM document inside program, and you have to recompile code and/or restart server which is also impossible in production environment.

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.