This might also be interesting: http://www.slideshare.net/coheigea/integrating-apache-syncope-with-apache-cxf
Colm should be able to share more insights. Best regards, Pierre Smits *OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/ On Tue, Oct 27, 2015 at 11:13 PM, Stefan Seelmann <[email protected]> wrote: > 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 ! > > > > > > > >
