You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Oliver Wulff <ow...@talend.com> on 2014/02/05 20:42:51 UTC
STSTokenValidator enhancements
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?
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
Re: STSTokenValidator enhancements
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Oli,
Ok I will consider this as part of a planned refactor of the Claims code.
Colm.
On Thu, Feb 6, 2014 at 10:16 AM, Oliver Wulff <ow...@talend.com> wrote:
> Hi Colm
>
> There is only a claim setter/getter of type Element and a CallbackHandler.
> As the former is not that nice for spring configuration, the callback
> handler could be used to set the element.
>
> Or do you think in adding a setter to configure the claim list in a easier
> way. The only question is which claim class definition to use. There is a
> claim annotation in jaxrs. Maybe we could move this to a JAX-RS/JAX-WS
> neutral package and use that in the sts and in the cxf framework.
>
> Thanks
> Oli
>
>
> ------
>
> Oliver Wulff
>
> Blog: http://owulff.blogspot.com
> Solution Architect
> http://coders.talend.com
>
> Talend Application Integration Division http://www.talend.com
>
> ________________________________________
> From: Colm O hEigeartaigh [coheigea@apache.org]
> Sent: 06 February 2014 10:42
> To: dev@cxf.apache.org
> Subject: Re: STSTokenValidator enhancements
>
> 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
>
> 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
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: STSTokenValidator enhancements
Posted by Oliver Wulff <ow...@talend.com>.
Hi Colm
There is only a claim setter/getter of type Element and a CallbackHandler. As the former is not that nice for spring configuration, the callback handler could be used to set the element.
Or do you think in adding a setter to configure the claim list in a easier way. The only question is which claim class definition to use. There is a claim annotation in jaxrs. Maybe we could move this to a JAX-RS/JAX-WS neutral package and use that in the sts and in the cxf framework.
Thanks
Oli
------
Oliver Wulff
Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com
Talend Application Integration Division http://www.talend.com
________________________________________
From: Colm O hEigeartaigh [coheigea@apache.org]
Sent: 06 February 2014 10:42
To: dev@cxf.apache.org
Subject: Re: STSTokenValidator enhancements
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
Colm.
On Wed, Feb 5, 2014 at 9:13 PM, Sergey Beryozkin <sb...@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
Re: STSTokenValidator enhancements
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <sb...@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
>>> <sb...@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
Re: STSTokenValidator enhancements
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>> <sb...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
Re: STSTokenValidator enhancements
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.
Cheers, Sergey
> Colm.
>
>
> On Thu, Feb 6, 2014 at 11:18 AM, Sergey Beryozkin <sb...@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
>>
>
>
>
Re: STSTokenValidator enhancements
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <sb...@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
Re: STSTokenValidator enhancements
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@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
Re: STSTokenValidator enhancements
Posted by Colm O hEigeartaigh <co...@apache.org>.
FYI this is now fixed. See the following (second) test:
http://svn.apache.org/viewvc/cxf/trunk/services/sts/systests/advanced/src/test/java/org/apache/cxf/systest/sts/transformation/TransformationTest.java?view=markup
Colm.
On Thu, Feb 6, 2014 at 10:35 AM, Colm O hEigeartaigh <co...@apache.org>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...
>
> Colm.
>
>
> On Thu, Feb 6, 2014 at 10:19 AM, Sergey Beryozkin <sb...@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-
>> ValidatingBasicAuthcredentialswithSTS
>>
>> 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
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: STSTokenValidator enhancements
Posted by Colm O hEigeartaigh <co...@apache.org>.
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...
Colm.
On Thu, Feb 6, 2014 at 10:19 AM, Sergey Beryozkin <sb...@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
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: STSTokenValidator enhancements
Posted by Sergey Beryozkin <sb...@gmail.com>.
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-ValidatingBasicAuthcredentialswithSTS
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 <sb...@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
Re: STSTokenValidator enhancements
Posted by Colm O hEigeartaigh <co...@apache.org>.
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
Colm.
On Wed, Feb 5, 2014 at 9:13 PM, Sergey Beryozkin <sb...@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
Re: STSTokenValidator enhancements
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>