utle
commented
1 year ago Meeting notes:
- Cover page: Typo planed >>> planned
p1: Fixed typo
- P 3: Question - Are LTPA keys unique per server instance? Tom noticed that the keys are stored in the container when created. We cannot leave an LTPA key in the container. Verify if the configure.sh is deleting the LTPA keys. Will take offline but that discussion needs result in updates on page 31 for container considerations.
p33: Added the following for container considerations:
Liberty operator will provide a better user experience
https://github.com/WASdev/websphere-liberty-operator/issues/380- P 7: Add JWT user >>> LTPA/JWT SSO user.
p7: Added JWT in bullets two
- P 12: Ut mentioned there was a typo, but I didn't catch it. He also mentioned that step 7 should return 200 code.
p12: Fixed typo.
- P 13: Question on how do you get the LTPA key2 and how this is updated in a container? Steps on page 11 talk about using config MBean to update. Operators don’t have any LTPA support to manage. Need day2 operation to recycle LTPA keys. Operator needs to handle across all pods. Open issue for operator. Does file monitoring help? Are there other patterns other than file based? tWAS uses a keystore. Should some other approach be used? Certificates might be able to be used? Could LTPA keys stored elsewhere?
p11: Added the following bullet:
Pre-req - Config update Trigger with mbean
p33: added the following for container considerations:
The Liberty operator will provide a better user experience by automating the steps defined in the p11
https://github.com/WASdev/websphere-liberty-operator/issues/380- Can you have a directory to where the keys are placed? Can config dropins be used? - not for keys, but could for the config pointing to the keys. But not a best practice if auto update is disabled.
This needs further discussion to be taken offline with updates to the cloud considerations page.
p19: Added monitoryDirectory attribute so they can place the LTPA keys file in the directory
-
P 19: Config page Used to verify incoming LTPA token Config naming updates requested - change:
-
verifyKeysFile to validationKeys name to fileName Discussion also on expirationDate. Should that be validUntil? It was asked whether it should be a duration, but that way the key file would have to be read to validate. No final decision there. Noted that the implementation will ignore expired keys. Discussion - Is expirationDate required? No There is a use case where expirationData is not required.
p19:
- Used element name validationKeys.
- Changed expirationDate to notUseAfterDate. It's optional.
- P 22: Add a config example in its proper context.
p20, p21 and p22: Added description for all examples
- In the first bullet, "ltpa" should be "LTPA/JWT" main bullet point is misleading - no auto generation. Concern that it doesn’t say which cookie it applies to - just SSO cookie Rename useContextRootAsCookiePath to useContextRootAsSSOCookiePath Question - is webAppSecurity per application - No - applies to all applications. Does changing the config values cause application restart? No
p24: Changed attribute useContextRootAsCookiePath to useContextRootAsSSOCookiePath
- P 31: Add container/operator considerations as previously brought up in the UFO discussion.
p33: Updated the slide with the container considerations issue.
-
P 33: Serviceability
-
The third bullet - message should be an INFO message (maybe warning)? Add another new ERROR message if the expirationDate value is bad and is not a valid ISO date. p 27: On the Beta slide - Add that new config properties need the IBM Beta tag.
p35:
- Changed the error message to information message.
- Added new error message for the validationKeys passed the specified notUseAfterData.
p29: Added beta tag.-
This might need a comeback after updates depending on the amount of changes that go in. Review with Alasdair after updates are made.
-
Notes from chat: from Adam Yoho (IBM) to Everyone: 10:35 AM file containing keys used to verify LTPA tokens from Adam Yoho (IBM) to Everyone: 10:36 AM from Joe Grassel (IBM) to Everyone: 10:40 AM So what happens should a key expire while an application in service is still using it? from Nichole Stewart (IBM) to Everyone: 10:41 AM The user is required to log back in. from Nichole Stewart (IBM) to Everyone: 10:42 AM Then the user gets an ltpa token from a valid key file. from Joe Grassel (IBM) to Everyone: 10:43 AM I mean more on the app config side, like what happens to the app at 2023-04-30 8am, especially when there are no more valid keys to use. Is there some kind of notification? It's not uncommon for people to forget to maintain their DNS registry or root certs, I'm sure this would be even more common from Eric Covener (IBM) to Everyone: 10:44 AM IIUC The first key is always used for signing/encryption and verifying/decryption. The expiration at the top level is how long the token is valid, not the key. from Ajay Reddy Karkala (IBM) to Everyone: 10:44 AM right. token expiration from Ajay Reddy Karkala (IBM) to Everyone: 10:55 AM useContextRootAsSSOCookiePath
p22:
- Changed useContextRootAsCookiePath to useContextRootAsSSOCookiePath
- Other comments are already addressed.
NottyCode
Zech-Hein
nstewart0206
tngiang73
chirp1
Description of the high level feature, including any external spec links:
Idea: make Liberty feature parity with traditional WAS to allow LtpaToken key rotation without having to restart the Liberty profile. LtpaToken SSO key rotation in Liberty currently requires a planned outage, unlike traditional WAS which can rotate the key on the fly. The traditional WAS administrative console setting controls for automatic key re-generation filled a function in high-security sites to make mounting a session attack prohibitively costly. The feature created a new key without requiring any administrator intervention, nor restarting of WAS profiles. There is no way to re-generate the LTPA keys on-demand without a Liberty profile restart so it can be automated out-of-band of Liberty; and even that procedure is not shown in the product documentation as far as I can tell. Thus, using third-party information sources and not the product documentation, as best as I can tell the only way to implement a high-security configuration with Liberty profiles without interrupting the application is only under applications like IBM Workload Scheduler that support session persistence. We would have to architect a load-balancer-fronted multiple-master configuration that fails over to a standby, transparently carrying sessions with it, drop the target master from the load balancer rotation, shut down the profile, force the password change of the LTPA key, start up the profile which generates a new LTPA key, and then return the node to the load balancer rotation. That's a big increase in operational complexity to rotate the LTPA key with the same no-restart functionality as traditional WAS.
When complete & mandatory, add links to the UFO (Upcoming Feature Overview) document, FTS (Feature Test Summary), blogs post issues(s), and Aha (externally raised RFEs):
UFO: https://ibm.box.com/s/5xphq0qr7mwhc1cu1riaqdm0uoygqvsd
FTS: https://github.com/OpenLiberty/open-liberty/issues/25669
Beta Blog Post (if applicable): https://github.com/OpenLiberty/open-liberty/issues/26138
Blog Post: https://github.com/OpenLiberty/open-liberty/issues/27048
Aha:
List of Steps to complete or get approvals / sign-offs for Onboarding to the Liberty release (GM date)
Instructions:
Design
Before Development Starts or 8 weeks before Onboarding
Before proceeding to any items below (active development), this feature MUST be prioritized on the backlog, and have been socialized (e.g., UFO Review). Follow the Feature and UFO Approval Process.
Development
When active development has begun
Beta
In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.
Beta Code
kind=beta,ibm:beta,ProductInfo.getBetaEdition()target:betaand the appropriatetarget:YY00X-beta(where YY00X is the targeted beta version).release:YY00X-beta(where YY00X is the first beta version that included the functionality).Beta Blog (Complete 1.5 weeks before beta eGA)
Legal
3 weeks before Onboarding
Translation
3 weeks before Onboarding
Feature Complete
2 weeks before Onboarding
Focal Point Approvals
2 to 1 week before Onboarding
You MUST have the Design Approved or No Design Approved label before requesting focal point approvals.
All features (both "Design Approved" and "No Design Approved")
"Design Approved" features
Ready for GA
1 week before Onboarding
1 week before GA
Other deliverbles