MP-config usage by other features, some consistency questions

[Scott Stark]

So as we are beginning to define externalizing configuration of MP-JWT behaviors using MP-config, the first couple of questions are around consistency. The first being what convention is used for the property names. I had suggested using package scoped names such as "org.eclipse.microprofile.authentication.JWT.verifierPublicKey", but it was pointed out the MP-openapi uses "mp.openapi.*" style names. We need to define what convention the various MP-* projects need to follow.

The second question is around interpretation of a given string property value. For example, is it a string literal, is it a classpath resource name, is it a URI/URL, ...

Are we going to define how to go about interpreting a given value and possibly provide utility classes to help with this?

Ultimately these are topics we need to take up in the architecture group and create guidelines for.

[Emily Jiang]

Hi Scott,

1. As for property name convention, it is good to define a guidance on the rules. For FT, we have the property starting with FT_. We did not choose . as the separator, because the . is an invalid character for environment variable names. With the release of MP config 1.3, we have provided a mapping rule and solved this limitation.

2. for the config property, I don't quite understand what you are trying to propose. The property string value can represent URL, URI, int, etc. In the user code, when they use config.getValue(configName, URI.class), it will be a URI. Perhaps, I completely misunderstand what you are trying to convene. Please explain with an example.

Thanks
Emily

[Scott Stark]

On Thursday, April 12, 2018 at 10:22:18 AM UTC-7, Emily Jiang wrote:

Hi Scott,

1. As for property name convention, it is good to define a guidance on the rules. For FT, we have the property starting with FT_. We did not choose . as the separator, because the . is an invalid character for environment variable names. With the release of MP config 1.3, we have provided a mapping rule and solved this limitation.

I'm not seeing this jump out at me when I look at the current spec. Can you point me to what the mapping rule details are?

 

2. for the config property, I don't quite understand what you are trying to propose. The property string value can represent URL, URI, int, etc. In the user code, when they use config.getValue(configName, URI.class), it will be a URI. Perhaps, I completely misunderstand what you are trying to convene. Please explain with an example.

So for the verifierPublicKey property value, there are 3 natural usecases:

Usage 1, the literal PEM encoded public key:

org.eclipse.microprofile.authentication.JWT.verifierPublicKey=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlivFI8qB4D0y2jy0CfEqFyy46R0o7S8TKpsx5xbHKoU1VWg6QkQm+ntyIv1p4kE1sPEQO73+HY8+Bzs75XwRTYL1BmR1w8J5hmjVWjc6R2BTBGAYRPFRhor3kpM6ni2SPmNNhurEAHw7TaqszP5eUF/F9+KEBWkwVta+PZ37bwqSE4sCb1soZFrVz/UT/LF4tYpuVYt3YbqToZ3pZOZ9AX2o1GCG3xwOjkc4x0W7ezbQZdC9iftPxVHR8irOijJRRjcPDtA6vPKpzLl6CyYnsIYPd99ltwxTHjr3npfv/3Lw50bAkbT4HeLFxTx4flEoZLKO/g0bAoV2uqBhkA9xnQIDAQAB

Usage 2, a classpath resource reference:

org.eclipse.microprofile.authentication.JWT.verifierPublicKey=/somepath/xzykey.pem

Usage 3, an external URL reference:

org.eclipse.microprofile.authentication.JWT.verifierPublicKey=http://somepath/xzykey.pem

So I understand one can ask for the config property as a given type, but it is up to the user to choose how they want to encode the value, so the feature consuming the value has to try various types in some order. I have seen frameworks use a prefix to indicate the context for interpretation of a string value. For example:

org.eclipse.microprofile.authentication.JWT.verifierPublicKey=[raw]MIIBIjANBgkqhkiG9w0...
org.eclipse.microprofile.authentication.JWT.verifierPublicKey=[classpath]/somepath/xzykey.pem
org.eclipse.microprofile.authentication.JWT.verifierPublicKey=[url]http://somepath/xzykey.pem

The goal being, that I can write a custom config Converter like the following:

/**
 * A custom configuration converter for {@linkplain PublicKey} injection using
 * {@linkplain org.eclipse.microprofile.config.inject.ConfigProperty}
 */
public class PublicKeyConverter implements Converter<PublicKey> {
    /**
     * Converts a string to a PublicKey by loading it as a classpath resource
     * @param value - the PEM encoded string value to convert
     * @return the PublicKey loaded as a resource
     * @throws IllegalArgumentException - on failure to load the key
     */
    @Override
    public PublicKey convert(String value) throws IllegalArgumentException {
        PublicKey pk;
        try {
            pk = decodePublicKey(value);
        }
        catch (Exception e) {
            IllegalArgumentException ex = new IllegalArgumentException("Failed to parse: "+value);
            ex.initCause(e);
            throw ex;
        }
        return pk;
    }
}

that does not have to deal with the details of how the value argument was specified in a given config source. The converter just gets the raw PEM encoded string. Make sense?

[Emily Jiang]

Hi Scott,

> I'm not seeing this jump out at me when I look at the current spec. Can you point me to what the mapping rule details are?

 
It will be in the upcoming Config 1.3 release. The issue being done is here: https://github.com/eclipse/microprofile-config/issues/264

>So for the verifierPublicKey property value, there are 3 natural usecases:

Thanks for the detailed example! yes, I think in this case you can define this naming convention for the value so that impl of JWT can provide a customer converter to get you the desired type.

Log all of this in our infrastructure doc so that we can discuss and agree on the rules.

Thanks
Emily