Added sandbox module to microprofile-jwt-auth, question about JWTAuthenticationMechanismDefinition

[Scott Stark]

I added a new sandbox module for testing out future implementation work, and I have started some work in there for testing of #62, standardize the issuer, signer public key, etc.

While going through that, I had a question about why we were talking about including the configuration information in the JWTAuthenticationMechanismDefinition ala:

x

/**
 * An example JWTAuthenticationMechanism bean
 */
@JWTAuthenticationMechanismDefinition(
    publicKey = "#{MPConfig.config[\"org.eclipse.microprofile.auth.JWT.signerPublicKey\"]}",
    acceptedIssuer = "#{MPConfig.config[\"org.eclipse.microprofile.auth.JWT.issuer\"]}"
)
@ApplicationScoped
public class SomeAuthMech {   

...
}

versus just using the MP config value injection directly into the auth bean:

/**
 * An example JWTAuthenticationMechanism bean
 */
@JWTAuthenticationMechanismDefinition(
)
@ApplicationScoped
public class SomeAuthMech {
    @Inject
    private Config config;
    @Inject
    @ConfigProperty(name = "org.eclipse.microprofile.auth.JWT.signerPublicKey")
    private String testKey;
    @Inject
    @ConfigProperty(name = "org.eclipse.microprofile.auth.JWT.signerPublicKey")
    private PublicKey keyFromPEM;
    @Inject
    @ConfigProperty(name = "org.eclipse.microprofile.auth.JWT.issuer")
    private String issuer;
    @Inject
    @ConfigProperty(name = "org.eclipse.microprofile.auth.JWT.issuers")
    private String[] issuers;
    @Inject
    @ConfigProperty(name = "org.eclipse.microprofile.auth.JWT.clockSkew", defaultValue = "30")
    private int clockSkew;

...
}

Arjan, what did you have in mind?

[Jean-Louis Monteiro]

Great!

Thanks Scott, I'll have a look

--

Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

--
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/b500edd1-b80c-4c6c-b021-73b702ba39a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Arjan Tijms]

Hi,

Sorry for the late reply I somehow missed that question.

When values are injected into the bean, how does the authentication mechanism know how to find those?

Perhaps the confusion is that "SomeAuthMech" is not the authentication mechanism itself. E.g. the developer doesn't have to code an entire authentication mechanism, since that is provided by MP JWT.

So just putting "@JWTAuthenticationMechanismDefinition" somewhere is identical to the current @LoginConfig(authMethod="MP-JWT"), but just with configuration for the key and issuer.

E.g.

@LoginConfig(

    authMethod = "MP-JWT",

    // Even though specified being only for HTTP Basic auth, JBoss/WildFly/Swarm mandates this

    // to refer to its proprietary "security domain" concept.

    realmName = "MP-JWT"

)

@ApplicationScoped

public class ApplicationInit {

    

   

}

vs

@JWTAuthenticationMechanismDefinition

@ApplicationScoped

public class ApplicationInit {

    

   

}

The "@JWTAuthenticationMechanismDefinition" here says exactly the same as the @LoginConfig. The bean "ApplicationInit" is just a place to put the annotation on.

Now the *actual* implementation of the JWT authentication mechanism (say "PayaraJWTAuthMechanismImpl"), could obtain the values using MP Config with the pre-determined key names; either using injection (if it itself is a CDI bean), or by using the lower level MP Config classes.

Having the config as attributes on the annotation would allow for more self discovery though (users can easily see which keys are mandatory and which other options are there).

Kind regards,

Arjan Tijms

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