directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Claims based authentication with ApacheDS
Date Tue, 27 Oct 2015 22:07:03 GMT

I'm not sure if it is related but we have a claim-based access control, 
with the claims representing some attributes from a SAML token (which 
represents an authenticated client). That will need to be also mapped 
for JWT assertions though...

Cheers, Sergey
On 27/10/15 22:00, Pierre Smits wrote:
> Carlo,
> You might have a look at Apache CXF, that might be a solution to help you
> out.
> Best regards,
> Pierre Smits
> *OFBiz Extensions Marketplace*
> On Tue, Oct 27, 2015 at 7: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 !

Sergey Beryozkin

Talend Community Coders

View raw message