[Question] When is the subaccountid part of the ext_attr in a token?

[Kiemes]

Hello colleagues, could you please explain in which cases we would see the subaccountid as part of ext_attr in a token and in which cases we won't?

I see the code in XsuaaToken.java and I wonder when the first part checking the EXTERNAL_ATTRIBUTE will become true and when we would fallback to the zid.

Maybe you have some documentation which I did not find?

Thanks and best regards, Tom

[nenaraab]

Hi @Kiemes,

the reason I've implemented it that way, was to allow customers to update their applications before zones becomes relevant in CF Canary for new subaccounts.

For existing subaccounts the value remains unchanged, but until the switch the security client libraries takes the subaccountid from "zid" claim and afterwards from the subclaim from "ext_attr".

See also here: https://github.com/SAP-samples/teched2020-DEV263/tree/main/exercises/ex6_tenantid

Best regards, Nena

[Kiemes]

Thx @nenaraab. I still wonder what will happen if applications did not change from getSubaccountId() to getZoneId() for identifying the tenant until today. Assuming the switch happens today, and a new customer tenant is onboarded tomorrow by the app still using getSubaccountId. That means, the tenant discriminator will be the subaccount id. Now the application switches from getSubaccountId() to getZoneId() next month. At that point, the customer will not be able to get any data since there is no tenant discriminator with that zone id registered.

Already yesterday, our tokens contained the ext_attr with subaccountid. Will this attribute stay part of the token after the switch? Who is "taking" the subaccountid as you say in "subaccountid is taken from"?

[nenaraab]

Hi @Kiemes

I still wonder what will happen if applications did not change from getSubaccountId() to getZoneId() for identifying the tenant until today. Assuming the switch happens today, and a new customer tenant is onboarded tomorrow by the app still using getSubaccountId. That means, the tenant discriminator will be the subaccount id. Now the application switches from getSubaccountId() to getZoneId() next month. At that point, the customer will not be able to get any data since there is no tenant discriminator with that zone id registered.

• this change is not yet productive. Its just active in the CF Canary environment. So customers have still time to prepare their applications as described here:

  • https://github.com/SAP-samples/teched2020-DEV263#changed-api-for-multi-tenant-applications-to-determine-tenant-identifier-getsubaccountid-replaced-by-getzoneid
  • https://blogs.sap.com/2020/12/02/changed-api-for-multitenant-apps-to-get-tenant-identifier-getzoneid-replaces-getsubaccountid/

• Yes, the impact is clear and critical, as you've described... in case applications stores data with the wrong tenant discriminator, this would require data migration efforts in case the application was not prepared.

• In the cases, the subaccount id is required, its not that critical, its just not working.

Already yesterday, our tokens contained the ext_attr with subaccountid. Will this attribute stay part of the token after the switch?

Yes, "ext_attr" is the new way, the xsuaa access token provides the subaccount id.

Who is "taking" the subaccountid as you say in "subaccountid is taken from"?

I've adopted the text above. I've meant the the security client libraries provided by SAP.

Best regards, Nena