Is the current work in Kerby on preauth mechanism using JWT also related? Can Kerberos auth then be used in OAuth2 flows?
Kind Regards, Stefan On 10/27/2015 07: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 ! > > >
