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:51:13 GMT
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 <sberyozkin@gmail.com>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
>>> <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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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