You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2011/09/15 16:27:06 UTC
[DISCUSS] - STS framework implementation contribution
All,
I would like to initiate a discussion on contributing a STS (Security
Token Service) framework implementation to CXF. CXF currently has an
STS framework in the ws-security module, and ships with a simple
implementation in the examples. Talend would like to contribute a more
sophisticated implementation of the STS framework to the community. It
supports the following standards:
STS support
- WS-Trust 1.3/1.4
- WS-SecurityPolicy
Supports the following mechanism to authenticate an RST:
- UsernameToken
- SAML token (1.1/2.0)
- KerberosToken
- X509 Token
Following security bindings are supported:
- Symmetric
- Asymmetric
- Transport
Supports Issue/Validate and Cancel binding
Can issue the following tokens:
- SAML 1.1/2.0
- Holder-Of-Key
- Bearer
- custom tokens
Issued token can be encrypted
Validate binding supports issuing a new token.
Custom Validator can be implemented
Creation of SAML tokens can be customized:
- authenticationstatement
- attributestatements
Advanced RST elements:
- KeyType (Public, Symmetric, Bearer)
- Entropy (Symmetric, Public)
- OnBehalfOf
- ActAs
- Claims
- SecondaryParameters
- Custom ClaimsHandler
In my opinion, this implementation will greatly enhance CXF's security
story and will help to drive new users to the product. I would like to
ask the CXF community for their opinion on this contribution (+1/-1?).
I would also like to ask for opinions on where it should go in the
source - a new services module, or perhaps a subproject?
Colm.
--
Colm O hEigeartaigh
http://coheigea.blogspot.com/
Talend - http://www.talend.com
Re: [DISCUSS] - STS framework implementation contribution
Posted by Colm O hEigeartaigh <co...@apache.org>.
Ok cool. It sounds like people are happy with this contribution. I'll
add an initial version into a new services module on trunk.
Colm.
On Fri, Sep 16, 2011 at 3:23 AM, Willem Jiang <wi...@gmail.com> wrote:
> +1 for we introduce a services module to house these kind of Service which
> is based on CXF and can be use out of box :)
>
> It could be helpful for the user to use this kind of Enterprise service more
> easily.
>
> On 9/16/11 1:07 AM, Daniel Kulp wrote:
>>
>>
>> On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
>>>
>>> ....
>>> In my opinion, this implementation will greatly enhance CXF's security
>>> story and will help to drive new users to the product. I would like to
>>> ask the CXF community for their opinion on this contribution (+1/-1?).
>>
>>
>> As someone who's been trying to push for this in Talend, I'm obviously +1
>> to the idea. This is very similar to the discussion we had back in July
>> [1] about moving the WS-Notification stuff from
>> ServiceMix into CXF. Obviously no work has been done toward that (yet),
>> but I still support the idea of being able to have "out of the box" some of
>> these enterprise level services that can make
>> using CXF in more complex environments easier and more approachable.
>>
>>> I would also like to ask for opinions on where it should go in the
>>> source - a new services module, or perhaps a subproject?
>>
>> I personally prefer creating a new "services/sts" directory in cxf/trunk
>> to house this. One problem with subprojects is they seem to attract their
>> little sub-communities and they end up really
>> being separate from the main community. They can languish based on old
>> versions (like our current DOSGi issue), not release often enough, etc...
>> I'd just prefer to keep it in trunk so it's
>> built and tested with the entirety of CXF. At least for now. That's my
>> opinion.
>>
>> Dan
>>
>>
>> [1]
>> http://cxf.547215.n5.nabble.com/DISCUSSION-Support-WS-Notification-in-CXF-td4564096.html
>>
>>
>>
>> On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
>>>
>>> All,
>>>
>>> I would like to initiate a discussion on contributing a STS (Security
>>> Token Service) framework implementation to CXF. CXF currently has an
>>> STS framework in the ws-security module, and ships with a simple
>>> implementation in the examples. Talend would like to contribute a more
>>> sophisticated implementation of the STS framework to the community. It
>>> supports the following standards:
>>>
>>> STS support
>>>
>>> - WS-Trust 1.3/1.4
>>> - WS-SecurityPolicy
>>>
>>> Supports the following mechanism to authenticate an RST:
>>> - UsernameToken
>>> - SAML token (1.1/2.0)
>>> - KerberosToken
>>> - X509 Token
>>>
>>> Following security bindings are supported:
>>> - Symmetric
>>> - Asymmetric
>>> - Transport
>>>
>>> Supports Issue/Validate and Cancel binding
>>>
>>> Can issue the following tokens:
>>> - SAML 1.1/2.0
>>> - Holder-Of-Key
>>> - Bearer
>>> - custom tokens
>>>
>>> Issued token can be encrypted
>>>
>>> Validate binding supports issuing a new token.
>>> Custom Validator can be implemented
>>>
>>> Creation of SAML tokens can be customized:
>>> - authenticationstatement
>>> - attributestatements
>>>
>>>
>>> Advanced RST elements:
>>> - KeyType (Public, Symmetric, Bearer)
>>> - Entropy (Symmetric, Public)
>>> - OnBehalfOf
>>> - ActAs
>>> - Claims
>>> - SecondaryParameters
>>>
>>> - Custom ClaimsHandler
>>>
>>> In my opinion, this implementation will greatly enhance CXF's security
>>> story and will help to drive new users to the product. I would like to
>>> ask the CXF community for their opinion on this contribution (+1/-1?).
>>> I would also like to ask for opinions on where it should go in the
>>> source - a new services module, or perhaps a subproject?
>>>
>>> Colm.
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>
--
Colm O hEigeartaigh
http://coheigea.blogspot.com/
Talend - http://www.talend.com
Re: [DISCUSS] - STS framework implementation contribution
Posted by Willem Jiang <wi...@gmail.com>.
+1 for we introduce a services module to house these kind of Service
which is based on CXF and can be use out of box :)
It could be helpful for the user to use this kind of Enterprise service
more easily.
On 9/16/11 1:07 AM, Daniel Kulp wrote:
>
>
> On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
>> ....
>> In my opinion, this implementation will greatly enhance CXF's security
>> story and will help to drive new users to the product. I would like to
>> ask the CXF community for their opinion on this contribution (+1/-1?).
>
>
> As someone who's been trying to push for this in Talend, I'm obviously +1 to the idea. This is very similar to the discussion we had back in July [1] about moving the WS-Notification stuff from
> ServiceMix into CXF. Obviously no work has been done toward that (yet), but I still support the idea of being able to have "out of the box" some of these enterprise level services that can make
> using CXF in more complex environments easier and more approachable.
>
>> I would also like to ask for opinions on where it should go in the
>> source - a new services module, or perhaps a subproject?
>
> I personally prefer creating a new "services/sts" directory in cxf/trunk to house this. One problem with subprojects is they seem to attract their little sub-communities and they end up really
> being separate from the main community. They can languish based on old versions (like our current DOSGi issue), not release often enough, etc... I'd just prefer to keep it in trunk so it's
> built and tested with the entirety of CXF. At least for now. That's my opinion.
>
> Dan
>
>
> [1] http://cxf.547215.n5.nabble.com/DISCUSSION-Support-WS-Notification-in-CXF-td4564096.html
>
>
>
> On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
>> All,
>>
>> I would like to initiate a discussion on contributing a STS (Security
>> Token Service) framework implementation to CXF. CXF currently has an
>> STS framework in the ws-security module, and ships with a simple
>> implementation in the examples. Talend would like to contribute a more
>> sophisticated implementation of the STS framework to the community. It
>> supports the following standards:
>>
>> STS support
>>
>> - WS-Trust 1.3/1.4
>> - WS-SecurityPolicy
>>
>> Supports the following mechanism to authenticate an RST:
>> - UsernameToken
>> - SAML token (1.1/2.0)
>> - KerberosToken
>> - X509 Token
>>
>> Following security bindings are supported:
>> - Symmetric
>> - Asymmetric
>> - Transport
>>
>> Supports Issue/Validate and Cancel binding
>>
>> Can issue the following tokens:
>> - SAML 1.1/2.0
>> - Holder-Of-Key
>> - Bearer
>> - custom tokens
>>
>> Issued token can be encrypted
>>
>> Validate binding supports issuing a new token.
>> Custom Validator can be implemented
>>
>> Creation of SAML tokens can be customized:
>> - authenticationstatement
>> - attributestatements
>>
>>
>> Advanced RST elements:
>> - KeyType (Public, Symmetric, Bearer)
>> - Entropy (Symmetric, Public)
>> - OnBehalfOf
>> - ActAs
>> - Claims
>> - SecondaryParameters
>>
>> - Custom ClaimsHandler
>>
>> In my opinion, this implementation will greatly enhance CXF's security
>> story and will help to drive new users to the product. I would like to
>> ask the CXF community for their opinion on this contribution (+1/-1?).
>> I would also like to ask for opinions on where it should go in the
>> source - a new services module, or perhaps a subproject?
>>
>> Colm.
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: [DISCUSS] - STS framework implementation contribution
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
> On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
>> ....
>> In my opinion, this implementation will greatly enhance CXF's security
>> story and will help to drive new users to the product. I would like to
>> ask the CXF community for their opinion on this contribution (+1/-1?).
>
>
> As someone who's been trying to push for this in Talend, I'm obviously +1 to the idea. This is very similar to the discussion we had back in July [1] about moving the WS-Notification stuff from
> ServiceMix into CXF. Obviously no work has been done toward that (yet), but I still support the idea of being able to have "out of the box" some of these enterprise level services that can make
> using CXF in more complex environments easier and more approachable.
>
Absolutely - even JAX-RS security extensions will somehow depend on STS
so good to have it in
>> I would also like to ask for opinions on where it should go in the
>> source - a new services module, or perhaps a subproject?
>
> I personally prefer creating a new "services/sts" directory in cxf/trunk to house this. One problem with subprojects is they seem to attract their little sub-communities and they end up really
> being separate from the main community. They can languish based on old versions (like our current DOSGi issue), not release often enough, etc... I'd just prefer to keep it in trunk so it's
> built and tested with the entirety of CXF. At least for now. That's my opinion.
+1.
Sergey
>
> Dan
>
>
> [1] http://cxf.547215.n5.nabble.com/DISCUSSION-Support-WS-Notification-in-CXF-td4564096.html
>
>
>
> On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
>> All,
>>
>> I would like to initiate a discussion on contributing a STS (Security
>> Token Service) framework implementation to CXF. CXF currently has an
>> STS framework in the ws-security module, and ships with a simple
>> implementation in the examples. Talend would like to contribute a more
>> sophisticated implementation of the STS framework to the community. It
>> supports the following standards:
>>
>> STS support
>>
>> - WS-Trust 1.3/1.4
>> - WS-SecurityPolicy
>>
>> Supports the following mechanism to authenticate an RST:
>> - UsernameToken
>> - SAML token (1.1/2.0)
>> - KerberosToken
>> - X509 Token
>>
>> Following security bindings are supported:
>> - Symmetric
>> - Asymmetric
>> - Transport
>>
>> Supports Issue/Validate and Cancel binding
>>
>> Can issue the following tokens:
>> - SAML 1.1/2.0
>> - Holder-Of-Key
>> - Bearer
>> - custom tokens
>>
>> Issued token can be encrypted
>>
>> Validate binding supports issuing a new token.
>> Custom Validator can be implemented
>>
>> Creation of SAML tokens can be customized:
>> - authenticationstatement
>> - attributestatements
>>
>>
>> Advanced RST elements:
>> - KeyType (Public, Symmetric, Bearer)
>> - Entropy (Symmetric, Public)
>> - OnBehalfOf
>> - ActAs
>> - Claims
>> - SecondaryParameters
>>
>> - Custom ClaimsHandler
>>
>> In my opinion, this implementation will greatly enhance CXF's security
>> story and will help to drive new users to the product. I would like to
>> ask the CXF community for their opinion on this contribution (+1/-1?).
>> I would also like to ask for opinions on where it should go in the
>> source - a new services module, or perhaps a subproject?
>>
>> Colm.
Re: [DISCUSS] - STS framework implementation contribution
Posted by Johan Edstrom <se...@gmail.com>.
I'd love to have this in trunk.
+1 on in trunk,
+1 on this being available - it is one of the core questions asked in enterprise setups.
+1 also for making this very very very modular.
/je
On Sep 15, 2011, at 7:22 PM, Freeman Fang wrote:
>
> On 2011-9-16, at 上午1:07, Daniel Kulp wrote:
>
>>
>>
>> On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
>>> ....
>>> In my opinion, this implementation will greatly enhance CXF's security
>>> story and will help to drive new users to the product. I would like to
>>> ask the CXF community for their opinion on this contribution (+1/-1?).
>>
>>
>> As someone who's been trying to push for this in Talend, I'm obviously +1 to the idea. This is very similar to the discussion we had back in July [1] about moving the WS-Notification stuff from
>> ServiceMix into CXF. Obviously no work has been done toward that (yet), but I still support the idea of being able to have "out of the box" some of these enterprise level services that can make
>> using CXF in more complex environments easier and more approachable.
>>
>>> I would also like to ask for opinions on where it should go in the
>>> source - a new services module, or perhaps a subproject?
>>
>> I personally prefer creating a new "services/sts" directory in cxf/trunk to house this. One problem with subprojects is they seem to attract their little sub-communities and they end up really
>> being separate from the main community. They can languish based on old versions (like our current DOSGi issue), not release often enough, etc... I'd just prefer to keep it in trunk so it's
>> built and tested with the entirety of CXF. At least for now. That's my opinion.
>>
>
> +1 to be a new module in trunk
>
> Freeman
>> Dan
>>
>>
>> [1] http://cxf.547215.n5.nabble.com/DISCUSSION-Support-WS-Notification-in-CXF-td4564096.html
>>
>>
>>
>> On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
>>> All,
>>>
>>> I would like to initiate a discussion on contributing a STS (Security
>>> Token Service) framework implementation to CXF. CXF currently has an
>>> STS framework in the ws-security module, and ships with a simple
>>> implementation in the examples. Talend would like to contribute a more
>>> sophisticated implementation of the STS framework to the community. It
>>> supports the following standards:
>>>
>>> STS support
>>>
>>> - WS-Trust 1.3/1.4
>>> - WS-SecurityPolicy
>>>
>>> Supports the following mechanism to authenticate an RST:
>>> - UsernameToken
>>> - SAML token (1.1/2.0)
>>> - KerberosToken
>>> - X509 Token
>>>
>>> Following security bindings are supported:
>>> - Symmetric
>>> - Asymmetric
>>> - Transport
>>>
>>> Supports Issue/Validate and Cancel binding
>>>
>>> Can issue the following tokens:
>>> - SAML 1.1/2.0
>>> - Holder-Of-Key
>>> - Bearer
>>> - custom tokens
>>>
>>> Issued token can be encrypted
>>>
>>> Validate binding supports issuing a new token.
>>> Custom Validator can be implemented
>>>
>>> Creation of SAML tokens can be customized:
>>> - authenticationstatement
>>> - attributestatements
>>>
>>>
>>> Advanced RST elements:
>>> - KeyType (Public, Symmetric, Bearer)
>>> - Entropy (Symmetric, Public)
>>> - OnBehalfOf
>>> - ActAs
>>> - Claims
>>> - SecondaryParameters
>>>
>>> - Custom ClaimsHandler
>>>
>>> In my opinion, this implementation will greatly enhance CXF's security
>>> story and will help to drive new users to the product. I would like to
>>> ask the CXF community for their opinion on this contribution (+1/-1?).
>>> I would also like to ask for opinions on where it should go in the
>>> source - a new services module, or perhaps a subproject?
>>>
>>> Colm.
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>
Re: [DISCUSS] - STS framework implementation contribution
Posted by Freeman Fang <fr...@gmail.com>.
On 2011-9-16, at 上午1:07, Daniel Kulp wrote:
>
>
> On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
>> ....
>> In my opinion, this implementation will greatly enhance CXF's
>> security
>> story and will help to drive new users to the product. I would like
>> to
>> ask the CXF community for their opinion on this contribution
>> (+1/-1?).
>
>
> As someone who's been trying to push for this in Talend, I'm
> obviously +1 to the idea. This is very similar to the discussion
> we had back in July [1] about moving the WS-Notification stuff from
> ServiceMix into CXF. Obviously no work has been done toward that
> (yet), but I still support the idea of being able to have "out of
> the box" some of these enterprise level services that can make
> using CXF in more complex environments easier and more approachable.
>
>> I would also like to ask for opinions on where it should go in the
>> source - a new services module, or perhaps a subproject?
>
> I personally prefer creating a new "services/sts" directory in cxf/
> trunk to house this. One problem with subprojects is they seem to
> attract their little sub-communities and they end up really
> being separate from the main community. They can languish based on
> old versions (like our current DOSGi issue), not release often
> enough, etc... I'd just prefer to keep it in trunk so it's
> built and tested with the entirety of CXF. At least for now.
> That's my opinion.
>
+1 to be a new module in trunk
Freeman
> Dan
>
>
> [1] http://cxf.547215.n5.nabble.com/DISCUSSION-Support-WS-Notification-in-CXF-td4564096.html
>
>
>
> On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
>> All,
>>
>> I would like to initiate a discussion on contributing a STS (Security
>> Token Service) framework implementation to CXF. CXF currently has an
>> STS framework in the ws-security module, and ships with a simple
>> implementation in the examples. Talend would like to contribute a
>> more
>> sophisticated implementation of the STS framework to the community.
>> It
>> supports the following standards:
>>
>> STS support
>>
>> - WS-Trust 1.3/1.4
>> - WS-SecurityPolicy
>>
>> Supports the following mechanism to authenticate an RST:
>> - UsernameToken
>> - SAML token (1.1/2.0)
>> - KerberosToken
>> - X509 Token
>>
>> Following security bindings are supported:
>> - Symmetric
>> - Asymmetric
>> - Transport
>>
>> Supports Issue/Validate and Cancel binding
>>
>> Can issue the following tokens:
>> - SAML 1.1/2.0
>> - Holder-Of-Key
>> - Bearer
>> - custom tokens
>>
>> Issued token can be encrypted
>>
>> Validate binding supports issuing a new token.
>> Custom Validator can be implemented
>>
>> Creation of SAML tokens can be customized:
>> - authenticationstatement
>> - attributestatements
>>
>>
>> Advanced RST elements:
>> - KeyType (Public, Symmetric, Bearer)
>> - Entropy (Symmetric, Public)
>> - OnBehalfOf
>> - ActAs
>> - Claims
>> - SecondaryParameters
>>
>> - Custom ClaimsHandler
>>
>> In my opinion, this implementation will greatly enhance CXF's
>> security
>> story and will help to drive new users to the product. I would like
>> to
>> ask the CXF community for their opinion on this contribution
>> (+1/-1?).
>> I would also like to ask for opinions on where it should go in the
>> source - a new services module, or perhaps a subproject?
>>
>> Colm.
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: [DISCUSS] - STS framework implementation contribution
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
>....
> In my opinion, this implementation will greatly enhance CXF's security
> story and will help to drive new users to the product. I would like to
> ask the CXF community for their opinion on this contribution (+1/-1?).
As someone who's been trying to push for this in Talend, I'm obviously +1 to the idea. This is very similar to the discussion we had back in July [1] about moving the WS-Notification stuff from
ServiceMix into CXF. Obviously no work has been done toward that (yet), but I still support the idea of being able to have "out of the box" some of these enterprise level services that can make
using CXF in more complex environments easier and more approachable.
> I would also like to ask for opinions on where it should go in the
> source - a new services module, or perhaps a subproject?
I personally prefer creating a new "services/sts" directory in cxf/trunk to house this. One problem with subprojects is they seem to attract their little sub-communities and they end up really
being separate from the main community. They can languish based on old versions (like our current DOSGi issue), not release often enough, etc... I'd just prefer to keep it in trunk so it's
built and tested with the entirety of CXF. At least for now. That's my opinion.
Dan
[1] http://cxf.547215.n5.nabble.com/DISCUSSION-Support-WS-Notification-in-CXF-td4564096.html
On Thursday, September 15, 2011 3:27:06 PM Colm O hEigeartaigh wrote:
> All,
>
> I would like to initiate a discussion on contributing a STS (Security
> Token Service) framework implementation to CXF. CXF currently has an
> STS framework in the ws-security module, and ships with a simple
> implementation in the examples. Talend would like to contribute a more
> sophisticated implementation of the STS framework to the community. It
> supports the following standards:
>
> STS support
>
> - WS-Trust 1.3/1.4
> - WS-SecurityPolicy
>
> Supports the following mechanism to authenticate an RST:
> - UsernameToken
> - SAML token (1.1/2.0)
> - KerberosToken
> - X509 Token
>
> Following security bindings are supported:
> - Symmetric
> - Asymmetric
> - Transport
>
> Supports Issue/Validate and Cancel binding
>
> Can issue the following tokens:
> - SAML 1.1/2.0
> - Holder-Of-Key
> - Bearer
> - custom tokens
>
> Issued token can be encrypted
>
> Validate binding supports issuing a new token.
> Custom Validator can be implemented
>
> Creation of SAML tokens can be customized:
> - authenticationstatement
> - attributestatements
>
>
> Advanced RST elements:
> - KeyType (Public, Symmetric, Bearer)
> - Entropy (Symmetric, Public)
> - OnBehalfOf
> - ActAs
> - Claims
> - SecondaryParameters
>
> - Custom ClaimsHandler
>
> In my opinion, this implementation will greatly enhance CXF's security
> story and will help to drive new users to the product. I would like to
> ask the CXF community for their opinion on this contribution (+1/-1?).
> I would also like to ask for opinions on where it should go in the
> source - a new services module, or perhaps a subproject?
>
> Colm.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com