IETF Logo Mail Archive

[OAUTH-WG] Dynamic Client Registration in trusted federation

Matt Pryor - UKRI STFC <Matt.Pryor@stfc.ac.uk> Fri, 01 June 2018 13:57 UTC

Return-Path: <Matt.Pryor@stfc.ac.uk>
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 A429A12D875 for <oauth@ietfa.amsl.com>; Fri, 1 Jun 2018 06:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 RRxyE1YvayLc for <oauth@ietfa.amsl.com>; Fri, 1 Jun 2018 06:57:39 -0700 (PDT)
Received: from smtp-out4.electric.net (smtp-out4.electric.net [192.162.216.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC49212D87B for <oauth@ietf.org>; Fri, 1 Jun 2018 06:57:38 -0700 (PDT)
Received: from 1fOkYg-0003IO-Vz by out4a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from <Matt.Pryor@stfc.ac.uk>) id 1fOkYi-0003Wa-Uo for oauth@ietf.org; Fri, 01 Jun 2018 06:57:36 -0700
Received: by emcmailer; Fri, 01 Jun 2018 06:57:36 -0700
Received: from [130.246.132.234] (helo=exchsmtp.stfc.ac.uk) by out4a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) (Exim 4.90_1) (envelope-from <Matt.Pryor@stfc.ac.uk>) id 1fOkYg-0003IO-Vz for oauth@ietf.org; Fri, 01 Jun 2018 06:57:34 -0700
Received: from exch03.fed.cclrc.ac.uk (130.246.132.234) by exch03.fed.cclrc.ac.uk (130.246.132.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1415.2; Fri, 1 Jun 2018 14:57:34 +0100
Received: from exch03.fed.cclrc.ac.uk ([fe80::25c0:55bd:d31a:d95b]) by exch03.fed.cclrc.ac.uk ([fe80::25c0:55bd:d31a:d95b%7]) with mapi id 15.01.1415.002; Fri, 1 Jun 2018 14:57:34 +0100
From: Matt Pryor - UKRI STFC <Matt.Pryor@stfc.ac.uk>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: Dynamic Client Registration in trusted federation
Thread-Index: AQHT+bB9jLQbu/dxiE+4zzbH9GudLA==
Date: Fri, 01 Jun 2018 13:57:34 +0000
Message-ID: <59B07252-0FEA-433F-9DD7-F3C5A5B8CF66@stfc.ac.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.246.135.148]
x-esetresult: clean, is OK
x-esetid: 37303A295AAF266D607262
Content-Type: text/plain; charset="utf-8"
Content-ID: <D49DCB4A24125E4A93C58594F493756B@fed.cclrc.ac.uk>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-IP: 130.246.132.234
X-Env-From: Matt.Pryor@stfc.ac.uk
X-Proto: esmtps
X-Revdns: exch03.rl.ac.uk
X-HELO: exchsmtp.stfc.ac.uk
X-TLS: TLSv1.2:ECDHE-RSA-AES256-SHA384:256
X-Authenticated_ID:
X-PolicySMART: 3590380
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/AY7Cq0VMBOn3Xt4dLxQgnjRpZS8>
Subject: [OAUTH-WG] Dynamic Client Registration in trusted federation
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, 01 Jun 2018 13:57:42 -0000

Hi,

I am working on a use case of OAuth 2.0 in a federation and am after some advice about bootstrapping trust.

Each site in the federation has an OAuth 2.0 authorization server and an OAuth 2.0 relying party. The relying party at each site needs to be registered with all the authorization servers in the federation. We want to automate as much of this process as possible, but restrict client registration to trusted members of the federation. We also want to make onboarding a new federation member as easy as possible.

This seems an ideal use case for the Dynamic Client Registration Protocol (RFC 7591). The RFC permits the client registration endpoint to require a pre-existing token in order to register a new client which gives us our security (only trusted federation members can register a client).

The challenge seems to be in bootstrapping the initial trust. It seems cumbersome to require that a new federation member must manually obtain a token from each authorization server before registering - they may as well manually register their client. I'd be interested to know if anyone has any ideas for a solution other than securely distributing a shared secret to new federation members.

One possible option is to piggy-back on the legacy authn/z we already have - users can obtain an X509 certificate from their home idp, which is then trusted by all the other sites. We can then obtain SAML assertions about their permissions based on that certificate. We could use this mechanism to maintain a list of trusted admins, requiring authentication with an X509 certificate with the correct SAML assertion for the client registration endpoint. However, we are hoping to retire the X509 support in the short-to-medium term, so I'm also looking for solutions that do not use it. I'm also not sure how the use of X509 certificates would fit in with an RFC-compliant implementation of the Dynamic Client Registration Protocol.

Thanks in advance for your help,
Matt

v2.23.0 | Report a Bug | By Email