[Openid-specs-ab] IdP initiated login

Thu Nov 3 04:39:55 UTC 2011

3. is what Justin is talking about and is the way to go, IMHO.

=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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111103/01cd2c6e/attachment.html>