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:[email protected]]
Sent: Tuesday, October 27, 2015 1:36 PM
To: [email protected]
Subject: Re: Claims based authentication with ApacheDS
Le 27/10/15 16:16, [email protected] 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 !
