Closed jtmulvey closed 4 years ago
The use case here is that the customer has a custom login module that wants to get the unique username information from the ltpaToken in their login module - before the subject is created. The username is then used to fill in the information required to create the subject.
Thanks Ajay. Here's one simple use case. 1) USER1 logs in in Liberty in POD1 and is authenticated by the 3rd party login module. 2) An LTPA token is created for USER1 and returned as LtpaToken2 cookie 3) POD1 fails or router passes request to POD2 for the first time and LTPA cookie goes to 3rd party login module in POD2 4) 3rd party login module has LTPA cookie only to work with and wants to derive the user name in order to assert USER1 and create a new Subject for USER1 in POD2
Instructions:
[x] POC Design / WAD Review Scheduled (David Chang) or N/A.
[x] POC Design / WAD Reviewed (Feature Owner) or N/A.
[x] Complete any follow-ons from the POC Review.
[x] Design / WAD Approval (Alasdair Nottingham) or N/A.
[ ] No Design / No WAD Approval (Arthur De Magalhaes - cloud / Alasdair Nottingham - server) or N/A.
[ ] SVT Requirements identified. (Epic owner / Feature owner with SVT focal point)
[ ] ID Requirements identified. (Epic owner / Feature owner with ID focal point)
[ ] Create a child task of the epic entitled "FAT Approval Test Summary". Add and fill in the template as described here: https://github.ibm.com/was-liberty/WS-CD-Open/wiki/Feature-Review-(Feature-Test-Summary-Process)
[ ] Identify all open source libraries that are changing or are new. Work with Legal Release Services (Cass Tucker or Release PM) to get open source cleared and approved. Or N/A. (Epic Owner). New or changed open source impacts license and Certificate of Originality.
[ ] All new or changed PII messages are checked into the integration branch, before the last translation shipment out. (Epic Owner)
[x] Implementation complete. (Epic owner / Feature owner)
[x] All function tests complete. Ready for FAT Approval. (Epic owner / Feature owner)
[ ] Review all known issues for Stop Ship. (Epic owner / Feature owner / PM)
Prereq: You must have the Design Approved or No Design Approved label on the GitHub Epic.
[x] Accessibility - (G Scott Johnston). Accessibility testing is complete or N/A. Approver adds label focalApproved:accessibility to the Epic in Github.
[ ] FAT Liberty SOE - (Kevin Smith). SOE FATS are running successfully or N/A . Approver adds label focalApproved:fat to the Epic in Github.
[x] Globalization (Sam Wong - Liberty / Simy Cheeran - tWAS). Translation is complete or N/A. TVT - complete or N/A. Approver adds label focalApproved:globalization to the Epic in Github.
[x] ID - (Kareen Deen). Documentation work is complete or N/A . Approver adds label focalApproved:id to the Epic in Github.
[x] Performance - (Jared Anderson). Performance testing is complete with no high severity defects or N/A . Approver adds label focalApproved:performance to the Epic in Github.
[x] Serviceability - (Don Bourne). Serviceability has been addressed.
[x] STE - (Swati Kasundra). STE chart deck is complete or N/A . Approver adds label focalApproved:ste to the Epic in Github.
[x] SVT - (Greg Ecock - Cloud, Brian Hanczaryk- APS). SVT is complete or N/A . Approver adds label focalApproved:svt to the Epic in Github.
[x] Demo - (Liberty only - Tom Evans or Chuck Bridgham). Demo is scheduled for an upcoming EOI. Approver adds label focalApproved:demo to the Epic in Github.
[ ] No Stop Ship issues for the feature. (Epic owner / Feature owner / Release PM)
[ ] Ship Readiness Review and Release Notes completed (Epic owner / Feature owner / Release PM)
[ ] Github Epic and Epic's issues are closed / complete. All PRs are committed to the master branch. (Epic owner / Feature owner / Backlog Subtribe PM)
[ ] OL Guides - (Yee-Kang Chang). Assessment for OL Guides is complete or N/A.
[ ] WDT - (Leonard Theivendra). WDT work complete or N/A.
[ ] Blog article writeup (Epic owner / Feature owner / Laura Cowen)
Design review follow-on actions:
No AVT required. This feature does not change the UI or add any new UI. This feature adds a new API to provide a way to programmatically retrieve the user name from the LTPA token.
Design review follow-on actions:
- on the "as-is" or "technical background" slide, be more specific on what scenario isn't working, i.e. it just says that we need an API, but it doesn't say what scenario would be enabled if the API is provided
- developer experience slide does apply and should be filled in with the requested information from the slide notes
- system test slide, please say explicitly that this was discussed with system test and that they don't believe it is necessary
- migration impact slide does apply and should be filled in with the requested information from the slide notes (for example, the migration toolkit has work here)
Completed
Hi @sabolo, @ayoho Here is the Feature FAT Summary: https://github.com/OpenLiberty/open-liberty/issues/11664
Serviceability Approval Comment - Please answer the following questions for serviceability approval:
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?
This is an API that port from tWAS to Liberty.
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?
Test Null tokenByte and invalid token
b) Who did you demo to?
`The end of iteration demo `
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?
`No comments from demo `
SVT team agreed there is no need for SVT . FAT tests covered positive and negative.
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.
Handled by WL3Security.
L2 has requested STE slides for this feature. The STE template can be found at the link 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. Thanks!
Hi @skasund, here is the STE. https://ibm.box.com/s/51li86zy04pj20tldlwcftjpc3xy6vs0
@utle Thanks for the STE slides. I've approved the feature.
@utle , please see above serviceability approval comment re: serviceability approval.
@donbourne , I updated it. Thanks.
granting serviceability approval as this is just an API change.
From a discussion with Ut, no ID is required. Approving.
Lite-weight third party authentication (LTPA) tokens in Liberty today offer a way to support single-signon out of the box. LTPA tokens can be shared between instances of Liberty provided the ltpa.keys file is shared. There are a number of instances where it would be useful to introspect the LTPA token in order to retrieve the user name. This feature adds a new API to provide a way to programmatically retrieve the user name from the LTPA token.
Associated RFE: https://www.ibm.com/developerworks/rfe/execute?use_case=viewChangeRequest&CR_ID=137428
WAD: https://ibm.box.com/s/mk3maek6fc4y3gyd6akjqgpy8ls9zrkt