CHIPS (Partitioned Cookies) Feature Test Summary for Liberty

[volosied]

Test Strategy

Describe the test strategy & approach for this feature, and describe how the approach verifies the functions delivered by this feature.

For Epic: https://github.com/OpenLiberty/open-liberty/issues/27405

The changes related to setting a new attribute called "Partitioned" on cookies. The "Partitioned" attribute is only applies to cookies which have "SameSite=None". This will allow cookies to be shared across third party contexts (with limitations set by the browsers to reduce cross site tracking).

Our test strategy is similar to the one for SameSite. We created numerous tests (with various configuration scenarios) to ensure the correct cookie attributes were set.

We also created tests to verify the precedence of our configurations ( for example, session config should override anything set on the http channel config).

We also tested manually on Chrome to verify the cookies were accepted by the browser and no errors were reported.

List of projects affected

• com.ibm.ws.webcontainer.servlet.4.0_fat
• com.ibm.ws.webcontainer.servlet.4.0_fat.2
• io.openliberty.webcontainer.servlet.6.0.internal_fat
• com.ibm.ws.security.oauth.oidc_fat.common
• com.ibm.ws.security.oidc.client_fat.2

• com.ibm.ws.security.social_fat.commonTest.LibertyOP

  Unit Tests were also updated / created for the new attribute.

• com.ibm.ws.webcontainer.security/test
• com.ibm.ws.security.social/test
• com.ibm.ws.security.saml.websso.2.0/test
• And others

Test strategy

• What functionality is new or modified by this feature?

• What are the positive and negative tests for that functionality? (Tell me the specific scenarios you tested. What kind of tests do you have for when everything ends up working (positive tests)? What about tests that verify we fail gracefully when things go wrong (negative tests)? See the Positive and negative tests section of the Feature Test Summary Process wiki for more detail.)

Positive tests would include verifying the cookie attribute exists when set to true. The attribute was set to true via various means: httpSession config, http config, Cookie#setAttribute, httpservletresponse#setHeader, etc. We also verified webAppSecurity / httpSession took precedence over the HTTP config.

As for negative tests, we ensured that if partitioned was set on something other than samesite=none, then we did not add the attribute. No exceptions should occur here, the attribute is simply not added.

• What manual tests are there (if any)? (Note: Automated testing is expected for all features with manual testing considered an exception to the rule.)

There are no manual tests needed since our FATS verify the attribute exists when set, but I verified that Chrome accepted > the new cookie attribute by enabling the experimental feature: chrome://flags/#test-third-party-cookie-phaseout.

Confidence Level

2) Collectively as a team you need to assess your confidence in the testing delivered based on the values below. This should be done as a team and not an individual to ensure more eyes are on it and that pressures to deliver quickly are absorbed by the team as a whole.

Please indicate your confidence in the testing (up to and including FAT) delivered with this feature by selecting one of these values: Our confidence level is 4.

4 - We have delivered all automated testing we believe is needed for the golden paths of this feature and have good coverage of the error/outlying scenarios. While more testing of the error/outlying scenarios could be added we believe there is minimal risk here and the cost of providing these is considered higher than the benefit they would provide.

[c00crane]

27983

[ayoho]

Coverage sounds fine 👍