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

Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> Thu, 27 March 2014 13:07 UTC

Return-Path: <Adam.Lewis@motorolasolutions.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id DE0F71A06D2 for <oauth@ietfa.amsl.com>; Thu, 27 Mar 2014 06:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.348
X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dciTViN78R2b for <oauth@ietfa.amsl.com>; Thu, 27 Mar 2014 06:07:11 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com []) by ietfa.amsl.com (Postfix) with ESMTP id A8A121A06E5 for <oauth@ietf.org>; Thu, 27 Mar 2014 06:07:10 -0700 (PDT)
Received: from mail122-ch1-R.bigfish.com ( by CH1EHSOBE007.bigfish.com ( with Microsoft SMTP Server id; Thu, 27 Mar 2014 13:07:07 +0000
Received: from mail122-ch1 (localhost []) by mail122-ch1-R.bigfish.com (Postfix) with ESMTP id CC4B14801EE for <oauth@ietf.org>; Thu, 27 Mar 2014 13:07:07 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg01.am.mot-solutions.com; RD:ct11msg01.mot-solutions.com; EFVD:NLI
X-SpamScore: 2
X-BigFish: VPS2(zzc85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25f6h2605h268bh9a9j1155h)
Received-SPF: pass (mail122-ch1: domain of motorolasolutions.com designates as permitted sender) client-ip=; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg01.am.mot-solutions.com ; olutions.com ;
X-Forefront-Antispam-Report-Untrusted: CIP:; KIP:(null); UIP:(null); (null); H:BL2PRD0410HT004.namprd04.prod.outlook.com; R:internal; EFV:INT
Received: from mail122-ch1 (localhost.localdomain []) by mail122-ch1 (MessageSwitch) id 1395925626611890_2982; Thu, 27 Mar 2014 13:07:06 +0000 (UTC)
Received: from CH1EHSMHS040.bigfish.com (snatpool1.int.messaging.microsoft.com []) by mail122-ch1.bigfish.com (Postfix) with ESMTP id 870372A00D8 for <oauth@ietf.org>; Thu, 27 Mar 2014 13:07:06 +0000 (UTC)
Received: from ct11msg01.am.mot-solutions.com ( by CH1EHSMHS040.bigfish.com ( with Microsoft SMTP Server (TLS) id; Thu, 27 Mar 2014 13:07:02 +0000
Received: from ct11msg01.am.mot-solutions.com (ct11vts02.am.mot.com []) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id s2RD71Dp026490 for <oauth@ietf.org>; Thu, 27 Mar 2014 08:07:01 -0500 (CDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com []) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id s2RD71fY026487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <oauth@ietf.org>; Thu, 27 Mar 2014 08:07:01 -0500 (CDT)
Received: from mail92-tx2-R.bigfish.com ( by TX2EHSOBE003.bigfish.com ( with Microsoft SMTP Server id; Thu, 27 Mar 2014 13:07:00 +0000
Received: from mail92-tx2 (localhost []) by mail92-tx2-R.bigfish.com (Postfix) with ESMTP id 926601A0081 for <oauth@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Thu, 27 Mar 2014 13:07:00 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(53806001)(46102001)(74366001)(87266001)(94946001)(54356001)(85306002)(81542001)(86362001)(54316002)(56776001)(18717965001)(87936001)(2656002)(74876001)(51856001)(33646001)(94316002)(74706001)(15975445006)(97336001)(69226001)(81342001)(93136001)(81816001)(93516002)(95416001)(76482001)(76576001)(19609705001)(63696002)(76786001)(76796001)(79102001)(83072002)(74502001)(47446002)(92566001)(50986001)(47976001)(49866001)(47736001)(4396001)(74662001)(90146001)(31966008)(98676001)(81686001)(74316001)(16236675002)(15202345003)(20776003)(77982001)(66066001)(19300405004)(95666003)(80022001)(97186001)(56816005)(85852003)(76176001)(80976001)(65816001)(59766001)(83322001)(19580395003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR04MB733; H:DM2PR04MB735.namprd04.prod.outlook.com; FPR:AC047219.95269403.B2F37DBB.46E0B871.2035B; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail92-tx2 (localhost.localdomain []) by mail92-tx2 (MessageSwitch) id 139592561875401_18726; Thu, 27 Mar 2014 13:06:58 +0000 (UTC)
Received: from TX2EHSMHS035.bigfish.com (unknown []) by mail92-tx2.bigfish.com (Postfix) with ESMTP id 0C14CC0075 for <oauth@ietf.org>; Thu, 27 Mar 2014 13:06:58 +0000 (UTC)
Received: from BL2PRD0410HT004.namprd04.prod.outlook.com ( by TX2EHSMHS035.bigfish.com ( with Microsoft SMTP Server (TLS) id; Thu, 27 Mar 2014 13:06:56 +0000
Received: from DM2PR04MB733.namprd04.prod.outlook.com ( by BL2PRD0410HT004.namprd04.prod.outlook.com ( with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 27 Mar 2014 13:06:48 +0000
Received: from DM2PR04MB735.namprd04.prod.outlook.com ( by DM2PR04MB733.namprd04.prod.outlook.com ( with Microsoft SMTP Server (TLS) id 15.0.898.11; Thu, 27 Mar 2014 13:06:46 +0000
Received: from DM2PR04MB735.namprd04.prod.outlook.com ([]) by DM2PR04MB735.namprd04.prod.outlook.com ([]) with mapi id 15.00.0898.005; Thu, 27 Mar 2014 13:06:46 +0000
From: Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: OAuth & Enteprise federation ... 5 years from now
Thread-Index: Ac9JvWeAW+r7N2YsS96k1esZSJ97mA==
Date: Thu, 27 Mar 2014 13:06:45 +0000
Message-ID: <c174791bb42e462d813b62a952ded267@DM2PR04MB735.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 01630974C0
Content-Type: multipart/alternative; boundary="_000_c174791bb42e462d813b62a952ded267DM2PR04MB735namprd04pro_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-CFilter-Loop: Reflected
X-OriginatorOrg: motorolasolutions.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/V4a3DbArh-hAjX89VBl0khiUzRE
Subject: [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 13:07:15 -0000

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?