search

OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.16k stars 599 forks source link

Support MicroProfile JWT 1.2 (part of MP 4.0) #11022

Closed Emily-Jiang closed 3 years ago

Emily-Jiang commented 4 years ago

Based on my conversation with MP JWT, MP JWT 1.2 will be released part of MP 4.0 Support the next MicroProfile JWT release 1.2 and baseline Jakarta EE8.

UFO: https://ibm.box.com/s/fi8gp4aag4t7goza3mq18umf6l2cv5tw Feature Test Summary (FTS): https://github.com/openliberty/open-liberty/issues/14978

Stories under this feature:

Doc updates:

Beta Blog Post:

GA Blog Post:

OL Guide updates:

Instructions:

TARGET COMPLETION DATE Before Development Starts or 8 weeks before Onboarding

Prerequisites

teddyjtorres commented 4 years ago

https://ibm.box.com/s/fi8gp4aag4t7goza3mq18umf6l2cv5tw

covener commented 4 years ago

Actions/Followups from first UFO review

teddyjtorres commented 4 years ago

Actions/Followups from first UFO review

teddyjtorres commented 4 years ago

@NottyCode Added "Design Approval Request". Thanks.

samwatibm commented 4 years ago

You've requested focal point approvals. For globalization approvals, 21001/2 translations are not back yet. Can you clarify whether there are any translations & I can approve now or whether it was sent & returned previously? Thanks.

teddyjtorres commented 3 years ago

@samwatibm Hi Sam. I believe the nlprops or translation content was delivered in 20.0.0.12 or before for this feature.

donbourne commented 3 years ago

Serviceability Approval Comment - Please answer the following questions for serviceability approval:

  1. WAD -- does the WAD identify the most likely problems customers will see and identify how the feature will enable them to diagnose and solve those problems without resorting to raising a PMR? Have these issues been addressed in the implementation? Yes - The WAD notes messages that have been added to cover new errors that are due to the new config attributes as well as mis-matches in the token and the server configs.

  2. Test and Demo -- As part of the serviceability process we're asking feature teams to test and analyze common problem paths for serviceability and demo those problem paths to someone not involved in the development of the feature (eg. L2, test team, or another development team).
    a) What problem paths were tested and demonstrated?

    • (builder) Mis-match between the sig alg (type) specified in the config vs the actual cert that is provided - 401 in response, CWWKS6029E in server log.
    • (builder) Try to encrypt a token with invalid mgmt key or key - 401 in response, CWWKS6060E and CWWKS6020E (this msg includes the specific issue from json4j) in server log.
    • (consumer) Mis-Match between sig alg used in token vs what is configured to process the token - 401 in response, CWWKS6029E in server log. (tested combinations of new and already supported signature algorithms (in both the supplied tokens as well as the consuming config)
    • (mpJwt) Mis-Match between sig alg used in token vs what is "configured" (via server.xml, env vars, system properties, or mp config properties) to process the token - 401 in response, CWWKS6029E in server log. (tested combinations of new and already supported signature algorithms (in both the supplied tokens as well as the consuming config)
    • (mpJwt) Mis-Match between sig alg (type) specified and the actual cert provided (tests created to specify these values via combinations of server.xml, env vars, system properties, and mp config properties) - 401 in response, CWWKS6029E in server log.
    • (mpJwt) Specify that token will be passed the authorization header, but, pass the token as a cookie (and vice-versa) ((ests created to specify the location via server.xml, env vars, system properties, and mp config properties) - 401 in response, CWWKS5522E in server.log
    • Config attributes that previously existed and that are now allowed to be specified in new ways are omitted or specified incorrectly to show that we get the same messages that we get when specifying them using the previous methods b) Who did you demo to? Test team (Tester reviews messages/responses from a user and sys admin perspective) c) Do the people you demo'd to agree that the serviceability of the demonstrated problem scenarios is sufficient to avoid PMRs for any problems customers are likely to encounter, or that L2 should be able to quickly address those problems without need to engage L3? Yes, the errors that occur with this feature would require handling by the system admin who should be able to understand what is happening and not require interaction with our L2 or L3.

  3. SVT -- SVT team is often the first team to try new features and often encounters problems setting up and using them. Note that we're not expecting SVT to do full serviceability testing -- just to sign-off on the serviceability of the problem paths they encountered. (refer to comment from hanczaryk - https://github.com/OpenLiberty/open-liberty/issues/11022#issuecomment-765396344) a) Who conducted SVT tests for this feature? b) Do they agree that the serviceability of the problems they encountered is sufficient to avoid PMRs, or that L2 should be able to quickly address those problems without need to engage L3?

  4. Which L2 / L3 queues will handle PMRs for this feature? Ensure they are present in the contact reference file and in the queue contact summary, and that the respective L2/L3 teams know they are supporting it. Ask Don Bourne if you need links or more info.

  5. Does this feature add any new metrics or emit any new JSON events? If yes, have you updated the JMX metrics reference list / Metrics reference list / JSON log events reference list in the Open Liberty docs?

mhldr commented 3 years ago

I've started an initial FAT review, it looks promising so far but there are a number of known that unresolved issues with the tests that I see you're aware of.

skasund commented 3 years ago

L2 has requested STE slides for this feature. The STE template can be found at the links below. You can use either one to create the education.

Slide Template: https://ibm.box.com/s/1an42g7zdgmaj84w7dft0indqfgi8ffm

Github Template: https://pages.github.ibm.com/WASL3/site/STE/about

Please upload the completed slides to the same 'STE Archive' BOX folder or provide me the Github link. Thanks!

donbourne commented 3 years ago

@teddyjtorres , please add comment with answers for serviceability approval (even if we don't have SVT complete yet it's helpful for seeing if everything else is ready for this approval)

teddyjtorres commented 3 years ago

Demo scheduled for February 2nd.

teddyjtorres commented 3 years ago

@steven1046 There is no Accessibility needed for this Epic. Please let me know if Serviceability approval can be resolved as "N/A", thanks.

teddyjtorres commented 3 years ago

@tevans78 or @cbridgha The demo was scheduled for the February 2nd's EOI. Please let me know if demo focal approval can be resolved. Thanks.

teddyjtorres commented 3 years ago

@Emily-Jiang @chirp1 The ID issue is https://github.com/OpenLiberty/docs/issues/3511.

hanczaryk commented 3 years ago

Here are the SVT answers for https://github.com/OpenLiberty/open-liberty/issues/11022#issuecomment-744497280

a) Who conducted SVT tests for this feature?
Brian Hanczaryk

