Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now

Tim Bray <tbray@textuality.com> Thu, 27 March 2014 21:48 UTC

Return-Path: <tbray@textuality.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1459D1A06DA for <oauth@ietfa.amsl.com>; Thu, 27 Mar 2014 14:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVM0BznuMZYs for <oauth@ietfa.amsl.com>; Thu, 27 Mar 2014 14:48:07 -0700 (PDT)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF1B1A03DA for <oauth@ietf.org>; Thu, 27 Mar 2014 14:48:07 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id lh14so4964530vcb.6 for <oauth@ietf.org>; Thu, 27 Mar 2014 14:48:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E9CoBgkt5/uWO0BRihwJrDg08jtB5nafmZ9CLlD7Fpg=; b=U2cl/gOOWHd+es9RsLYxm6e6bYsUL7xpFFc5TBSvi24payPTrPx9Uf482We0YbGZYA hMQlgegDh7gxMHofE7KreVKHppjM19/8l0eWx2X9kR/puDsIILQrm5M/9BKci/5QMVDR nMWFQLyq+4UJ01HqM0g8kpfopoZNQ4vwZoxllinLu7R7q/H3woxs4gXMyRO66fGN9YPz FrPpC9LreihrYaveRUxEkSI8xNDyUIdQLW6R5P1ebiMfBJgkHjWg7mnuA6TYjhZt4JH3 LDgIY4IOp/GbUGaTWrpHNQZu0QR3WONG2w6jEDv1b5ligLOPQnJ8movV2+34Ta5niH+i i3bA==
X-Gm-Message-State: ALoCoQn1I94LV3+2t3XqA54p9X9SXrZJR8fHayg3pvhn8C+DMq8HRsOzRscD19BcVVZdJEsxG7Mu
X-Received: by 10.58.195.202 with SMTP id ig10mr491812vec.33.1395956885496; Thu, 27 Mar 2014 14:48:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.98.73 with HTTP; Thu, 27 Mar 2014 14:47:45 -0700 (PDT)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <C082266B-009B-481D-9224-7B1A05F2397F@ve7jtb.com>
References: <c174791bb42e462d813b62a952ded267@DM2PR04MB735.namprd04.prod.outlook.com> <F9D7698F-9713-477D-9D14-BF97425CFF92@ve7jtb.com> <4fa46e94eca54ce0940162f8ef4101dd@DM2PR04MB735.namprd04.prod.outlook.com> <C300A03E-CDCB-48BF-B2A2-E519E017669E@ve7jtb.com> <2a2d0cadd4d445a9b148c8a2a6e06dc3@DM2PR04MB735.namprd04.prod.outlook.com> <C082266B-009B-481D-9224-7B1A05F2397F@ve7jtb.com>
From: Tim Bray <tbray@textuality.com>
Date: Thu, 27 Mar 2014 14:47:45 -0700
Message-ID: <CAHBU6itVGTZoCqJ2F4ezwcTcxzAwMdBBTOzJ5LgcjDYrLpU0nw@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="047d7b66fce74841ba04f59d8a0e"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/RBSq2SVEL9lhhyXJD1hy4baR3qA
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Mar 2014 21:48:11 -0000

I can’t give names or numbers but yeah, it’s happening. Especially for
Android apps, it’s easy & straightforward to get an ID token, and cheap to
validate on the server side.  Obviously, it only works for Google accounts.


