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: =?UTF-8?Q?Cl=c3=a9ment_OUDOT?= <clement.oudot@savoirfairelinux.com>
Organization: Savoir-Faire Linux
Message-ID: <d49c35f3-6b00-614c-4ce0-5dba7d884c73@savoirfairelinux.com>
Date: Mon, 5 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