[Openid-specs-ab] IdP initiated login
Justin Richer
jricher at mitre.org
Wed Nov 2 21:23:32 UTC 2011
Why wouldn't you just redirect to the RP, have the RP figure out that
you're not authenticated, then direct you to the IdP? In the usual
enterprise case, the IdP is preconfigured at the RP, so that can be
done. If you want to have the flexibility of the IdP indicating itself
to the RP, then you're going to need some kind of callback to the RP
that has a template/argument/thing where the IdP can insert itself.
I don't really see how you could do that in a completely hands-off way,
since you'd at the very least need to know what URL to send the user to
at the RP to start the process. This is what John was getting at with
his comments about it not being able to do it "within OAuth". In this
case, it smells like a new endpoint definition to me.
-- Justin
On Wed, 2011-11-02 at 14:14 -0700, 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
More information about the Openid-specs-ab
mailing list