[Openid-specs-ab] IdP initiated login

Fri Nov 4 00:35:54 UTC 2011

On Thu, Nov 3, 2011 at 17:24, Allen Tom <allentomdude at gmail.com> wrote:

> OK, this seems to make sense.
>
> The IdP can link directly to the the RP's service. If the user is not
> already logged into the RP, the RP can redirect the the user back to the
> IdP's authorization URL to authenticate the user - which is the same
> scenario as if the user had started off at the RP.
>
> There are a couple minor gotchas, which might not matter:
>
> 1) It might be necessary for the IdP to include a hint about which IdP to
> use, if the landing page on the RP is linked to from multiple IdPs. For
> instance, if the RP is mail.example.com, how is the RP supposed to know
> which IdP to send the user?
>
> 2) It's possible that the user is already logged into the RP, but as a
> different user than the user that's logged into the IdP - aka "the wrong
> user problem."  Perhaps one solution would be for the IdP to pass along a
> user hint, and the RP can redirect the browser back to the IdP if the wrong
> user is logged in.
>
>
Agreed.

> Allen
>
>
> On Thu, Nov 3, 2011 at 9:48 AM, Breno de Medeiros <breno at google.com>wrote:
>
>>
>>
>> On Wed, Nov 2, 2011 at 21:39, Nat Sakimura <sakimura at gmail.com> wrote:
>>
>>> 3. is what Justin is talking about and is the way to go, IMHO.
>>
>>
>> I agree. I think the IDP should simply redirect the user to a URL at the
>> RP with a clue about what IDP should be used. The RP will then initiate the
>> request. This is simpler to maintain (the IDP doesn't need to know what the
>> RP wants to ask in requests, which can evolve over time) and better for
>> security (the RP can implement other features such as XSRF protection to
>> prevent assertion leakage).
>>
>>
>>
>>
>>>
>>> =nat
>>>
>>>
>>> On Thu, Nov 3, 2011 at 6:44 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>>
>>>> No, it will require some sort of extension.
>>>>
>>>> A OAuth 2.0 response doesn't have enough information in it.
>>>> We are sending the id_token that dose have enough information in it.
>>>> However basic clients rely on the check_id endpoint.   They don't have
>>>> enough information to find it, without looking in the id_token.
>>>>
>>>> Possible solutions are:
>>>> 1. make every RP capable of directly inspecting the id_token,  all they
>>>> need to do is base64url decode the token body to find the issuer and lookup
>>>> the check_id endpoint if they can't process signatures.
>>>> 2. Add an additional response paramater of issuer to unsolicited
>>>> assertions.
>>>> 3. Add a special RP API to setup the login.
>>>>
>>>> 1&2 have the problem of working around the RP's XSRF protection, as
>>>> well as the IdP knowing what client_id and return URL to use,  they may
>>>> change over time.
>>>>
>>>> People weren't interested when I raised the issue the first time.   I
>>>> agree that we probably need to address this.
>>>>
>>>> There are a bunch of issues that need to be considered.
>>>>
>>>>
>>>> John B.
>>>>
>>>>
>>>> On 2011-11-02, at 6:14 PM, Allen Tom wrote:
>>>>
>>>> Hi John -
>>>>
>>>> The scenario that I'm talking about is where the user starts on IdP's
>>>> site in an authenticated state, and is presented with a list of links to
>>>> services hosted on other sites. The user clicks on one of the links and is
>>>> seamlessly logged into one of the services without having to
>>>> re-authenticate.
>>>>
>>>> So for example, imagine that the user is an employee and is
>>>> authenticated into her work intranet portal. The portal has a link to check
>>>> the user's mail, which is hosted on a different domain. The user should be
>>>> able to click on the [check mail] link and be able to use the mail
>>>> application without having to authenticate again.
>>>>
>>>> This is a pretty common use case - many companies outsource corporate
>>>> applications like mail, expense reports, calendaring, payroll, travel
>>>> bookings, etc  to 3rd parties.  The user logs into their employer's
>>>> corporate portal and should be able to click on the links to the different
>>>> apps, without having to re-authenticate.
>>>>
>>>> Does OpenID Connect have a solution for this use case?
>>>>
>>>> Allen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Nov 1, 2011 at 7:11 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>>>
>>>>> Yes but that, can't be done with the existing OAuth flow in connect.
>>>>> The OAuth presumption is that the user is starting at the RP and the RP
>>>>> stores state about what IdP the user is going to.
>>>>>
>>>>> There is not enough info in the authentication response alone for the
>>>>> RP to figure out where it came from.
>>>>>
>>>>> We need an extension to OAuth that would start the flow from the IdP
>>>>> and send the extra info,  as well as protecting against XSRF.
>>>>>
>>>>> John
>>>>> On 2011-11-01, at 2:21 AM, Harald Petersilka wrote:
>>>>>
>>>>> Hi John,****
>>>>> ** **
>>>>> I was more thinking of a kind of dashboard located at an IdP where I
>>>>> can collect my OpenID sites and just have to click them to be logged in.
>>>>> ****
>>>>> There I’d send the user to the RP with the already known OpenID as
>>>>> GET/POST parameter to initiate the common authentication procedure just
>>>>> without forcing the user to enter his OpenID every time.****
>>>>> ** **
>>>>> BG, Harry****
>>>>> ** **
>>>>> ** **
>>>>>  *Von:* openid-specs-ab-bounces at lists.openid.net [mailto:
>>>>> openid-specs-ab-bounces at lists.openid.net] *Im Auftrag von *John
>>>>> Bradley
>>>>> *Gesendet:* Dienstag, 01. November 2011 01:32
>>>>> *An:* Allen Tom
>>>>> *Cc:* openid-specs-ab at lists.openid.net
>>>>> *Betreff:* Re: [Openid-specs-ab] IdP initiated login****
>>>>> ** **
>>>>> I agree that the user needs to go back to the IdP.  ****
>>>>> ** **
>>>>> I was saying the first step of getting the user to the RP can't be
>>>>> OAuth, because it doesn't have enough info.****
>>>>> ** **
>>>>> I was thinking that the IdP would need to have the user full frame and
>>>>> present some sort of dialog before sending the request to the RP.****
>>>>> Otherwise the attacker XSRFs the IdP to get to the RP.****
>>>>> ** **
>>>>> You seem to have another use case where the attacker is cooperating
>>>>> with a bad IdP to log the user into a RP as some 4th party that the
>>>>> attacker controls?****
>>>>> ** **
>>>>> John****
>>>>> On 2011-10-31, at 9:22 PM, Allen Tom wrote:****
>>>>>
>>>>>
>>>>> ****
>>>>> Hi John -****
>>>>> ** **
>>>>> I think that there's still an XRSF vulnerability even if the the IdP
>>>>> shows a dialog before generating the assertion.****
>>>>> ** **
>>>>> The attacker could login to the IdP with the attacker's own account,
>>>>> then go through the flow to see the dialog. The attacker could then click
>>>>> through the dialog and capture the assertion (possibly using a browser
>>>>> extension, or modified client) and then send the assertion to a victim
>>>>> (possibly via IM or email) to have the victim be signed into the RP using
>>>>> the attacker's account.****
>>>>> ** **
>>>>> This is why the RP needs to bounce the browser back to the OP to have
>>>>> the OP verify that the assertion was issued to the same browser before
>>>>> sending the browser back to the RP.****
>>>>> ** **
>>>>> I used to think that Login XRSF was not a big deal (who cares if an
>>>>> attacker can get someone else to login as the attacker?) - however there
>>>>> are a few interesting scenarios where a victim could have their privacy
>>>>> compromised.****
>>>>> ** **
>>>>> Allen****
>>>>> ** **
>>>>> ** **
>>>>> ** **
>>>>> On Mon, Oct 31, 2011 at 5:10 PM, John Bradley <ve7jtb at ve7jtb.com>
>>>>> wrote:****
>>>>> If the IdP is not presenting a dialog then it leaves the user open to
>>>>> XSRF. ****
>>>>> ** **
>>>>> In a code flow you only get code and state from the IdP it is the RP's
>>>>> responsibility to figure out where it came from, so that wouldn't work.
>>>>> ****
>>>>> If you used the Token flow the RP would need to look into the id_token
>>>>> to see where it came from.  ****
>>>>> That would be a problem for simple clients, because they need the
>>>>> introspection endpoint, and to get that they need to get the issuer from
>>>>> inside the token.****
>>>>> ** **
>>>>> I think we need a separate API that takes as its  parameters:****
>>>>>  issuer****
>>>>>  nonce****
>>>>>  hmac of issuer & nonce with client secret.****
>>>>> ** **
>>>>> That way the RP can tell that the IdP is sending the request and not a
>>>>> 3rd party.****
>>>>> ** **
>>>>> The RP would do a normal authentication with prompt=none to the issuer.
>>>>> ****
>>>>> ** **
>>>>> There is a extra hop.****
>>>>> ** **
>>>>> We need to identify & authenticate the issuer/IdP somehow in the first
>>>>> step.****
>>>>> ** **
>>>>> John B.****
>>>>> ** **
>>>>> ** **
>>>>> ** **
>>>>> On 2011-10-31, at 5:42 PM, Allen Tom wrote:****
>>>>>
>>>>>
>>>>> ****
>>>>> Hi John -****
>>>>> ** **
>>>>> Is this the Unsolicited Assertion use case - where the user clicks on
>>>>> a sponsored link hosted on the IdP's site and gets authenticated on the
>>>>> RP's site?****
>>>>> ** **
>>>>> I think we had discussed this at IIW a couple years ago, and the
>>>>> general consensus was that upon receiving an unsolicited positive
>>>>> assertion, the RP would need to redirect the user's browser back to the OP
>>>>> to have the OP re-generate the assertion and resend it back to the RP.
>>>>> ****
>>>>> ** **
>>>>> The downside is that the UX would suffer due to the extra round trip.*
>>>>> ***
>>>>> ** **
>>>>> Allen****
>>>>> ** **
>>>>> ** **
>>>>> ** **
>>>>> ** **
>>>>> On Mon, Oct 31, 2011 at 6:56 AM, John Bradley <ve7jtb at ve7jtb.com>
>>>>> wrote:****
>>>>>
>>>>> Just a note on a possible idea.
>>>>>
>>>>> The when the RP registers a client ID it sets unsolicited_login_url:
>>>>>  to some return_url
>>>>>
>>>>> The IdP then sends the id_token with nonce set to  a time stamp +
>>>>> entropy , and a claim of idp_initiated: true .
>>>>>
>>>>> We probably need to restrict this to the code flow.
>>>>>
>>>>> RP could then check that the id_token was not generated by XSRF and
>>>>> set it's cookies.
>>>>>
>>>>> I don't see a general way that a unmodified RP is going to be able to
>>>>> safely.
>>>>>
>>>>> This should probably be an extension.
>>>>>
>>>>> John  B.
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> 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
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>

-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111103/a94f5658/attachment.html>