[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-0001.html>


More information about the Openid-specs-ab mailing list