Thanks Carlo and Emmanuel, I learned something new.
Best regards, Pierre Smits *OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/ On Tue, Oct 27, 2015 at 7:00 PM, <[email protected]> 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 [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 ! > > > >
