On 06/02/14 09:42, Colm O hEigeartaigh wrote:
As far as I know, all of this functionality is already available. Take a
look at the TransformationTest here:
http://svn.apache.org/viewvc/cxf/trunk/services/sts/systests/advanced/src/test/java/org/apache/cxf/systest/sts/transformation/TransformationTest.java?view=markup
This uses the STSTokenValidator to transform a UsernameToken into a SAML
Assertion. Note the configuration of the service, you can just manually
configure an STSClient Object to send whatever Claims etc. you want:
http://svn.apache.org/viewvc/cxf/trunk/services/sts/systests/advanced/src/test/resources/org/apache/cxf/systest/sts/transformation/cxf-service.xml?view=markup
As far as I understand this is not what Oli is asking about. The context
is we have an RS endpoint, and the client using Basic Auth. Next we have
an RS interceptor which transform this Basic Auth and uses
STSTokenValidator to validate it with STS and get a SAML assertion back
representing the authenticated user.
This is documented here:
https://cwiki.apache.org/confluence/display/CXF20DOC/Secure+JAX-RS+Services#SecureJAX-RSServices-ValidatingBasicAuthcredentialswithSTS
and the configuration of STSClient and STSTokenValidtor was probably
copied from the configuration example you linked to above.
My understanding is, the SAML assertion returned from STSTokenValidator
has the limited information, example, it has no claims attached to it, etc.
Oli, is it right ?
So I think, fundamentally, this kind of the extra metadata such as the
extra claims, etc, can only come from STS, not from the
STSTokenValidator itself which is a mere link between WS/RS endpoints
and STS.
Oli, may be indeed we should optionally get STS issue the assertion
given Basic Auth ? If not then I'd say the validation response should
have the extra bits
Thanks, Sergey
Colm.
On Wed, Feb 5, 2014 at 9:13 PM, Sergey Beryozkin <[email protected]>wrote:
Hi Oli
On 05/02/14 19:42, Oliver Wulff wrote:
Hi there
The STSTokenValidator is used to validate incoming credentials (ex.
username/password) against the STS. The STSTokenValidator can be used for
authentication for web services as well a REST services.
REST security is already very enhanced to support claims based access
control which requires that the service provider knows the user claims like
from a SAML token. This could also be achieved for incoming
username/passwords by issuing a SAML token with a configurable list of
claims.
The STSTokenValidator uses the STS validate binding which doesn't support
to validate a token and provide additional claims in the returned SAML
token.
There are two options:
1) Make the binding configurable in the STSTokenValidator
(validate/issue) and configure the list of claims, appliesto element,
lifetime etc. for the issue use case
2) Enhance the validate binding use case on the STS and in the
STSTokenValidator to configure the list of claims, appliesto element,
lifetime etc.
WDYT?
It appears to me that STS is where the extra metadata like claims can be
attached so I guess I'm more for the 2nd case, I looked at the code and
apparently STSTokenValidator supports the case of STS transforming a token.
Look forward to Colm commenting on it
Thanks, Sergey
Thanks
Oli
------
Oliver Wulff
Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
Solution Architect
http://coders.talend.com
<http://coders.talend.com>Talend Application Integration Division
http://www.talend.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
