Yep exactly. By "Claims" here I mean the ClaimType (e.g. role), and the STS fills in the actual value in the assertion.
Colm. On Thu, Feb 6, 2014 at 11:49 AM, Sergey Beryozkin <[email protected]>wrote: > On 06/02/14 11:45, Sergey Beryozkin wrote: > >> Hi Colm >> On 06/02/14 11:34, Colm O hEigeartaigh wrote: >> >>> 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. >>> >> >> Yes, I'm with you so far >> >> 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. >>> >>> Right. As I said in my previous email, I think this can get us started, >> as far as getting the claims added to the assertion, so we can test, >> example, the claims-based authorization, etc. >> >> What I'm saying though is that IMHO, from the practical point of view (I >> guess I mean the production/deployment), I don't see it is really >> working, where the endpoint itself creates the claims (to be properly >> formatted into the SAML assertion by STS) that it will itself authorize >> against later on. >> > > However you meant that we can tell STSClient to *request* STS add whatever > claims that it may be aware of for a given authenticated principal, then it > definitely does work, if that is the case then I'm sorry I've missed the > point earlier > > Thanks, Sergey > > > >> Cheers, Sergey >> >> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
