Identity Zone Selection via X-Zid Header

[adrianhoelzl-sap]

No description provided.

[fhanik]

@adrianhoelzl-sap How does this impact cookies and security?

What If I do a request like this

GET /some/path
Host: some.host.com
Header: X-Zid=zone-id-for-someother.host.com

and this sets up my cookies (including authentication stored in the session)
and then I do this request (and continue using the same JSESSIONID since the host hasn't changed)

GET /some/path
Host: some.host.com

Do I just gain access across zones?

[adrianhoelzl-sap]

@adrianhoelzl-sap How does this impact cookies and security?

What If I do a request like this

GET /some/path
Host: some.host.com
Header: X-Zid=zone-id-for-someother.host.com

and this sets up my cookies (including authentication stored in the session) and then I do this request (and continue using the same JSESSIONID since the host hasn't changed)

GET /some/path
Host: some.host.com

Do I just gain access across zones?

This scenario should be addressed by this check here:

uaa/server/src/main/java/org/cloudfoundry/identity/uaa/authentication/SessionResetFilter.java

Line 60 in df50723

if (!Objects.equals(IdentityZoneHolder.getCurrentZoneId(), authentication.getPrincipal().getZoneId())) {

The zone resolved through the subdomain or X-Zid header (IdentityZoneHolder.getCurrentIdentityZoneId()) is compared to the zone for which the session was set up (authentication.getPrincipal().getZoneId()). If they do not match, the session is invalidated.

[fhanik]

The SessionResetFilter is added at the end of each filter chain. it is the last filter that is used before an MVC endpoint is invoked.

But all the filters before that, that may contain logic and send redirects prior to the completion of the filter chain are still vulnerable to this.

A lot of the SAML/OAuth/OIDC happens in just filters, and not in MVC endpoints, and those filters would be working under incorrect assumptions.

Given the risk, is this header really needed?

If the HTTP client can set a header, it can set the "Host" header, and if there is a browser involved, cookie handling will be accurate.

[strehle]

My hope was that we can consolidate the amount of filter (per each request) and optimize but can we integration this logic into one of other IdentityZoneXYZ filters ? ... maybe rename one and do more ?

[strehle]

I checked docs and we have X-Identity-Zone-Id and X-Identity-Zone-Subdomain already , so what is X-zid in comparison ?

The header allows new possiblities, correct ? then we should have thing to tell admin, e.g.
allowZoneSwitchByHeader or allowZoneSwitchByZidHeader

[strehle]

What is the difference to X-Identity-Zone-Id, X-Identity-Zone-Subdomain ?

[adrianhoelzl-sap]

With the subdomain or the X-Zid header, one selects the identity zone to log in to. With the other two headers, IdZ switching can be performed (only possible if logged in to "uaa" zone).

Example for IdZ switching:

• user has a group zones.custom.scim.read in the "uaa" zone
• log in to "uaa" zone (here, the X-Zid can be used as an override), receive token
• use the token for performing actions according to the scim.read scope in the zone with the ID "custom"
  • In the SCIM requests, he would then need to pass the X-Identity-Zone-Id header with the value "custom"

[strehle]

this means, even if we have a subdomain but if there is a X-Zid we overrule the subdomain ?

[adrianhoelzl-sap]

Yes, the X-Zid header overrides the zone specified by the subdomain.