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.

Reply via email to