[Openid-specs-ab] end_session endpoint parameter specs
Torsten Lodderstedt
torsten at lodderstedt.net
Thu Jan 23 10:40:30 UTC 2014
Hi all,
it's my impression that every particpant in this discussion has some
threats and counter measures in mind but nothing is explicitely spelled
out/documented. I repeat my statement that first of all the relevant
threats must be documented. As always, there will be different measures
to mitigated those threats and the WG should discuss/decide, which
counter measures are backed into the protocol and which of them are just
explained/recommended.
I see open redirection as a potential threat. We use a global whitelist
for post url's to mitigate it. Id token hints and pre-registered urls
are another way of achieving the same goal.
Regarding XSRF: the logout request will terminate the session - where is
the risk?
regards,
Torsten.
Am 23.01.2014 01:51, schrieb John Bradley:
> One point that was maid in favour of allowing a client_id was that it
> might be useful in helping the idp look up the post logout URI to
> validate it.
>
> I don't know that it is actually easier than just indexing the URI
> itself.
>
> Following a post logout redirect without a id_token even if it is
> registered may be a bad idea.
>
> John B.
>
>
> On Jan 22, 2014, at 7:19 PM, Breno de Medeiros <breno at google.com
> <mailto:breno at google.com>> wrote:
>
>> The requirement that login be available if a login was not processed
>> is incompatible with any form of 'XSRF' protection of the logout
>> endpoint.
>>
>> I propose that we make id_token_hint RECOMMENDED, explain that IDPs
>> MAY require it to be present to perform logout, but not add another
>> mechanism based on client_id, which is solving no problem I am aware of.
>>
>> So if the IDP supports logout, it may specify id_token_hint required
>> or not, or behave differently (e.g., require user confirmation if
>> id_token_hint absent). You can add a discussion on security
>> considerations.
>>
>> Again, I am against adding another mechanism for id_token_hint, and I
>> think that the current approach to make it RECOMMENDED is the correct
>> one. I argue for no change except added discussion in security reqs.
>>
>>
>>
>>
>> On Mon, Jan 20, 2014 at 8:28 AM, Torsten Lodderstedt
>> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>>
>> Hi Todd,
>>
>> this page would not necessarily have a client id.
>>
>> Regards,
>> Torsten.
>>
>>
>>
>> Todd W Lainhart <lainhart at us.ibm.com
>> <mailto:lainhart at us.ibm.com>> schrieb:
>>
>> Hi Torsten -
>>
>> > We see the need to trigger a logout from pages, which did
>> not previously process a login (portal, landing page).
>>
>> Would your page have a client_id available? It's a
>> requirement that the provided post_logout_uri be registered.
>> I was trying to intuit how that would be done given the
>> current param spec, in which the client_id was only available
>> (perhaps) as the "aud" field of the id_token.
>>
>> *
>>
>>
>> Todd Lainhart
>> Rational software
>> IBM Corporation
>> 550 King Street, Littleton, MA 01460-1250**
>> 1-978-899-4705 <tel:1-978-899-4705>
>> 2-276-4705 (T/L)
>> lainhart at us.ibm.com <mailto:lainhart at us.ibm.com>*
>>
>>
>>
>>
>>
>>
>> From: Torsten Lodderstedt <torsten at lodderstedt.net
>> <mailto:torsten at lodderstedt.net>>
>> To: Todd W Lainhart/Lexington/IBM at IBMUS,
>> Cc: "openid-specs-ab at lists.openid.net
>> <mailto:openid-specs-ab at lists.openid.net>"
>> <openid-specs-ab at lists.openid.net
>> <mailto:openid-specs-ab at lists.openid.net>>
>> Date: 01/18/2014 03:44 AM
>> Subject: Re: [Openid-specs-ab] end_session endpoint parameter
>> specs
>> ------------------------------------------------------------------------
>>
>>
>>
>> Hi Todd,
>>
>> I think your proposal to make the id token hint required if
>> the post logout uri is present limits applicability of the
>> logout mechanism. We see the need to trigger a logout from
>> pages, which did not previously process a login (portal,
>> landing page). This would be impossible.
>>
>> General note: I think the security consideration section must
>> discuss open redirection at the end session endpoint. I
>> assume registration of post logout uri serves the purpose of
>> preventing this threat but this is not documented.
>>
>> regards,
>> Torsten.
>>
>> Am 17.01.2014 um 22:45 schrieb Todd W Lainhart
>> <_lainhart at us.ibm.com_ <mailto:lainhart at us.ibm.com>>:
>>
>> Last week I filed:
>> _
>> __https://bitbucket.org/openid/connect/issue/914/session-5-missing-client_id-parameter_
>>
>> ...where I stated that a required client_id parm was missing
>> that allowed for the verification of the post_logout_uri
>> value. I've implemented this endpoint, and I think that I
>> see that this parm may not be necessary.
>>
>> Section 5 of the session mgmt. spec says this:
>>
>> //===========
>> This specification also defines the following parameters that
>> are passed as query parameters in the logout request:
>>
>> id_token_hint
>> RECOMMENDED. Previously issued ID Token passed to the logout
>> endpoint as a hint about the End-User's current authenticated
>> session with the Client. This is used as an indication of the
>> identity of the End-User that the RP is requesting be logged
>> out by the OP. The OP need not be listed as an audience of
>> the ID Token when it is used as an id_token_hintvalue.
>> post_logout_redirect_uri
>> OPTIONAL. URL to which the RP is requesting that the
>> End-User's User Agent be redirected after a logout has been
>> performed. The value MUST have been previously registered
>> with the OP, either using the
>> post_logout_redirect_urisRegistration parameter or via
>> another mechanism. If supplied, the OP SHOULD honor this
>> request following the logout.
>>
>>
>> //===========
>>
>> I would reword these definitions to say something along the
>> following lines:
>>
>> post_logout_redirect_uri OPTIONAL. The URL to which the RP
>> is requesting that the End-User's User Agent be redirected to
>> after the logout has been performed. The value MUST have
>> been previously registered with the OP, either using the
>> post_logout_redirect_uris Registration parameter or via
>> another mechanism. If supplied, id_token_hint MUST be specified.
>>
>> id_token_hint REQUIRED if "post_logout_redirect_uri" is
>> specified, otherwise RECOMMENDED. The previously issued ID
>> Token passed to the logout endpoint as a hint about the
>> End-User's current authenticated session with the Client.
>> This is used as an indication of the identity of the End-User
>> that the RP is requesting be logged out by the OP. If
>> "post_logout_redirect_uri" is specified, then the "aud"
>> member of this token MUST be a single element, and MUST be
>> the client_id to which the specified
>> "post_logout_redirect_uri" is registered.
>>
>> Additionally, a decision should be made as to whether a state
>> parameter should be included that can be round-tripped via
>> the post_logout_redirect_uri. Either that, or the value of
>> the id_token_hint parm is returned via the
>> post_logout_redirect_uri redirect.
>>
>> The implication of this is that the end_session_endpoint can
>> be called with no parameters, an id_token_hint, or both
>> id_token_hint and post_logout_redirect_uri.
>>
>>
>>
>>
>> *
>>
>>
>>
>> Todd Lainhart
>> Rational software
>> IBM Corporation
>> 550 King Street, Littleton, MA 01460-1250**
>> 1-978-899-4705 <tel:1-978-899-4705>
>> 2-276-4705 (T/L)**_
>> _**_lainhart at us.ibm.com_* <mailto:lainhart at us.ibm.com>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list_
>> __Openid-specs-ab at lists.openid.net_
>> <mailto:Openid-specs-ab at lists.openid.net>_
>> __http://lists.openid.net/mailman/listinfo/openid-specs-ab_
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>>
>> --
>> --Breno
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140123/88edc874/attachment.html>
More information about the Openid-specs-ab
mailing list