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:09:00 GMT
That also works for JAX-WS if needed... Colm may have more info about 
it, once he gets back...

On 27/10/15 22:07, Sergey Beryozkin wrote:
> Hi
> 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 !

View raw message