[Openid-specs-ab] Limiting a login request to a specific user

John Bradley ve7jtb at ve7jtb.com
Thu Sep 25 00:32:19 UTC 2014


The issue with that might be that the email ends up in the id_token, though I think MS is putting claims in the id_token anyway.  If this is about email or UPN then Nat has a point. 

Sent from my iPad

> On Sep 24, 2014, at 9:22 PM, Nat Sakimura <n-sakimura at nri.co.jp> wrote:
> 
> Let me understand the problem. 
> 
> As in the 2012 thread, you can ask for a specific claim value to be returned. 
> If you are using email as the "alias" of the user, and you only want a positive assertion if the user's verified email address matches a particular value, you can as the example in the thread. 
> 
> For example, you can include the following in the request: 
> 
>  "id_token":
>    {
>      "claims":
>        {
>          "iss": {"essential": true, "value": "https://op.example.com/"},
>          "sub": {"essential": true, "value": "1352468"},
>          "auth_time": {"essential": true},
>          "email": {"essential": true, "value":"alice at example.com"},
>          "email_verified": {"essential": true, "value": true},
>        },
>      "max_age": 86400
>    }
> 
> The response will be negative if the user's email is not "alice at example.com". 
> 
> This seems to be what you are wanting, and is one of the topic of the 2012 thread. 
> Could you kindly elaborate the difference? 
> 
> Nat
> 
> 2014-09-25 6:06 GMT+09:00 Mike Jones <Michael.Jones at microsoft.com>:
>> You're right that, in general, the hint could be ambiguous, but in practice, an e-mail address valued hint is highly likely to map to a single identity at the OP.  Our team is going to implement something to do this.  I'd like it to be something that we have agreement on and that others might choose to use too.
>> 
>> I'm thinking that the best solution that's been proposed so far is a new parameter - say restrict_to_hint=true - which tells the IdP to not allow the user to sign in as a different user than one matching the login_hint or id_token_hint parameters used.  Are people OK with that?  Do you want the name to be different or is "restrict_to_hint" a reasonable name?
>> 
>>                                 -- Mike
>> 
>> -----Original Message-----
>> From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
>> Sent: Wednesday, September 24, 2014 1:37 PM
>> To: Nat Sakimura
>> Cc: openid-specs-ab at lists.openid.net
>> Subject: Re: [Openid-specs-ab] Limiting a login request to a specific user
>> 
>> Yes, however in conversation with Mike it appears that they are wanting to scope the login to an alias for the user and not the user_id itself, so that method likely won't work for them.
>> 
>> They seem to be looking to limit the returned value to a alias of the hint.
>> 
>> That presents a issue given that the hint might cover all the users at the idp or some group etc.
>> So defining the exact semantics of how a exact match on something that is otherwise treated as a hint may be tricky.
>> 
>> John B.
>> On Sep 24, 2014, at 5:41 AM, Nat Sakimura <n-sakimura at nri.co.jp> wrote:
>> 
>> > Hi Takahiro,
>> >
>> > You are right. You would have to state the 'iss' as well though and add 'essential' to them as well.
>> >
>> > This actually has been discussed in the following thread back in 2012.
>> >
>> > http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120903
>> > /002354.html
>> >
>> > In the mail, Blaine expressed the requirement as:
>> >
>> >> Only sign in the user identified by user_id. If it's not possible to
>> >> sign in that user, please return an error.
>> >
>> > The response to the message by John B. was:
>> >
>> >> We have the only sign in this  user_id  in the request object already.
>> >
>> > and the example is given in
>> > http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120903
>> > /002367.html
>> >
>> > Taking the example, the request object for requesting a specific sub would be:
>> >
>> > {
>> > "response_type": "code id_token",
>> > "client_id": "s6BhdRkqt3",
>> > "redirect_uri": "https://client.example.org/cb",
>> > "scope": "openid profile",
>> > "state": "af0ifjsldkj",
>> > "userinfo":
>> >   {
>> >     "claims":
>> >       {
>> >         "name": {"essential": true},
>> >         "nickname": null,
>> >         "email": {"essential": true},
>> >         "email_verified": {"essential": true, "value": true},
>> >         "picture": null
>> >       }
>> >   },
>> > "id_token":
>> >   {
>> >     "claims":
>> >       {
>> >         "iss": {"essential": true, "value": "https://op.example.com/"},
>> >         "sub": {"essential": true, "value": "1352468"},
>> >         "auth_time": {"essential": true},
>> >         "acr": { "values":["2"] }
>> >       },
>> >     "max_age": 86400
>> >   }
>> > }
>> >
>> >
>> >
>> >
>> > The conclusion of the WG was that
>> >
>> > On Tue, 23 Sep 2014 19:57:46 +0900
>> > Takahiko Kawasaki <daru.tk at gmail.com> wrote:
>> >
>> >> "OpenID Connect Core 1.0, 3.1.2.2. Authentication Request Validation"
>> >> says as follows:
>> >>
>> >>> If the sub (subject) Claim is requested with a specific value for
>> >>> the ID Token, the Authorization Server MUST only send a positive
>> >>> response if the End-User identified by that sub value has an active
>> >>> session with the Authorization Server or has been Authenticated as a
>> >>> result of the request. The Authorization Server MUST NOT reply with
>> >>> an ID Token or Access Token for a different user, even if they have
>> >>> an active session with the Authorization Server. Such a request can
>> >>> be made either using an id_token_hint parameter or by requesting a
>> >>> specific Claim Value as described in Section 5.5.1, if the claims
>> >>> parameter is supported by the implementation.
>> >>
>> >> Doesn't this mechanism suit your case?
>> >>
>> >> If my understanding is correct, a client application can request a
>> >> specific subject (login ID) using "claims" request parameter like
>> >> below.
>> >>
>> >>    {
>> >>     "id_token":
>> >>       {
>> >>         "sub": {"value": "REQUIRED-SUBJECT"}
>> >>       }
>> >>    }
>> >>
>> >> If I'm wrong, please let me know, experts.
>> >>
>> >> Takahiko Kawasaki
>> >>
>> >> 2014-09-23 7:34 GMT+09:00 Tim Bray <tbray at textuality.com>:
>> >>> Cleanest way would probably be new parameters "login_must_be" /
>> >>> "id_token_must_be", same semantics as login_hint but substitution
>> >>> forbidden.
>> >>>
>> >>> On Mon, Sep 22, 2014 at 3:26 PM, Mike Jones
>> >>> <Michael.Jones at microsoft.com> wrote:
>> >>>>
>> >>>> We have a use case in which we want to limit the login to the user
>> >>>> specified via the login_hint and not allow the user to sign in as a
>> >>>> different user.  How would you suggest expressing that requirement?
>> >>>> For instance, should we invent a new request parameter such as
>> >>>> "this_user=true" (which could be used in combination with
>> >>>> login_hint or id_token_hint)?  Or might a "prompt" parameter value
>> >>>> such as "prompt=this_user" be appropriate? Or would that possibly
>> >>>> conflict with other uses of "prompt"?
>> >>>>
>> >>>>
>> >>>>
>> >>>>                                                                --
>> >>>> Mike
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Openid-specs-ab mailing list
>> >>>> Openid-specs-ab at lists.openid.net
>> >>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> - Tim Bray (If you'd like to send me a private message, see
>> >>> https://keybase.io/timbray)
>> >>>
>> >>> _______________________________________________
>> >>> Openid-specs-ab mailing list
>> >>> 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
>> >> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> >
>> >
>> > --
>> > Nat Sakimura (n-sakimura at nri.co.jp)
>> > Nomura Research Institute, Ltd.
>> >
>> > PLEASE READ:
>> > The information contained in this e-mail is confidential and intended
>> > for the named recipient(s) only. If you are not an intended recipient
>> > of this e-mail, you are hereby notified that any review,
>> > dissemination, distribution or duplication of this message is strictly
>> > prohibited. If you have received this message in error, please notify
>> > the sender immediately and delete your copy from your system.
>> > _______________________________________________
>> > Openid-specs-ab mailing list
>> > 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
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140924/36baf906/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2915 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140924/36baf906/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list