Session Management OP Frame message origin assertion

Issue #1022 open
Filip Skokan
created an issue

From OpenID Connect Session Management 1.0 - draft 28#4.2. OP iframe

The OP iframe MUST enforce that the caller has the same origin as its parent frame. It MUST reject postMessage requests from any other source origin.

I understand the intention here but would like to raise a few questions/issues.

  1. cross-domain parent origin is not accessible, accessing window.parent.location.origin or window.parent.origin raises a DOMException and other means of reading the url are unreliable and inconsistent at best (accessing document.referrer and building the origin url out of it).
  2. the parent frame (tab) is not actually the source of the message, this would be the RP frame, same origin tho which might very well sit on a different subdomain, resulting in another origin.

I can see the example in the specification is not handling this either.

Steps to reproduce:

  1. Login with any username/password at RP https://tranquil-reef-95185.herokuapp.com, set to login with OP https://guarded-cliffs-8635.herokuapp.com
  2. Open console, switch to opframe js context
  3. Attempt to get parent origin via js to have are reference to compare message origin with

If anything this assertion of message origin should be mentioned in the RP frame, where the RP frame must assert the origin of the message is the OP frame origin, this origin can be easily formed by knowing the OP Frame location and can compare it to the message origin. The example rpFrame in the specification already does this.

Comments (10)

  1. Edmund Jay

    Filip,

    Is seems there that you are proposing:

    1. Delete modify the OP iframe assertion statement.
    2. Modify the OP iframe assertion to say something along the lines of "OP iframe MUST enforce that the caller is from an approved/known origin"
    3. Add a corresponding assertion statement to the RP iframe.
    4. Add CORS language to OP/RP frames? (unknown if this will support the call of window.parent.location.origin)

    or all/combination of above?

  2. Filip Skokan reporter

    Edmund,

    1. Yes - because asserting message origin being the same as parent (or rather RP frame origin, parent is not the sender) origin is not possible due to CORS restrictions.
    2. No - Same as above, to do something like this OP frame would either have to
      • have all known origins of all RPs in the rendered page ready to be asserted to include current message origin presence
      • or rely upon accessing external resources, doing so would beat the mobile friendly nature of session management messages
      • Content-Security-Policy header frame-ancestors section would seem like a good candidate but the OP frame parent is not the origin of the caller, that would be the RP frame origin, which cannot be checked using CSP.
    3. Yes - I believe the RP can take on this responsibility, it has all the necessary information at the time of rendering its frame to statically embed the assertion.
    4. Partially, with the above, the only thing left to do is remove // Validate message origin from OP Frame example and possibly wrap the receiveMessage body in a try / catch block resulting in responding with error

    It would be of great help if others who have also already undergone this implementation would share their findings.

  3. Michael Jones

    Filip, can you summarize the specific text changes you're proposing? I have some guesses but I'm not sure that my guesses are right.

    Also, a the in-person meeting at the beginning of April, the WG decided to take the logout specs to final status. If we're going to make any more changes, now's the time.

  4. Filip Skokan reporter

    Mike, i'm not comfortable proposing changes without having confirmation from others that this OK and that they've run into the same issue. Understanding what the intention behind those statements in security considerations was or how they were intended to be implemented is needed as well as the possible impact of these proposed changes.

    Nevertheless here's a proposal and my comments on why

    Removal of "The OP iframe MUST enforce that the caller has the origin as its parent frame."

    1. it is not possible to reach x-domain for the parent frame origin (DOMException) and it is not possible to embed the expected origin in the frame html since the server does not have the information available.
    2. it is possible the parent frame and caller origins are actually different, i.e. example-rp.com as the main window, example-op.com as the OP. When the redirect_uri was i.e. https://login.example-rp.com/cb (a subdomain, common pattern) then login.example-rp.com must be the rpFrame origin else op frame won't ever be able to calculate the correct state the RP has received in the authorization response. Now there are three origins in the mix and the OP can only read the caller origin.

    OP Frame Message Origin Assertion Removal
    The OP is not able to efficiently and reliably confirm the origin url of where the opFrame is embedded.

    1. same as the above
    2. in order to do this client side once a message is received the op frame would have to either
      1. embed all possible origins in the frame html - this turns out to be a problem for OPs with hundreds and thousands of clients where client information is loaded on-demand
      2. dynamically reach out to the server for validation - since client_id is part of the message this might be possible but would contradict one of the purposes of the spec it is desirable to be able to check the login status at the OP without causing network traffic
  5. Log in to comment