b) Do they agree that the serviceability of the problems they encountered is sufficient to avoid PMRs, or that L2 should be able to quickly address those problems without need to engage L3? Yes, I agree that the serviceability of any problems encountered is sufficient to avoid PMRs, or that L2 should be able to quickly address those problems without the need to engage L3.

teddyjtorres commented 3 years ago

@donbourne

  1. WAD -- does the WAD identify the most likely problems customers will see and identify how the feature will enable them to diagnose and solve those problems without resorting to raising a PMR? Have these issues been addressed in the implementation? A: Yes

  2. Test and Demo -- As part of the serviceability process we're asking feature teams to test and analyze common problem paths for serviceability and demo those problem paths to someone not involved in the development of the feature (eg. L2, test team, or another development team).
    a) What problem paths were tested and demonstrated? b) Who did you demo to? c) Do the people you demo'd to agree that the serviceability of the demonstrated problem scenarios is sufficient to avoid PMRs for any problems customers are likely to encounter, or that L2 should be able to quickly address those problems without need to engage L3? A: Demo scheduled for EOI.

SVT Answered question 3.

  1. Which L2 / L3 queues will handle PMRs for this feature? Ensure they are present in the contact reference file and in the queue contact summary, and that the respective L2/L3 teams know they are supporting it. Ask Don Bourne if you need links or more info. A: WAS: L2 SEC Team and WAS L3: Security SSO

  2. Does this feature add any new metrics or emit any new JSON events? If yes, have you updated the JMX metrics reference list / Metrics reference list / JSON log events reference list in the Open Liberty docs? A: N/A. The feature does not add any new metrics or new JSON events.

teddyjtorres commented 3 years ago

@mhldr The TCK issues were resolved in https://github.com/OpenLiberty/open-liberty/pull/15606. We're ready for FAT approval. Thanks.

donbourne commented 3 years ago

@teddyjtorres , demo (from question 2) needs to explicitly cover showing the problem scenarios so that participants can comment on whether they think the serviceability of the demonstrated problems is sufficient. EOI demos often just cover the "green thread" path, so need to ensure you're demoing the problem paths too if that's where you're planning to get serviceability feedback.

ayoho commented 3 years ago

@skasund I've uploaded the STE slides for this feature to the STE Archive Box folder: https://ibm.box.com/s/lp6kczjtib15limcnb6krm2x3abw2xm0

skasund commented 3 years ago

@ayoho Thanks for the STE slides

teddyjtorres commented 3 years ago

@donbourne We will demo also to our L3, who has not been involved in the development or testing of the feature.

Our FAT tester also covered testing the messages.

teddyjtorres commented 3 years ago

@mhldr Please let us know if there is anything else needed for FAT approval. Thanks.

donbourne commented 3 years ago

@donbourne We will demo also to our L3, who has not been involved in the development or testing of the feature.

That sounds good - please update when you have completed the demo and indicate if the L3 team is happy with serviceability capabilities so I can sign off. I'm ok if minor serviceability issues are found as long as you show that you have opened issues to address them in the next release.

c00crane commented 3 years ago

@donbourne we have completed the demo with our L3 @barbj. She is happy with what was tested as well as messages/config descriptions with a few minor updates (issue: #15755). Let me know if you need anything else.