Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

Brian Campbell <bcampbell@pingidentity.com> Fri, 28 July 2017 22:29 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165CB13230E for <oauth@ietfa.amsl.com>; Fri, 28 Jul 2017 15:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
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 i92afWHVyu7x for <oauth@ietfa.amsl.com>; Fri, 28 Jul 2017 15:29:06 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 7DF7F1322FB for <oauth@ietf.org>; Fri, 28 Jul 2017 15:29:06 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id d67so32554554pfc.0 for <oauth@ietf.org>; Fri, 28 Jul 2017 15:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JElRXVogZovj70PbkPGPWlDU2mfQcGHyD6d7m+9u920=; b=Aw7ho0UNV5zf2w7aZKDBFP8gpb+wDLVLf+fy+EtVk3IjdxbaIBRmFerOVXRD2AEzia Xl4Mp26+yitl168AqQMQoCvEVlXCbQGjEelzIj8Mxg1iW4t6hAwDjYq7IygdI8WBv7N5 ZMzNuv0b3HvOV3MmKPV/hbXPS9qBqwum0j8co=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JElRXVogZovj70PbkPGPWlDU2mfQcGHyD6d7m+9u920=; b=QPJhjpYrB49L/mIvD079N32BVdWcLjgOOaVOGTTM00/f89FKZuhW967/eNocD5PG2J 0NmDwduh9xddiYZGxToyitXt/TE7rAzzZkFzXRO5SR5zaWmNpNgcL3LcziIKXr2eayU8 VQAWsWHFAjVrae8SgwMGWKFsbV7iNvGGOsnlzeRMxswxKg3TZDDvBWivWdRsF9j5ha6a B/+DKI/b2J+2f82X7YqTzi+EN7xQ5AXrRZ0p1lVIOzfRoUQOjmiv61hLGxxZBIPb45sg C+H37vaqEIV6dQSCvLL6VO1N8zSccgjrKqOQca+3ISw1j/qkXI0LBMmQq1WC8pjyHK/O RuuA==
X-Gm-Message-State: AIVw112ZQEdLoRgtAQ2lfZ+Z1IndqO/1AbtSsAN1P6zACfwwcqNOg/1b 1qUu0OkKxx+V9dHo5MLzfWEhYuzD6gEhUITJlfGRyou9haF+IHyNFe66XXRPcHZQDmcIpG5JbEh NA18H
X-Received: by 10.84.232.143 with SMTP id i15mr9343562plk.248.1501280946105; Fri, 28 Jul 2017 15:29:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Fri, 28 Jul 2017 15:28:35 -0700 (PDT)
In-Reply-To: <fa2e98ad-cb95-a142-7989-4bfd422de06b@redhat.com>
References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> <CA+k3eCQCKtBct-iqxJCscad3rkUDUyx-MDbGa0Ysb995wX2BUA@mail.gmail.com> <fa2e98ad-cb95-a142-7989-4bfd422de06b@redhat.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 28 Jul 2017 16:28:35 -0600
Message-ID: <CA+k3eCTzTO54xvekYoY=TkL4dxYupg+C6-K9dsduqCS9NLspdg@mail.gmail.com>
To: Bill Burke <bburke@redhat.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="f40304361ef480582805556835f8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Kuo0K9UjQFNTSBdsnTablsq_orc>
Subject: Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 28 Jul 2017 22:29:09 -0000

The urn:ietf:params:oauth:token-type:access_token type is an "indicator
that the token is a typical OAuth access token issued by the authorization
server in question" (see near the end of section 3
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-3>)
so the issuer is the given STS in that case. Cross domain is possible by
use of other token types that are not opaque to the STS where the issuer
can be inferred from the token.

On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke <bburke@redhat.com>; wrote:

> Thanks for replying,
>
> The Introduction of the spec implies that inter-security-domain exchange
> is supported: "
>
>  A Security Token Service (STS) is a service capable of validating and
>    issuing security tokens, which enables clients to obtain appropriate
>    access credentials for resources in heterogeneous environments or
>    across security domains.
> "
>
> But with the current API if you want to exchange an external token to an internal one, there is no way for the STS to identify where the subject_token originated.  Are you saying that an STS cannot accept tokens from an external domain?
>
> i.e
>
> subject_token: <opaque-string>
>
> subject_token_type: urn:ietf:params:oauth:token-type:access-token
>
> There's just no way for the STS to know where the subject_token came from
> because the subject_token can be completely opaque.
>
> Now, on the flip side, if you are converting from an internal token to an
> external one, the audience parameter is just too undefined.  For example,
> how could you specify that you want a token for an external client of an
> external issuer.  Client ids are opaque in OAuth, and issuer id isn't even
> something that is defined at all.  In OpenID connect, an issuer id can be
> any URL.
>
> IMO, adding optional "subject_token_issuer" and "requested_issuer"
> parameters only clarifies and simplifies the cross-domain case.   If you
> don't like "issuer" maybe "domain" is a better word?
>
> Thanks for replying,
>
> Bill
>
>
>
>
>
> On 7/28/17 4:39 PM, Brian Campbell wrote:
>
> In general, an instance of an AS/STS can only issue tokens from itself.
> The audience/resource parameters tell the AS/STS where the requested token
> will be used, which will influence the audience of the token (and maybe
> other aspects). But the issuer of the requested token will be the AS/STS
> that issued it. A cross domain exchange could happen by a client presenting
> a subject_token from a different domain/issuer (that the AS/STS trusts) and
> receiving a token issued by that AS/STS suitable for the target domain.
>
>
>
> On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke <bburke@redhat.com>; wrote:
>
>> Should probably have a "subject_issuer" and "actor_issuer" as well as the
>> "requested_issuer" too.
>>
>> FYI, I'm actually applying this spec to write a token exchange service to
>> connect various product stacks that have different and often proprietary
>> token formats and architectures.
>>
>>
>>
>> On 7/26/17 6:44 PM, Bill Burke wrote:
>>
>>> Hi all,
>>>
>>> I'm looking at Draft 9 of the token-exchange spec.  How would one build
>>> a request to:
>>>
>>> * exchange a token issued by a different domain to a client managed by
>>> the authorization server.
>>>
>>> * exchange a token issued by the authorization server (the STS) for a
>>> token of a different issuer and different client.  In other words, for a
>>> token targeted to a specific client in a different authorization server or
>>> realm or domain or whatever you want to call it.
>>>
>>> * exchange a token issued by a different issuer for a token of a
>>> different issuer and client.
>>>
>>> Is the spec missing something like a "requested_issuer" identifier?
>>> Seems that audience is too opaque of a parameter for the authz server to
>>> determine how to exchange the token.
>>>
>>> Thanks,
>>>
>>> Bill
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
>
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*