MP JWT Meeting Notes

MP JWT RBAC Auth Notes

Sep 1, 2017

Attendees:

Scott Stark

David Blevins

Michael Chen

Chunlong Liang

John Ament

Agenda:

Discuss TCK and specification questions as final prep for the 1.0 release.

We had a long discussion around confusion about what the spec was trying to convey with the @RequestScoped and @Dependent scoping on the JsonWebToken and it’s associated claim values. The ultimate conclusions that we arrived at are the following:

1. The JsonWebToken is @RequestScoped
2. The associated claim values need @Dependent scoping to allow any of the following uses to work:

1. @Inject @Claim(“iss”) String issuer;
2. @Inject @Claim(“iss”) Provider<String> issuer;
3. @Inject @Claim(“iss”) Instance<String> issuer;

3. MP-JWT implementations must validate that the usage of 2a is occurring in a @RequestScoped context, and if not:

1. Issue a DeploymentException if the usage context is either @ApplicationScoped or @SessionScoped
2. Issue a warning for any other scope. This warning should be suppressible via an implementation mechanism.

There certainly is concern with regard to the finality of the TCK in the timeframe that the API and specification are due. The plan is to have an initial TCK release and continue to iterate with maintenance releases post the API/specification release.

There was also concern about really being able to cement a final 1.0 API and specification without feedback from JavaOne. It will be an issue item raised for next week’s MP community call.

Aug 25, 2017

Attendees:

Scott Stark,

David Blevins

We reviewed the current TCK and API. On the API front, we discussed moving the @LoginConfig annotation from the org.eclipse.microprofile.jwt package to a more general org.eclipse.microprofile.auth package as well as cleaning up the language around the authMethod

Since we are currently not validating any authentication method other than MP-JWT.

David suggested breaking up the tests into more relevant names that reflect functionality as currently they are grouped primarily into the RolesAllowed test. We will do that.

We also discussed supporting the injection of JSON-P javax.json.JsonValue subtypes as a way to avoid having to use a ClaimValue wrapper. We will create tests to explore that.

Aug 18, 2017

Attendees:

Scott Stark,

Michael Chen,

Chunlong Liang,

Agenda:

Review the current proposed final API and spec

• microprofile-jwt-auth-1.0-RC4
• microprofile-jwt-auth-api-1.0-RC4-javadoc.jar
• microprofile-jwt-auth-api-1.0-RC4-sources.jar
• Microprofile-jwt-auth-spec.pdf

Discuss the types of ClaimValue injections

• ClaimValue<json-b-type>
• ClaimValue<Optional<json-b-type>

Discuss the exposed token claim types

• Use of Set<String> vs jsonb List<String> for an untyped mapping of a JSON array type (aud, groups claims vs a non-standard array type claim)

• Jsonb does require the ability to bind to any collection, so Set<String> can be required

Discuss the scope of optional Java EE container TCK tests

We discussed the current final API proposal and after discussing the question of exposed jsonb types, decided that we are good for the 1.0 release.

Aug 11, 2017

Attendees:

Scott Stark,

Michael Chen,

Chunlong Liang,

David Belvins

Alasdair Nottingham  

Agenda:

Review the proposed API changes:

• JWTPrincipal updates
• @LoginConfig introduction
• JWTClaimType introduction

Review the TCK status:

• Updated tokens-se and container profiles control the scope of tests and integrate with a container under test via a provided container tck harness artifact
• Progress with verifying a tck harness artifact other than wildfly-swarm
• Current scope of tests
• Need for a container-optional profile that includes tests for the recommended optional spec behaviors

Review the specification status:

• Updates for CDI requirements around injection of JWTPrincipal
• Base set of required container API integration is limited to JAX-RS
• Other container API integration moved to a recommended but optional section

Discuss injection of JWT claims

The current repo with all discussed changes is:

https://github.com/MicroProfileJWT/microprofile-jwt-auth

There is a prototype release with the spec pdf here:

https://github.com/MicroProfileJWT/microprofile-jwt-auth/releases/tag/Aug11Call

We went through the current API proposals and decided on updating the names of the types under the org.eclipse.microprofile.jwt package to the following:

JWTClaim -> Claim

JWTClaimPrincipal -> ClaimValue

JWTClaimType -> Claims

JWTPrincpal -> JsonWebToken

With both ClaimValue and JsonWebToken implementing the java.security.Principal interface.

There was a desire to change the package of the LoginConfig annotation to something other than org.eclipse.microprofile.annotation. (We could just move this to the org.eclipse.microprofile.jwt package for 1.0) David pointed out that for @RequestScoped information like JWT claims, we cannot directly inject to a String, so the current example usage will be updated to inject the ClaimValue.

In terms of the value types returned from the JsonWebToken#getClaim(String) method, Alasdair described the desire to have a clear mapping from the JSON type to the returned type, even for private claims. In order to validate this, the TCK will include a JWT that includes a claim not covered in the Claims enum set, for every JSON-B data type and validate that the returned type is consistent with the JSON-B mapping.

There was a discussion around the usage of the LoginConfig annotation on the JAX-RS Application object, and David brought up that you can have multiple JAX-RS Applications in a deployment archive. The question this raised is what happens if there are multiple LoginConfig annotations on these. Scott argued that the deployment archive should be treated as a logical deployment unit with a single authentication mechanism and realm. Alasdair said you could deal with this via the equivalent of a servlet filter and handle authentication based on the application paths. There were concerns about what impacts this might have on the underlying container implementation. It was decided that the TCK would only test one secured root context path with an associated LoginConfig in a given application under test, and the implementation under test would have to support a way of configuring the authentication mechanism for that path. We would not explicitly address the handling of multiple LoginConfig annotations in a given deployment unit.

