directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Carlo.Acco...@ibs-ag.com>
Subject RE: Claims based authentication with ApacheDS
Date Tue, 27 Oct 2015 18:00:39 GMT
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 [mailto:elecharny@gmail.com] 
Sent: Tuesday, October 27, 2015 1:36 PM
To: users@directory.apache.org
Subject: Re: Claims based authentication with ApacheDS

Le 27/10/15 16:16, Carlo.Accorsi@ibs-ag.com 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 http://gunnarpeipman.com/2013/07/what-is-claims-based-authentication/ is similar to
teh one you have on http://www.funtoo.org/Kerberos_With_Funtoo, 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 !



Mime
View raw message