Allow the SameSite attribute to be set on a Cookie

[pnicolucci]

We need to investigate and design a way to add the SameSite attribute to cookies added via the Servlet API by applications as well as the session Cookie created by Open Liberty. In addition we should investigate any other cookies that we set as part of the runtime and determine if we need to add a configuration for SameSite to those cookies as well.

Jakarta Servlet Spec Issue: jakartaee/servlet#175

RFE Link: https://www.ibm.com/developerworks/rfe/execute?use_case=viewChangeRequest&CR_ID=119022

Current options documented here: https://www.ibm.com/support/pages/browser-changes-samesite-cookie-handling-and-websphere-application-server

UFO: https://ibm.box.com/s/oeiwm7h19iy9is55uvx05yipb4dpvrzb

---

List of Steps to complete or get approvals / sign-offs for Onboarding to the Liberty release (GM date)

Instructions:

• Do the actions below and mark them complete in the checklist when they are done.
• Make sure all feature readiness approvers put the appropriate tag on the epic to indicate their approval.

---

TARGET COMPLETION DATE Before Development Starts or 8 weeks before Onboarding

• POC Design / WAD Review Scheduled (David Chang) or N/A.
• POC Design / WAD Reviewed (Feature Owner) or N/A.
• Complete any follow-ons from the POC Review.
• 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)

---

TARGET COMPLETION DATE 3 weeks before Onboarding

• 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.

---

TARGET COMPLETION DATE ** 3 weeks before Onboarding**

• All new or changed PII messages are checked into the integration branch, before the last translation shipment out. (Epic Owner)

---

TARGET COMPLETION DATE 2 weeks before Onboarding

• Implementation complete. (Epic owner / Feature owner)
• All function tests complete. Ready for FAT Approval. (Epic owner / Feature owner)
• Review all known issues for Stop Ship. (Epic owner / Feature owner / PM)

---

APPROVALS with TARGET COMPLETION DATE 2 to 1 week before Onboarding

Prereq: You must have the Design Approved or No Design Approved label on the GitHub Epic.

• 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.
• Globalization (Marika Joannidis - 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.
• ID - (Kareen Deen). Documentation work is complete or N/A . Approver adds label focalApproved:id to the Epic in Github.
• 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.
• Serviceability - (Don Bourne). Serviceability has been addressed.
• STE - (Swati Kasundra). STE chart deck is complete or N/A . Approver adds label focalApproved:ste to the Epic in Github.
• SVT - (Greg Ecock - Cloud, Brian Hanczaryk- APS). SVT is complete or N/A . Approver adds label focalApproved:svt to the Epic in Github.
• 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.

---

TARGET COMPLETION DATE 1 week before Onboarding

• 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)

---

NOT REQUIRED FOR A FEATURE

• OL Guides - (Yee-Kang Chang). Assessment for OL Guides is complete or N/A.
• WDT - (Leonard Theivendra). WDT work complete or N/A.

---

Related Deliverables TARGET COMPLETION DATE General Availability

• Blog article writeup (Epic owner / Feature owner / Laura Cowen)

---

UFO Socialization Minutes

• Action: SameSite attribute= None, Security Session attribute should be added automatically. (Ajay Reddy, Jim Mulvey) -> Updated UFO and implementation.
• Issue: WebApplSecurity can not override Security attribute in server.xml.(Ajay Reddy, Jim Mulvey, Chinlong Liang)
• action: "Application Level setting take precedence over server.xml setting" can not be supported by LTPA cookie.
  • We can not support Application Security override server.xml for SSO token in this release.(Alasdair Nottingham, Jim Mulvey, Ajay Reddy, Chinlong Liang Paul Nicolucci)
    • We will continue to hold offline discussion for this issue and implement the Application level configuration over server.xml in the future release with
      a staging approach.
• action: Document that SetCookieAttribute API and RemoveCookieAttribute API are Internal API. (Alasdair Nottingham, Paul Nicolucci)) : Determine it is SPI, updated UFO
  Note: Document that SetCookieAttribute API only support SameSite attribute in this release.
  No change to the Remove CookieAttribute API definition in this release but we will change it become more general in the future release.
  Opened Epic for this follow on work: Allow the SameSite attribute to be set on a Cookie - Application Level Configuration #11091

[chirp1]

On February 18, Paul and I slacked about the documentation requirements. Any updates in the doc will be in Autogen. The usual blog post will also be published. So, ID has no requirement to write documentation. Approving this epic.

[gscottj]

This feature has no user interface except for configuration parameters. No accessibility testing required.

[pnicolucci]

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

1. UFO -- does the UFO 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 UFO does identify the most likely problems customers will see. We've been very descriptive in our configuration Warning messages for invalid configuration. The UFO lists each of these Warnings and they have been implemented and tested in the implementation.

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?

Demonstrated Session and HttpEndpoint SameSite configuration, both as a standalone configuration and when configured by themselves. Misconfigured values and expected results were discussed and shown in tracing. Tracing covered both transport level tracing and warning messages that do not require tracing to be enabled.>

b) Who did you demo to?

Bill Lucy and Volodymyr Siedlecki from WAS Web Tier development.

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?

They responded with, "The new messages added on the problem paths are well thought out and should be sufficient for customers to address configuration problems on their own."

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.
   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?

Brian Hanczaryk 8:46 PM
b) Yes, I agree that serviceability of any problems was sufficient to avoid PMRs or that L2 could quickly address any issues without the 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.

L2: WAS: L2 WEB Team
L3: WAS L3:Security / WAS L3: WebContainer
L2/L3 Informed -> I reached out to WEB team member to share with the larger team.
Queue Contact Summary / Contact Reference File -> In my opinion nothing new to add here, no additional components were added as part of this feature it just has new metaType in the httpEndpoint,httpSession, and webAppSecurity.

[skasund]

No STE is needed. I've approved the feature.

[pnicolucci]

I've opened a GA blog post issue which is linked to this EPIC as well as a stand alone blog post with additional details : OpenLiberty/blogs#288

[pnicolucci]

All approvals are completed, closing.