On Thu, Mar 27, 2014 at 2:40 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> I don't know what clients are using the play API to get 3rd party tokens.
>
> Perhaps Tim Bray can comment on scale of use if not specific clients.
>
> John B.
>
> On Mar 27, 2014, at 3:36 PM, Lewis Adam-CAL022 <
> Adam.Lewis@motorolasolutions.com> wrote:
>
> I get the idea, but I’m trying to get a feel for whether or not this model
> is being built upon and to what extent.
>
> So if I rephrase … are there known 3rd party AS’s out there in the wild
> that are consuming the Google id_token?
>
> Or any examples of a 3rd-party RS that is directly consuming it?
>
> Looking for actual examples in the wild to point to.
>
> adam
>
> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com <ve7jtb@ve7jtb.com>]
> *Sent:* Thursday, March 27, 2014 1:07 PM
> *To:* Lewis Adam-CAL022
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from
> now
>
> Handing out a id_token with a 3rd party AS or RS as the audience is the
> standard way that Android apps that rely on Google as the source of
> identity work on Android using the Google Play Services.
>
> This describes the API
> http://android-developers.blogspot.ca/2013/01/verifying-back-end-calls-from-android.html
>
> On Mar 27, 2014, at 2:46 PM, Lewis Adam-CAL022 <
> Adam.Lewis@motorolasolutions.com> wrote:
>
>
>  Hi John,
>
> With respect to Google Play handing out id_tokens, are any there any known
> instances of that being used?  Either to kick of an assertion flow with
> another (non-Google) AS, or to present directly to a non-Google RS?
>
> adam
>
> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com <ve7jtb@ve7jtb.com>]
> *Sent:* Thursday, March 27, 2014 9:07 AM
> *To:* Lewis Adam-CAL022
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from
> now
>
> Hi Adam,
>
> 3 is the most common today.  In the Salesforce case it has the additional
> benefit that when Domain 1 is federating to SalesForce via OpenID Connect
> it can provide access tokens for it's API to sales force scoped for that
> user for use in the SalesForce custom logic.
>
> 1 and 2 are similar and likely it is more of a deployment choice between
> them.
> We do see examples of this currently with the Android play store providing
> third-party id_tokens/JWT assertions to OAuth clients.
>
> The reason for doing 1 or 2 vs 3 probably comes down to connivence and
> security if  there is an agent for the user's  IdP on the device that can
> act as a confidential client to the IdP for security and provide a more
> consistent UI for the user.   That is what we are working on in the NAPPS
> WG at OIDF.
>
> We have examples of 1/2 now, the problem is that they are not as
> universally applicable as 3 but hopefully with standardization for
> developers we will se more in the next year or so.
>
> John B.
>
> On Mar 27, 2014, at 10:06 AM, Lewis Adam-CAL022 <
> Adam.Lewis@motorolasolutions.com> wrote:
>
>
>
>  I am curious it ping the thoughts of others on the list of how OAuth is
> going to continue to mature, especially with respect to enterprise
> federation scenarios.  This is something that I spend a whole lot of time
> thinking about.  Specifically, consider the following use case:
>
> An end user in domain 1 downloads a native application to access an API
> exposed by domain 2, to access a protected resource in domain 2, under the
> administrative control of the domain 2 enterprise.
>
>
> There are in my mind three basic means by which OAuth can federate, which
> I know I have discussed with some of you in the past:
>
>
>
> 1.       First option … End user in domain 1 requests a JWT-structured
> access_token from the OAuth provider in domain 1, and sends it in the HTTP
> header directly to the RS in domain 2.   The JWT access_token looks a whole
> lot like a OIDC id_token (maybe it even is one?).  The RS in domain 2 is
> able to make attributed-based access control decisions based on the
> contents of the JWT.  This is architecturally the simplest approach, but
> enterprises aren’t exactly setting up OAuth providers these days for the
> intent of accessing protected resources in foreign domains.  Anybody think
> this might be the case 5 years from now?
>
>
>
> 2.       Second option … similar to the first, but the JWT-structured
> access_token from domain 1 is sent to the OAuth provider in domain 2, ala
> the JWT assertion profile.  Domain 1 access token is exchanged for a domain
> 2 access token, and the native client uses the domain 2 access token to
> send to the protected resource in domain 2.  I like this slightly more than
> the first option, because the resources servers in domain 2 only need to
> understand the token format of their own AS.  But it still suffers from the
> same basic challenge of option 1, that enterprises don’t’ setup OAuth
> providers today for the purpose of federating, the way that setup SAML
> providers for WebSSO.
>
>
>
> 3.       Third option.  Native client contacts the OAuth provider in
> domain 2 directly.  The authorization endpoint is federation enabled
> (NASCAR or other) and the user in domain 1 selects their home IdP (SAML or
> OIDC) and does WebSSO to federated into the domain 2 OAuth provider.  I
> believe this is the model that Salesforce supports today, and it the most
> tactical, since enterprise that want to federate today run out and buy a
> SAML provider.
>
> So option 3 is the most obvious approach today.  Does anybody foresee
> enterprises setting up an STS in the future to federate to foreign RS’s
> (the way they setup SAML providers today)?  Anybody think we will see
> options 1 or 2 in the future?
>
>
> adam
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>