We ended the call there due to time with the action item to circulate the current API changes and make a push to finalize the API by next Friday’s call. There is a need to finalize the API by that point in order to support a 1.2 release by JavaOne. We talked about needing to get a final API out for feedback and that we could introduce significant changes in a 1.1 release if needed.

Scott said he would be actively driving the finalization of the API and specification in the forums the following week to try to meet that goal.

Aug 4, 2017

Attendees:

Scott Stark,

Michael Chen,

Chunlong Liang,

David Belvins

Caesar

Agenda:

Discuss open issues

Issues with outstanding pull requests:

• The JWTPrincipal#getGroups() method should simply return the JWT "groups" claim
• There is no ASLv2
• Don't rely on full Java EE API
• Fix group Ids/artifact Ids

Issues with comments:

• Don't rely on Keycloak
• TCK should only provide tests

Discuss open pull requests

        https://github.com/eclipse/microprofile-jwt-auth/pull/11

Discuss current TCK status

We had a long discussion around the need for both the “roles” and “groups” token claims. The main agreement was there really was no need for two sets of claims as most containers supported a one-to-one mapping from a IDP group to an application role, and the less specific the name of the grant the more likely it could be used across applications. We decided we needed to enumerate the usecases better in the spec and back this up with unit tests illustrating the associated container API mappings. Population of the javax.security.auth.Subject was mentioned as something needing more definition.

We had a discussion about what should be in the TCK and to issue #6, reliance on Keycloak dependencies. David pointed out a more neutral Nimbus JOSE + JWT that could be used to address this, and Scott agreed to switch to it for the current token generation requirement. This group was not opposed to having vendor profiles in the TCK, but we will continue the discussion on Tuesday’s full MP hangout call.

There was a question on consistency raised regarding the JWTPrincipal#getAudience() accessor method that is returning a String[] rather than a Set<String> as the roles and groups accessors do. Scott said that he agreed it should be changed to a Set<String>.

July 28, 2017

Attendees:

Scott Stark,

Michael Chen,

Chunlong Liang,

Arjan Tijms

 

Agenda:

1. Review the current JWTPrincipal API
2. Discuss the need for a unique_username vs requiring uniqueness on the preferred_username.
3. Discuss TCK plans
4. Discuss merging the current PR into the eclipse repo

We had a discussion around whether the existing OIDC preferred_username was a sufficiently unique claim in actual fact for use as the unique name across applications. There was concern that it would not always be sufficient, and due to the fact that OIDC specifically stated it must not be treated as such, the decision was made to require a new upn claim. However, the spec will define a fallback behavior that will use the preferred_username if a upn claim does not exist so that in domains where the preferred_username can meet the uniqueness requirement, it can be utilized as a proxy for upn.

Chunlong pointed out that there is really no need for a explicit getUniqueUsername() accessor since this will be the Principal.name() value, so that method of the JWTPrincipal will be dropped.

There was a discussion about having a user friendly name, and Scott pointed out that with the addition of the getOtherClaimNames() and getOtherClaim(String) methods to the JWTPrincipal interface, other OIDC claims like name, nickname,  given_name, family_name, email, etc could be used, but that they were not required for the RBAC functionality needed by the MicroProfile.

Arjan asked about how roles were going to be sufficiently unique across applications and pointed out that often the authentication provider has no application role information. Scott said that the details of how one authenticated to an IDP to generate an MP JWT were up to the security domain manager, and in the case where say one used Google to authenticate, application roles would have to be brought in from another source at the IDP in order to have the information to generate the JWT. In the case where one would not have agreement across applications on the deployment roles, there would have to be agreement on a set of common groups that would then be mapped to the deployment roles by the application containers.

At this point we have agreed on the JWT RBAC 1.0 claims and JWTPrincipal interface.

Scott described the plans for the TCK to start with the unit tests created for the WildflySwarm MP-JWT authentication integration and generalize them using the model used by the javaee-samples project where common application code was run with vendor specific profiles. Someone wanting to run the TCK can either choose an existing profile or add a new one for a new container.

Scott indicated that he would update the current API and specification for the changes decided on today, and then would post an update to the MicroProfile groups asking that the outstanding PR be merged so that the proposed 1.0 code was available in the main repository.

July 21 2017

Attendees:

Scott Stark

Rudy De Busscher

John Clingan

Agenda:

1. General discussion of current state of the specification.

2. Answer questions on the specification or the proposed API/RI.

3. Get into specifics regarding:

 a. The need for a unique_username vs requiring uniqueness on the preferred_username.

 b. Is there agreement on the proposed resource_access encoding of service specific groups/roles?

4. Next steps:

 a. TCK

 b. DefaultServerModule for Java EE 7.

 c. Additional test coverage.

Rudy asked why the current API was depended on the JSR-375 API. Scott said that was just a starting point and that the base JWTPrincipal interface only depended on the java.security.Principal interface, and the abstract JWTCallerPrincipal which extends javax.security.enterprise.CallerPrincipal could be broken out into a separate jar.

John was concerned that the MP 1.2 September deadline was tight. Scott said it really depended on agreement of the claims the JWT was to carry. Once that is done, the API is done and the only work left is on the TCK.

Action items:

- Move the JWTCallerPrincipal into the reference implementation for now, possibly creating another api that extends both the base MP api and the 375 api if demand warrants.

- Scott will create a thread to vote on the current claim proposals and contact the parties that have expressed interest to participate.