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 !
