cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: STSTokenValidator enhancements
Date Thu, 06 Feb 2014 11:34:13 GMT
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 <sberyozkin@gmail.com>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 <sberyozkin@gmail.com
>> >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 <sberyozkin@gmail.com
>>>>
>>>>> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message