Mailing-List: contact users-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@directory.apache.org
Subject: Re: Claims based authentication with ApacheDS
To: users@cxf.apache.org,
 Apache Directory Users List <users@directory.apache.org>
References: <53f83db11dc64fb4b7db826a2c775563@IBSMSX2.ibs-ag.com>
 <562FB608.6080703@gmail.com>
 <6d63682d77e94b339b2fa2e58db82725@IBSMSX2.ibs-ag.com>
 <CADPkm84+R7vxpiVc_2aBG4m1DqdVLzo-pVDGESV+DG7+qRhkJw@mail.gmail.com>
 <562FF587.3060307@gmail.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <562FF5FC.6030302@gmail.com>
Date: Tue, 27 Oct 2015 22:09:00 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <562FF587.3060307@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

That also works for JAX-WS if needed... Colm may have more info about 
it, once he gets back...

Sergey
On 27/10/15 22:07, Sergey Beryozkin wrote:
> Hi
>
> I'm not sure if it is related but we have a claim-based access control,
> with the claims representing some attributes from a SAML token (which
> represents an authenticated client). That will need to be also mapped
> for JWT assertions though...
>
> http://cxf.apache.org/docs/jax-rs-saml.html#JAX-RSSAML-ClaimsBasedAccessControl
>
>
> Cheers, Sergey
> On 27/10/15 22:00, Pierre Smits wrote:
>> Carlo,
>>
>> You might have a look at Apache CXF, that might be a solution to help you
>> out.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *OFBiz Extensions Marketplace*
>> http://oem.ofbizci.net/oci-2/
>>
>> On Tue, Oct 27, 2015 at 7:00 PM, <Carlo.Accorsi@ibs-ag.com> 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:elecharny@gmail.com]
>>> Sent: Tuesday, October 27, 2015 1:36 PM
>>> To: users@directory.apache.org
>>> Subject: Re: Claims based authentication with ApacheDS
>>>
>>> Le 27/10/15 16:16, Carlo.Accorsi@ibs-ag.com 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 !
>>>
>>>
>>>
>>>
>>
>
>