[Openid-specs-ab] IdP initiated login
Justin Richer
jricher at mitre.org
Fri Nov 4 12:30:37 UTC 2011
I think we'll need a special landing page -- a registered "idp-login
endpoint" that the idp knows about. From that point, the idp can
actually just pass in the full user identifier to the RP in an id token,
acct:user at idp.com and all. That way the RP can decide about the
multiuser problem, which IdP, and all that.
-- Justin
On Thu, 2011-11-03 at 17:24 -0700, Allen Tom 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.
>
>
> 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
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
More information about the Openid-specs-ab
mailing list