Relying Parties are often behind firewalls

[Michael Jones]

As we make protocol choices, we should be aware that many Relying Parties live behind firewalls. This means that direct Web access to them, such as POST operations, are impossible. (Note that user agents can redirect to these RPs, since they’re also running behind the firewall on behalf of the end-user.)

This means that proposed protocol flows, such as Response-as-Push https://bitbucket.org/openid/connect/pull-requests/50 will often not be possible.

[David Waite]

For approaches such as response_mode=post and response-as-push, these will likely not work without there being an accessible endpoint on the RP for the SIOP agent.

The response_mode=form_post mechanism is not reliable for SIOP for a different reason - the SIOP implementation will often be a native app, and native apps can only ‘open’ URLs (e.g. HTTP GET) via the various platform APIs. The SIOP implementation could potentially use javascript to POST into an embedded web view, but it will likely compromise CSRF and other potential protections on the RP, as well as leave the user in the wrong browser context.

It seems for cross-device scenarios, there is a requirement for the RP to have an accessible endpoint and likely that will translate for it to be publicly accessible. We could potentially evaluate whether this endpoint could be separated infrastructure (e.g. common hosting provider acting as a mailbox)

For app-browser and cross-app scenarios, #1342 may help up get more mileage around embedding data within the redirect URL.

[Jeremie Miller]

(Note that user agents can redirect to these RPs, since they’re also running behind the firewall on behalf of the end-user.)

SIOP is on the same device as the user agent, why would it have different network access and be unable to make a POST (in a native app) vs. a GET (in a browser)?

[Stephane Durand]

I am not sure to understand how these firewall limitations come into the picture. As mentioned above, it goes by that a prerequisite for response-as-push is that the RP exposes an endpoint to receive the POST so I’d assume the RP to accordingly configure its firewall ( and/or WAF) to accept direct (POST) connections.

In that sense, the issue seems more to be able to ensure that all the conditions are met on both end of (SI)OP and RP in order to support a feature before using it. In the case of the Response as Push, it was noted in the PR comments that some registration metadata allow the RP to express its support of R-as-P; if RP could not adjust its firewall rules, then it should just not advertise support.

[Stephane Durand]

the SIOP implementation will often be a native app, and native apps can only ‘open’ URLs (e.g. HTTP GET) via the various platform APIs.

I am not aware of a platform where a low level socket API is not available to native apps. Then, if ‘high level’ APIs do not offer POST requests support, there is still an option to implement it.

[David Waite]

Then, if ‘high level’ APIs do not offer POST requests support, there is still an option to implement it.

The issue is not in the ability to do a network POST, but to have the correct associated state with that POST (such as XSRF and transactional state cookies).

Platforms do not provide the ability to invoke arbitrary HTTP methods within the system or third-party browsers from another application.

The purpose of “Response as Push” is to provide mail-boxing so that a larger message may be POSTed via a native API without such browser state, then a normal redirect be performed in order to allow such state to be available at the redirect_uri, as expected by many OpenID Relying Parties.

This issue discusses objections raised on that approach. Unfortunately, I’m not sure there’s an alternative other than doing redirects and limiting message size (which is why I separately brought up #1342).

[Stephane Durand]

Hi David,

I’m in line with your account of “Response as Push” (R-a-P), but I’m failing to grasp the objections to it (at least I fail to see something that the RP could not reconfigure while it choses to advertise support of R-a-P through inclusion of pushed_authorization_response_endpoint in its registration metadata).

I must be missing something so please correct where I’m wrong. This is how I understand the R-a-P works:

1. SIOP (as a native app) receives a request, featuring a pushed_authorization_response_endpoint in the registration metadata. Requests comes as deeplink / QR / whatever (key point is: no specific assumption that it comes through a browser and that this is not required).
2. SIOP + end user resolves the request

3. SIOP pushes the response to pushed_authorization_response_endpointwith a POST request. This is done from the SIOP native app, with response expected and consumed by the native app (I don’t see that any browser should be involved at this stage, should it?)

   • In response, SIOP gets something to use as redirect_uri

4. SIOP “opens” (in the sense of the platform API allowing to let a browser become active and load the supplied URL) redirect_uri, as a GET.

Then, if there is a correct associated state that should go with the POST, I don’t see where we get it from, nor do I see where it needs to be propagated to.

‌

[Jeremie Miller]

All 4 points are spot on.

Then, if there is a correct associated state that should go with the POST, I don’t see where we get it from, nor do I see where it needs to be propagated to.

If the initial request originated in the browser on the same system, there is likely context (like an active session) that can be associated when the redirect_uri loads in the same browser.

If the redirect_uri loads on a different device, the RP can only use the P-a-R data that was POSTed, and can present a UX to the user depending on the needs of the RP at that point.

[Kristina Yasuda]

I think the simple solution is, require RP to have a publicly accessible endpoint where SIOP can POST, how RP obtains the information from such public endpoint would be out of scope for the specification, but we can add an implementation guidance on how RPs can do so.

[Torsten Lodderstedt]

I agree with Kristina’s proposal. Whether the RP application directly exposes an endpoint able to receive HTTP Post requests from the internet or whether there is some agent receiving and storing the posted data, where the RP queries it (push vs pull), is in the end an implementation consideration.

[Kristina Yasuda]

During 2021-Oct-5 call, we agreed to add a clarifying text that for cross-device SIOP, RP needs to expose a public endpoint.

[Kristina Yasuda]

This was addressed in PR #50. If we are to close that PR in favor of PARM being a separate specification, we would need to do a separate PR introducing what has been agreed above.

[Torsten Lodderstedt]

I created the new PR #110.

[Kristina Yasuda]

Thank you! Reviewed and approved

[Kristina Yasuda]

addressed in a merged PR #110