cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: STSTokenValidator enhancements
Date Thu, 06 Feb 2014 11:49:34 GMT
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
>> <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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>

Mime
View raw message