Re: [OAUTH-WG] JWT Token on-behalf of Use case

Brian Campbell <bcampbell@pingidentity.com> Mon, 06 July 2015 21:33 UTC

Return-Path: <bcampbell@pingidentity.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 BF0B21A01C6 for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 14:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 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, 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 ewViWdg7dkb8 for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 14:33:20 -0700 (PDT)
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515041A1A4B for <oauth@ietf.org>; Mon, 6 Jul 2015 14:33:18 -0700 (PDT)
Received: by igrv9 with SMTP id v9so163479548igr.1 for <oauth@ietf.org>; Mon, 06 Jul 2015 14:33:17 -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=npRhJlXvRp53EcIfMeG8UlouyII0g1vzaAWekBAIwxQ=; b=iiE5d1C9QKpoKhInmwWYiWP/NNjiCG2sD8Fzdol9g0vUl8/Hj8ykgPXaXak/kkgcJa mKCZ6e751mC0lgHNRYrZDC7B+9ygU7oXq0cxMEE6qKQgoM2l+3jZZsQxTO8uw8kfWfst F3yb9QyUFShr5e66BlkOQswoFpWVqQeEjTQVmqO5uEsxZ5f9vAhxweK9ERFbGmcZbzXd 3r2pF2OOqWWynXBexJlYcgbjVecCcfX15QvzmQawdWWdhC7gGpkf26/wBmJNOdsUls5y lzlMW8FNGBpxrAlEqHUioWhizr9iwWHfcExdROYgGJQYz9p8Hwm4m+3O60ZnOvEHmOkO j9zw==
X-Gm-Message-State: ALoCoQnuxVBZqbwKb1ikKkZFMiudf7J2Kl5tGt91GvgQWmbf3hfqajLkcjCqYYTyQh4pBUmy/TQ4
X-Received: by 10.107.128.72 with SMTP id b69mr1362908iod.84.1436218397626; Mon, 06 Jul 2015 14:33:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.64.209 with HTTP; Mon, 6 Jul 2015 14:32:48 -0700 (PDT)
In-Reply-To: <CY1PR0301MB12437C5CFE06B7837375E5DBA6930@CY1PR0301MB1243.namprd03.prod.outlook.com>
References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <BY2PR03MB442205D40E8F1ECD88082F2F5AE0@BY2PR03MB442.namprd03.prod.outlook.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <CA+k3eCTA+HmwnMBUBzD7FKYWL37BMA7az_2BE+vnqqpO3=2utw@mail.gmail.com> <559A676F.3070008@gmail.com> <CA+k3eCTJsLqn88K4qEYJUzoxwAH4boWGsvJZtZi8guvV6C6zSA@mail.gmail.com> <DEAFAD4A-36F8-47D7-813D-35948CDCEA2C@ve7jtb.com> <BY2PR03MB44276C3D04E3FE5AE238298F5930@BY2PR03MB442.namprd03.prod.outlook.com> <CA+k3eCTRK9ND5c2HbDU=3ctZ3J4u3HMA2QHNZfEpwtfcwiLxfQ@mail.gmail.com> <CY1PR0301MB12437C5CFE06B7837375E5DBA6930@CY1PR0301MB1243.namprd03.prod.outlook.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 6 Jul 2015 15:32:48 -0600
Message-ID: <CA+k3eCSDYbxTTZ2BakTo0=AczmXbF+JbcFu81OfwFUYpmfLVSg@mail.gmail.com>
To: Anthony Nadalin <tonynad@microsoft.com>
Content-Type: multipart/alternative; boundary=001a113f96d06931c6051a3ba7c6
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/UAeG4hoi4UxWY004qDI91eFLrYM>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 06 Jul 2015 21:33:26 -0000

A natural usage of act-as or impersonation
<http://www.oxforddictionaries.com/us/definition/american_english/impersonate>
would suggest, to many people anyway, that the way you just used the terms
is reversed. The bold text below from
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
uses 'impersonates' and "on-behalf-of" contrary to what you just wrote
about Windows Kerb. That's where the assertion that the draft has them
reversed from de facto usage in WS-Trust. Those semantics are not only one
open issue that needs to be resolved, however, even if they occupy most of
the discussion.

1.3.  On-Behalf-Of vs. Impersonation Semantics

   When principal A acts on behalf of principal B, A is given all the
   rights that B has within some defined rights context.  Whereas, *with*
