1681062 - Authentication to service on ibm.com subdomain broken

Status: RESOLVED WORKSFORME

(Core :: Privacy: Anti-Tracking, defect, P1)

Description

[bberming]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

1. Browse to https://crossdomain.vanity.iamsimplify.com/index_verify.html
2. Enter username / password
   Note: username / password is for an authentication service on https://crossdomain.verify.ibm.com
3. Click Login button
4. User is presented with login page on https://crossdomain.verify.ibm.com

Actual results:

During the login call on crossdomain.vanity.iamsimplify.com a bearer token is retrieved from https://crossdomain.verify.ibm.com/oidc/endpoint/default/token, then a session is established on https://crossdomain.verify.ibm.com/v1.0/auth/session with an authorization header.
A user should be logged in and land on https://crossdomain.verify.ibm.com/usc however they are presented with the login page.
The reason is a session cookies (CISESSIONIDPR01A and CIPD-S-SESSION-ID) are not maintained between the POST /token and GET /session. The cookies are not sent in the request for the GET /session call.

This is not the case between https://crossdomain.vanity.iamsimplify.com/index_cloud.html and https://briantest.ice.ibmcloud.com which is the same service just different hostname. The cookies are sent in the GET /session request.

It appears crossdomain calls doesn't keep cookies on ibm.com but does on ibmcloud.com

Expected results:

User is logged into product on https://crossdomain.verify.ibm.com/usc

Comment 1

[bberming]

Attachment: WORKING-briantest.ice.ibmcloud.com_Archive [20-12-07 12-13-08]-1.har

Working har

Comment 2

[bberming]

Attachment: NOTWORKING-crossdomain.verify.ibm.com_Archive [20-12-07 12-12-35]-1.har

Comment 3

[Tim Huang[:timhuang]]

I think it's because ibm.com is treated as an analytics tracker. So, ETP has blocked its cookie access. I can see from the console log that https://crossdomain.verify.ibm.com/oidc/endpoint/default/token and https://crossdomain.verify.ibm.com/v1.0/auth/session were blocked.

However, ibmcloud.com doesn't be categorized as a tracker. So, the login works over there.

Steve, how do we handle this case? Should we contact IMSimplify to ask them to use StorageAccessAPI? Thanks.

Comment 4

[bberming]

Hi Tim,

A background to our product. Our product is called IBM Security Verify and we provide identity as a service. Our old domain provided to our customers was <tenant>.ice.ibmcloud.com but we now use <tenant>.verify.ibm.com.
Some customers can have thousands of applications that use an authentication solution on abc.verify.ibm.com.

iamsimplify.com is a domain I am using to reproduce this issue for the purposes of this bug report but we have real customers who are hitting this issue.

While ibm.com likely does do analytics tracking there are many IBM products that are under the ibm.com domain which wouldn't, e.g. video.ibm.com have a similar bug open - https://bugzilla.mozilla.org/show_bug.cgi?id=1557363

Comment 5

[bberming]

Hi,

Any update on this bug?

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:timhuang, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit auto_nag documentation.

Comment 7

[Tim Huang[:timhuang]]

It seems the pages are no longer available. I will close this bug for now. Feel free to reopen.

Comment 8

[bberming]

I can update the examples but will the issue be investigated as this bug has been opened for 2 years

Comment 9

[Tim Huang[:timhuang]]

Thanks for reopening,

Yes, we will look into this issue recently, so it would be wonderful if you could update the examples. :)

Comment 10

[bberming]

I'll setup again to reproduce, should have an update tomorrow.
Related issue, if you go to prepiam.ice.ibmcloud.com with Enhanced Tracking Protection enabled then you'll see that you get a blank page, this is because the web resources (css, js, etc.) are blocked as the web resources are hosted on ibm.com

Comment 11

[Thomas Wisniewski [:twisniewski]]

Yes, those resources will be blocked in strict mode or private browsing as they are on the Disconnect lists. In standard mode they seem to load fine for me. Is that what you're experiencing as well, bberming?

Comment 12

[Marco Castelluccio [:marco]]

bberming, any updates?

Comment 13

[Neha Kochar [:neha]]

bberming, I re-filed a NI for you so you'd hopefully get a new notification about this. Can you please confirm if you are still able to reproduce this?

Comment 14

[Neha Kochar [:neha]]

Closing this as WFM as we haven't heard back from the reporter for this S2 bug. Reporter, please re-open if you are still able to reproduce and have more info for us.

Comment 15

[bberming]

Hi Neha,

Apologies for not replying, I'll leave this closed and find time to test but I haven't seen this issue reported in a while so it may have been fixed.

Comment 16

[Neha Kochar [:neha]]

Thank you bberming very much for confirming. We appreciate it!