Re: [ldapext] Request for feedback: draft-wibrown-ldapssotoken
Clément OUDOT <clement.oudot@savoirfairelinux.com> Mon, 05 September 2016 16:00 UTC
Return-Path: <clement.oudot@savoirfairelinux.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32610128E18 for <ldapext@ietfa.amsl.com>; Mon, 5 Sep 2016 09:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.639
X-Spam-Level:
X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 yJ6oyWCdvIRX for <ldapext@ietfa.amsl.com>; Mon, 5 Sep 2016 09:00:53 -0700 (PDT)
Received: from mail.savoirfairelinux.com (mail.savoirfairelinux.com [208.88.110.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2CAD127A90 for <ldapext@ietf.org>; Mon, 5 Sep 2016 09:00:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.savoirfairelinux.com (Postfix) with ESMTP id 6B5C76203A0 for <ldapext@ietf.org>; Mon, 5 Sep 2016 12:00:52 -0400 (EDT)
Received: from mail.savoirfairelinux.com ([127.0.0.1]) by localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 2M-Wqu4uVfbS for <ldapext@ietf.org>; Mon, 5 Sep 2016 12:00:50 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by mail.savoirfairelinux.com (Postfix) with ESMTP id AAA1D6204C6 for <ldapext@ietf.org>; Mon, 5 Sep 2016 12:00:50 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.savoirfairelinux.com
Received: from mail.savoirfairelinux.com ([127.0.0.1]) by localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8-MPKJKqzYDT for <ldapext@ietf.org>; Mon, 5 Sep 2016 12:00:50 -0400 (EDT)
Received: from [192.168.47.134] (LStLambert-656-1-262-71.w193-248.abo.wanadoo.fr [193.248.50.71]) by mail.savoirfairelinux.com (Postfix) with ESMTPSA id 0946C6203A0 for <ldapext@ietf.org>; Mon, 5 Sep 2016 12:00:49 -0400 (EDT)
To: ldapext@ietf.org
References: <1473028512.26123.43.camel@redhat.com>
From: Clément OUDOT <clement.oudot@savoirfairelinux.com>
Organization: Savoir-Faire Linux
Message-ID: <d49c35f3-6b00-614c-4ce0-5dba7d884c73@savoirfairelinux.com>
Date: Mon, 05 Sep 2016 18:00:47 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <1473028512.26123.43.camel@redhat.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ldapext/QgeFPgy9blmfZEWMsg4s2y7a8H8>
Subject: Re: [ldapext] Request for feedback: draft-wibrown-ldapssotoken
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Sep 2016 16:00:56 -0000
Le 05/09/2016 à 00:35, William Brown a écrit : > Hi, > > I would like to ask for feedback on the submission > draft-wibrown-ldapssotoken [0]. Section 5 deals with the ldap components > of the implementation. > > Thank you for your time and advice, > > [0] https://datatracker.ietf.org/doc/draft-wibrown-ldapssotoken/ > Hi, this draft is really interesting and indeed provides a solution when no Kerberos is available. I was wondering if we could not get quite same behavior with proxy authentication and standard single-sign on mechanisms: the user is known by the web application trough token (JWT or whatever) and then the web application authenticates for this user using LDAP proxy authz. Other remark, you don't give any hint on how the LDAP server should manage its token database. Maybe it is intended as each LDAP server should implement its own way, but we may think of standard LDAP objects that could be used to manage these tokens directly in LDAP, instead of using a separate database? Regards, -- Clément OUDOT Consultant en logiciels libres, Expert infrastructure et sécurité Savoir-faire Linux
- [ldapext] Request for feedback: draft-wibrown-lda… William Brown
- Re: [ldapext] Request for feedback: draft-wibrown… Clément OUDOT
- Re: [ldapext] Request for feedback: draft-wibrown… William Brown