It could be useful in the scenario where a user only supplies authentication information (i.e. a UsernamePassword), but not any information that could be used for authorization. In this case, the endpoint sends a Claim to the STS for validation, to tell the STS to insert a (e.g.) role in the generated SAML Assertion. The endpoint can subsequently use this for authorization.
Colm. On Thu, Feb 6, 2014 at 11:18 AM, Sergey Beryozkin <[email protected]>wrote: > On 06/02/14 10:35, Colm O hEigeartaigh wrote: > >> No, you should in theory be able to add Claims information via a >> CallbackHandler (or DOM Element) to the STSClient, and they should be >> included in the generated SAML Assertion....but looking at the code it >> doesn't appear that the Validate binding actually sends the Claims >> Element. >> I will fix this... >> >> Sure, thanks, that can help I guess in the short term. > That said, IMHO this is not very practical, as I said, this kind of info > does not really belong to the endpoint which wants to work with STS, why > would it if it will itself add the claims, does not make sense to me but > may be I'm missing something > > Cheers, Sergey > > Colm. >> >> >> On Thu, Feb 6, 2014 at 10:19 AM, Sergey Beryozkin <[email protected] >> >wrote: >> >> 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- >>> ValidatingBasicAuthcredentials >>> withSTS >>> >>> 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 >>> >>> >> >> >> > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.com > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
