directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: Claims based authentication with ApacheDS
Date Tue, 27 Oct 2015 22:13:30 GMT
Is the current work in Kerby on preauth mechanism using JWT also
related? Can Kerberos auth then be used in OAuth2 flows?

Kind Regards,

On 10/27/2015 07:00 PM, wrote:
> Hi Emmanuel, ok thanks for making sense of it!  Sounds like something else wedges between
ApacheDS and an outside REST api. What that is we don't know yet :)
> -----Original Message-----
> From: Emmanuel Lécharny [] 
> Sent: Tuesday, October 27, 2015 1:36 PM
> To:
> Subject: Re: Claims based authentication with ApacheDS
> Le 27/10/15 16:16, a écrit :
>> Hi,
>> We're starting to hear our customers ask for 'claims based authentication' with our
product which back end with  ApacheDS.
>> I've researched it a bit and it's clearly beyond the goals of an LDAP server.
>> My question is, are any of you trying to implement something like this? If so, what
is the stack you're using?
>> What are challenges, benefits, risks?
> AFAIU what the 'Claims base authn' buzz is all about, it's nothing more than some kind
of Kerberos authn system, without the frightening complexity being exposed. The schema you
can find on is similar
to teh one you have on, with one big difference
: in Kerberos, your application does noyt have to check on the authentication broker if the
token is valid or not.
> In some way, it's a weaker protocol (weaker in a sense of the broker will not only be
pounded by clients requesting a token, but also by the application itself that need to check
the token). It makes the broker the real SPOF of your system, when in Kerberos, at least,
the ticket is valid for some period of time - ie, even if the AS is down, you can continue
to work.
> But I can see where it all comes from : on the internet, and especially on the cloud,
ommunicating using a protocol like kerberos is certainly not convenient : each application
has to be known by the Kerberos AS.
> This is not convenient when talking to external services... (not even for internal services
!). I can imagine how easier it is to deploy a brand new application, that only has to know
where is the broker to check the incoming tokens.
> So, yes, basically, it's inferior to Kerberos, at least from a technical POV, but it's
most certainly easier to use, especially now that we can assume that the broker are able to
sustain an extremelly high number of incoming requests, something that was not the case decades
ago when Kerberos was specified (yes, decades : 22 years ago actually ;-)
> What's the possible relation with Apache DS ? Well, if you consider that ApacheDS is
capable of providing some Kerberos Authentication, there is no reason it should not be able
to become a broker. All in all, it's just about being able to accept incoming requests and
answer them.
> ApacheDS has been designed from the very beginning to be exactly that :
> a layer on top of which you implement your protocol (and we have successfully implemented
LDAP, Kerberos, DHCP, DNS, NTP...)
> Now, the question is : how do we do that !

View raw message