MP-JWT TCK docs talk about group-to-role mapping, but test for that never executed

[Arjan Tijms]

The MP-JWT TCK readme talks about group to role mapping in the "Role Mapping" section.

The tck-full-suite.xml, used by the container-full Maven profile, includes the "ee-security-optional" group, which includes the role mapping test.

The "extended-tests" section of tck-full-suite.xml includes this group, but only adds the classes EjbTest, SubjectTest and ServletTest, while the only test in the "ee-security-optional" group is in the RolesAllowedTest class.

Even though the test is optional, the way things are described and set-up hints at this being a bug/oversight. See the extended-tests section below:

<test name="extended-tests" verbose="10">

        <groups>

            <define name="extended-groups">

                <include name="arquillian" description="Arquillian internal"/>

                <include name="ejb-optional" description="EJB container integration tests"/>

                <include name="jacc-optional" description="JACC API integration tests"/>

                <include name="servlet-optional" description="Servlet container integration tests"/>

                <include name="ee-security-optional" description="Java EE security feature tests"/>

            </define>

            <define name="excludes">

                <include name="debug" description="Internal debugging tests" />

            </define>

            <run>

                <include name="extended-groups" />

                <exclude name="excludes" />

            </run>

        </groups>

        <classes>

            <class name="org.eclipse.microprofile.jwt.tck.container.ejb.EjbTest" />

            <class name="org.eclipse.microprofile.jwt.tck.container.jacc.SubjectTest" />

            <class name="org.eclipse.microprofile.jwt.tck.container.servlet.ServletTest" />

        </classes>

    </test>

[John D. Ament]

Arjan,

This is just a doc issue right?  Each impl still has to create their own tck-suite.xml file to run the tests.

I say continue to report it on github, and when we next prep for a release of JWT we can roll it in.

John

[Arjan Tijms]

Hi,

On Thursday, December 21, 2017 at 2:14:20 PM UTC+1, John D. Ament wrote:

Arjan,

This is just a doc issue right?  Each impl still has to create their own tck-suite.xml file to run the tests.

Hmmm, I might have missed something, but why is it needed to create an individual tck-suite.xml?

I just executed:

mvn -Pcontainer-full -Dtck.container.groupId=fish.payara.microprofile -Dtck.container.artifactId=jwt-auth-tck -Dtck.container.version=4.1.2.181-SNAPSHOT test

and got:

[INFO] Tests run: 118, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 16.083 s - in TestSuite

[INFO] 

[INFO] Results:

[INFO] 

[INFO] Tests run: 118, Failures: 0, Errors: 0, Skipped: 0

Which seems to imply it runs all tests there are (using tck-full-suite.xml)

For the mandatory tests I executed:

 mvn -Pcontainer -Dtck.container.groupId=fish.payara.microprofile -Dtck.container.artifactId=jwt-auth-tck -Dtck.container.version=4.1.2.181-SNAPSHOT test

and got:

[INFO] Tests run: 112, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.11 s - in TestSuite

[INFO] 

[INFO] Results:

[INFO] 

[INFO] Tests run: 112, Failures: 0, Errors: 0, Skipped: 0

This seems to imply it runs all mandatory tests (using tck-base-suite.xml).

It's not that you *have* to create your own tck-suite.xml right?

The only thing I noticed as mentioned was that with tck-full-suite.xml 1 test is not being executed; it seemingly attempts to include that test by including the right group, but then it looks like it 'forgets' to also include the right class.

Kind regards,

Arjan Tijms

[Arjan Tijms]

Any more thoughts about this?

[Werner Keil]

Hi Arjan,

After helping another client with things like MP Config and at least outlining how they may use JSR 375 and Soteria in the future (their current JASPIC-based security API mimicks a few aspects of Soteria and we may have to stick with that till they update it to Soteria or Java EE 8) I have another usecase between MicroProfile OpenAPI and JWT. Where expecially a combination with JWT, JSR 375 and role extensions to OpenAPI/Swagger are of great interest.

Do synergies between MP-JWT and MP-OpenAPI already exist or planned?

Thanks and Regards,

Werner

[Scott Stark]

The role mapping test is the RolesEndpoint#needsGroup1Mapping(SecurityContext) endpoint which is accessed by the RolesAllowedTest#testNeedsGroup1Mapping() unit test. This is included in the tck-base-suite.xml descriptor that is part of the tck/tck-base-suite.xml. That test requires that the one of RolesEndpoint.json groups claim:

"groups": [
    "Echoer",
    "Tester",
    "group1",
    "group2"
],

is mapped to a Group1MappedRole role.

You can run test without creating your own tck-suite.xml test descriptor as you show. Both approaches are described in the tck/README.adoc.

[Werner Keil]

So is it recommended to use "groups" only?

Test data from https://github.com/eclipse/microprofile-jwt-auth/tree/master/tck/src/test/resources

has both

"roles": [
	"Echoer"
	],

as well as the mentioned groups.

I currently use the same lower-level API as CumuluzEE does (the one by Auth0) so it is up to me whether I use groups, roles or both.

Because the underlying mechanism is RestEasy which is not yet aligned with JSR 375/Soteria (likely won't till we do that in Jakarta EE "Soteria.next") I decided to use that instead of the Soteria AuthenticationMechanism for now.

Werner

[Scott Stark]

Yes, only the "groups" claimed is defined in the current specification. A "roles" claim would be a custom claim that would not be portable across implementations. The use of the "roles" claim in the TCK should be dropped to avoid confusion.