*   on-behalf-of semantics, principal A still has its own identity*
*   separate from B and it is explicitly understood that while B may have*
*   delegated its rights to A, any actions taken are being taken by A and*
*   not B. In a sense, A is an agent for B.*

   On-behalf-of semantics are therefore different than impersonation
   semantics, with which it is sometimes confused.  *When principal A*
*   impersonates principal B, then in so far as any entity receiving*
*   Claims is concerned, they are actually dealing with B. *It is true
   that some members of the identity system might have awareness that
   impersonation is going on but it is not a requirement.  For all
   intents and purposes, when A is acting for B, A is B.







On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin <tonynad@microsoft.com>
wrote:

>  The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition
> (impersonation)  feature as this enables an account to impersonate another
> account for the purpose of providing access to resources. In a typical
> scenario, the impersonating account would be a service account assigned to
> a web application or the computer account of a web server. The impersonated
> account would be a user account requiring access to resources (e.g. data in
> an SQL database) via a web application. In this scenario, SQL server would
> be accessed by the impersonating (service account) account, however access
> would be under the context of the impersonated (user) account.
>
>
>
> WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation
> feature, which lets you limit the back-end services for which a front-end
> service can request tickets on behalf of another user. “OnBehalfOf”  allows
> a selected services on a server can be granted for access by the
> impersonating account, whilst other services on the same server, or
> services on other servers are denied for access.
>
>
>
> Maybe someone can summarize why they think the text for ActAs and
> OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have
> not seen a clear explanation other than John saying that Brian knows and
> Brian saying John knows.
>
>
>
> Our usage and use cases are based upon the deployed services of WS-Trust
> and Kerberos support in Windows (workstation and server) and Xbox.
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Monday, July 6, 2015 11:29 AM
> *To:* Mike Jones <Michael.Jones@microsoft.com>
> *Cc:* oauth <oauth@ietf.org>
>
> *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case
>
>
>
> Stating specific action items resulting from the ad-hoc meeting in Dallas
> like that suggests some clear consensus was reached, which is not at all
> the case. As I recall, several of us argued past one another for an hour or
> so and decided to adjourn in order to go to the bar (okay, and dinner too -
> but mostly beer).
>
> The impression about reversal of terms, I think, comes from the text in
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
> which hurts my head a little every-time I read it but does seems to confuse
> things. The MSDN link
> <https://msdn.microsoft.com/en-us/library/ee748487.aspx> John gave is
> much more to the point than WS-Trust (I don't believe WS-Trust can be
> pointed to as a model of clarity).  In the draft I wrote, I tried to take
> Mike's text and clarify a distinction between impersonation and delegation
> with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3
> and then also be very explicit about act-as vs. on-behalf-of in the
> parameter definitions at
> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a
> manor that was consistent with WS-Trust and the MSDN explanation. I could
> see value in breaking with that shaky legacy and using new terms too. But I
> get the point of trying to keep with the old also and potential for even
> more confusing by using new terms.
>
> I wrote draft-campbell-oauth-sts last year in response to the call for
> adoption of jones-oauth-token-exchange (thread from the archive
> <https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html>).
> Though I didn't try and stand in the way and indicated a willingness to
> collaborate on things. With the expectation, of course, that the details
> would differ from the -00s and -01s as work progressed. Folks seemed generally
> amenable to that
> <https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html> at
> the time but little has happened since then.
>
> Phil's earlier point about the priory of this getting pushed down has some
> truth to it. But I still believe it's something that can provide a lot of
> value in standardizing, if we do so in a reasonable way.
>
>
>
>
>
>
>
>
>
> On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
> It would surprise me if on-behalf-of and act-as were reversed with respect
> WS-Trust, because the explanations of the terms came directly from WS-Trust
> 1.4.  I also think the chances of us reducing confusion by inventing new
> terminology, rather than adding to it, would not be in our favor. :-/
>
> FYI, the action items outstanding from our ad-hoc meeting on this draft in
> Dallas are:
>   - Allowing security types other than JWT to also be used as the act_as
> and on_behalf_of request values.
>   - Further integrating the mechanism into the existing OAuth ecosystem -
> allowing use of access tokens or refresh tokens when appropriate.
>
> I plan to do the first today.  The second is probably more than I'll get
> done today before the submission cutoff.  I agree with John that it would
> be useful to have discussions on this in Prague on the best way to achieve
> this further integration.  I'll plan to come into the Prague meeting with a
> concrete proposal for review.
>
>                                 Best wishes,
>                                 -- Mike
>
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
> Sent: Monday, July 06, 2015 8:13 AM
> To: Brian Campbell
> Cc: oauth
> Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
>
> Yes unfortunately we haven’t made any progress on this since accepting
> Mike’s first draft.
>
> His proposal is basically for a new endpoint while Brian tired to fit it
> into the existing token endpoint.
>
> I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs
> reversed compared to WS-Trust 1.4.
> see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short
> explanation.
>
> I think Brian is closer in explaining it.
>
> In fairness because WS-Trust originally only had On-Behalf-Of the naming
> and what people put in tokens is a bit muddled in many implementations.
> I think many times it is how WIF implemented it that people copied.
>
> It may be better to have new terms that are clear such as impersonation
> and composite.
>
> The WG needs to decide if this is going to be an entirely new endpoint,
> free of the Token endpoint semantics.   There are plusses and minuses to
> both options.
>
> Also while it is nice to be pure and talk about abstract security tokens,
> it would be good to give some guidance on what a composite security token
> would look like for interoperability.
>
> There are also issues around how this would work with proof of possession
> security tokens, both as input and output.
>
> Perhaps we can make some progress on this in Prague.
>
> John B.
>
>
>
>
> > On Jul 6, 2015, at 11:04 AM, Brian Campbell <bcampbell@pingidentity.com>
> wrote:
> >
> > Thanks Sergey,
> >
> > The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0
> and thus hopefully familiar to developers and easy to understand and
> implement (especially from the client side). It's also intended to be
> flexible in order to accommodate a variety of use-cases including the
> chaining type cases that Justin's draft covers.
> >
> > Specifying a security_token_type of the returned token is just a way of
> providing more info to the client about the token (i.e. is this a JWT or a
> SAML token or something else) via a URI. It's not always needed but in STS
> style cases the tokens are not always opaque to the client and the
> parameter just provides info about the returned token.
> >
> > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <sberyozkin@gmail.com>
> wrote:
> > Hi Brian
> >
> > I've read the text, I like it is still pure OAuth2, with few extra
> parameters added to the access token request, and a key response property
> being 'access_token' as opposed to 'security_access_token' as in the
> draft-ietf-oauth-token-exchange-01.
> > It appears draft-campbell-oauth-sts-01 can cover a
> draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?)
> property being an original client token but not 100% sure given
> draft-richer-oauth-chain-00 covers a specific case.
> >
> > One thing I'm not sure about is what is the purpose of specifying a
> > security_token_type of the returned access token
> >
> > Thanks, Sergey
> >
> > On 01/07/15 15:59, Brian Campbell wrote:
> > One problem, I think, with token exchange is that it can be really
> > simple (token in and token out) and really complicated (client X wants
> > a token that says user A is doing something on behalf of user B) at
> > the same time.
> >
> > I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in
> > an attempt to simplify things and express what I envisioned as an
> > OAuth based token exchange framework. Though it likely only muddied
> > the waters :)
> >
> > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <sberyozkin@gmail.com
> > <mailto:sberyozkin@gmail.com>> wrote:
> >
> >     Hi Justin
> >
> >     https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much
> >     easier to read, that I can tell for sure, at least it is obvious why
> >     a given entity (RS1) may want to exchange the current token provided
> >     by a client for a new token. Definitely easily implementable...
> >
> >     One thing I'm not sure in the draft-richer-oauth-chain-00 about is
> >     on behalf of whose entity RS1 will be acting once it starts
> >     accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO +
> >     Client), or may be it is On Behalf Of RO + Act As Client ? The last
> >     one seems most logical to me...
> >
> >     Thanks, Sergey
> >
> >
> >     On 01/07/15 13:18, Justin Richer wrote:
> >
> >         As it's written right now, it's a translation of some WS-*
> >         concepts into
> >         JWT format. It's not really OAuth-y (since the client has to
> >         understand
> >         the token format along with everyone else, and according to the
> >         authors
> >         the artifacts might not even be "OAuth tokens"), and that's my
> main
> >         issue with the document. Years ago, I proposed an OAuth-based
> >         token swap
> >         mechanism:
> >
> >         https://tools.ietf.org/html/draft-richer-oauth-chain-00
> >
> >         This works without defining semantics of the tokens themselves,
> just
> >         like the rest of OAuth. I've proposed to the authors of the
> current
> >         draft that it should incorporate both semantic (using JWT) and
> >         syntactic
> >         (using a simple token-agnostic grant) token swap mechanisms, and
> >         that
> >         the two could be easily compatible.
> >
> >            -- Justin
> >
> >         On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:
> >
> >             Hmm... perhaps the clue is in the draft title,
> >             token-exchange, so may
> >             be it is a case of the given access token ("on_behalf_of" or
> >             "act_as"
> >             claim) being used to request a new security token. One can
> >             only guess
> >             though, does not seem like the authors are keen to answer
> >             the newbie
> >             questions...
> >
> >             Cheers, Sergey
> >
> >
> >             On 30/06/15 13:38, Sergey Beryozkin wrote:
> >
> >                 Hi,
> >                 Can you please explain what is the difference between
> >                 On-Behalf-Of
> >                 semantics described in the
> >                 draft-ietf-oauth-token-exchange-01 and the
> >                 implicit On-Behalf-Of semantics a client OAuth2 token
> >                 possesses ?
> >
> >                 For example, draft-ietf-oauth-token-exchange-01 mentions:
> >
> >                 "Whereas, with on-behalf-of semantics, principal A still
> >                 has its own
> >                 identity separate from B and it is explicitly understood
> >                 that while B
> >                 may have delegated its rights to A, any actions taken
> >                 are being taken by
> >                 A and not B. In a sense, A is an agent for B."
> >
> >                 This is a typical case with the authorization code flow
> >                 where a client
> >                 application acts on-behalf-of the user who authorized
> >                 this application ?
> >
> >                 Sorry if I'm missing something
> >
> >                 Cheers, Sergey
> >                 On 25/06/15 22:28, Mike Jones wrote:
> >
> >                     That’s what
> >
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01
> >                     is
> >                     about.
> >
> >                     Cheers,
> >
> >                     -- Mike
> >
> >                     *From:*OAuth [mailto:oauth-bounces@ietf.org
> >                     <mailto:oauth-bounces@ietf.org>] *On Behalf Of
> *Vivek
> >                     Biswas
> >                     -T (vibiswas - XORIANT CORPORATION at Cisco)
> >                     *Sent:* Thursday, June 25, 2015 2:20 PM
> >                     *To:* OAuth@ietf.org <mailto:OAuth@ietf.org>
> >                     *Subject:* [OAUTH-WG] JWT Token on-behalf of Use
> > case
> >
> >                     Hi All,
> >
> >                         I am looking to solve a use-case similar to
> >                     WS-Security On-Behalf-Of
> >
> > <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1
> > .4-errata01-os-complete.html#_Toc325658980>
> >
> >
> >                     with OAuth JWT Token.
> >
> >                         Is there a standard claim which we can define
> >                     within the OAuth JWT
> >                     which denote the On-behalf-of User.
> >
> >                     For e.g., a Customer Representative trying to create
> >                     token on behalf of
> >                     a customer and trying to execute services specific
> >                     for that specific
> >                     customer.
> >
> >                     Regards,
> >
> >                     Vivek Biswas,
> >                     CISSP
> >
> >                     *Cisco Systems, Inc <http://www.cisco.com/>*
> >
> >                     *Bldg. J, San Jose, USA,*
> >
> >                     *Phone: +1 408 527 9176
> > <tel:%2B1%20408%20527%209176 <%2B1%20408%20527%209176>>*
> >
> >
> >
> >                     _______________________________________________
> >                     OAuth mailing list
> >                     OAuth@ietf.org <mailto:OAuth@ietf.org>
> >                     https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> >             _______________________________________________
> >             OAuth mailing list
> >             OAuth@ietf.org <mailto:OAuth@ietf.org>
> >             https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >         _______________________________________________
> >         OAuth mailing list
> >         OAuth@ietf.org <mailto:OAuth@ietf.org>
> >         https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >     _______________________________________________
> >     OAuth mailing list
> >     OAuth@ietf.org <mailto:OAuth@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>