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

Paul Madsen <paul.madsen@gmail.com> Thu, 27 March 2014 13:29 UTC

Return-Path: <paul.madsen@gmail.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 D92741A00F8 for <oauth@ietfa.amsl.com>; Thu, 27 Mar 2014 06:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Q1G_NquW_jqm for <oauth@ietfa.amsl.com>; Thu, 27 Mar 2014 06:29:53 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CF9D51A00B4 for <oauth@ietf.org>; Thu, 27 Mar 2014 06:29:52 -0700 (PDT)
Received: by mail-ig0-f170.google.com with SMTP id uq10so1457731igb.3 for <oauth@ietf.org>; Thu, 27 Mar 2014 06:29:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=kVjWvD1aM6Dj0/JziMamIsMhh9CU0TOsnjzZggqnYx8=; b=I7StJCjknzTALhnmJfeqEiv/qicd6k4VDUgynkHozYcQAYGOgy+CivKv35i8ZL395w vMvnq1VmQa9LOGBfo4P/4SFR92+XhoxPCQ9lO/olYkaeapMdjFHEOFwxUHLGCkiCCuoZ VcQi3kAlduNjTI89DuKGzxyneu5nLCWraldyBbyIMt4mMMW26UeZc6t5G+wQXpfP4tc8 nudbu/h2Csp9v0zmYSP4cYCaPnpSi0dpm4o7kxHlYgC0Qx6HSEfpEbJMqhcLJYIsJQSh QFmYiqlaJSpBHUyOFRzPEG5H5lqTvxk/7M9535oUrCQKe6sfhm3kQuPnT4zI2/ySXX5F sDCA==
X-Received: by 10.43.61.206 with SMTP id wx14mr1853342icb.43.1395926990921; Thu, 27 Mar 2014 06:29:50 -0700 (PDT)
Received: from [192.168.0.191] (CPE0022b0cb82b4-CMbc1401e98fa0.cpe.net.cable.rogers.com. [99.224.82.58]) by mx.google.com with ESMTPSA id bf7sm5307107igb.9.2014.03.27.06.29.48 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Mar 2014 06:29:50 -0700 (PDT)
Message-ID: <533427CC.90800@gmail.com>
Date: Thu, 27 Mar 2014 09:29:48 -0400
From: Paul Madsen <paul.madsen@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com>, "oauth@ietf.org" <oauth@ietf.org>
References: <c174791bb42e462d813b62a952ded267@DM2PR04MB735.namprd04.prod.outlook.com>
In-Reply-To: <c174791bb42e462d813b62a952ded267@DM2PR04MB735.namprd04.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------070002090302070101080009"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zceqPUrKRpJparDmZfOhvSgFTHY
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 13:29:56 -0000

Hi Adam, we are confronting this issue in the NAPPS effort and are 
exploring a model that resembles your Option 2

The Token Agent (TA) obtains an id-token from the first AS1, this 
targetted at the second AS2 (the one local to the target RS). The TA 
then exchanges that id_token at AS2 for an access token that the RS will 
be able to validate

Option 3 is indeed today's default for layering federation onto OAuth

paul

On 3/27/14, 9:06 AM, Lewis Adam-CAL022 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