You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Pierre Smits <pi...@gmail.com> on 2015/10/27 23:00:52 UTC
Re: Claims based authentication with ApacheDS
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, <Ca...@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 !
>
>
>
>
Re: Claims based authentication with ApacheDS
Posted by Sergey Beryozkin <sb...@gmail.com>.
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, <Ca...@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 !
>>>
>>>
>>>
>>>
>>
>
>
Re: Claims based authentication with ApacheDS
Posted by Sergey Beryozkin <sb...@gmail.com>.
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, <Ca...@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 !
>>>
>>>
>>>
>>>
>>
>
>
Re: Claims based authentication with ApacheDS
Posted by Sergey Beryozkin <sb...@gmail.com>.
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, <Ca...@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 !
>>
>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Claims based authentication with ApacheDS
Posted by Sergey Beryozkin <sb...@gmail.com>.
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, <Ca...@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 !
>>
>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/