Parse the incomming SAML token at server side

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Parse the incomming SAML token at server side

Tóth Csaba
Hello!

I'd like to parse the incomming SAML token to get the fields (user, etc)
and give it to the issuer.
I found, that is done in the
org.apache.cxf.sts.operation.TokenIssueOperation class but
stsProperties.getSamlRealmCodec() is always null in my code (how can i
set it, need to create a new one?)
but after in the fetchSAMLAssertionFromWSSecuritySAMLToken() function
List<WSSecurityEngineResult> engineResults = handlerResult.getResults();
line give back an empty list.

In the request there is an SAML token.

I try to find some solution, but every example is working with the
usernametoken, and/or dont provide a valid cxf config xml.

Thanx
Csaba

Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

coheigea
Administrator
What does the request look like, e.g. where is the SAML token in the
request? Is it referred to directly in the SOAP Body?

Colm.

On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba <[hidden email]> wrote:

> Hello!
>
> I'd like to parse the incomming SAML token to get the fields (user, etc)
> and give it to the issuer.
> I found, that is done in the
> org.apache.cxf.sts.operation.TokenIssueOperation class but
> stsProperties.getSamlRealmCodec() is always null in my code (how can i
> set it, need to create a new one?)
> but after in the fetchSAMLAssertionFromWSSecuritySAMLToken() function
> List<WSSecurityEngineResult> engineResults = handlerResult.getResults();
> line give back an empty list.
>
> In the request there is an SAML token.
>
> I try to find some solution, but every example is working with the
> usernametoken, and/or dont provide a valid cxf config xml.
>
> Thanx
> Csaba
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

Tóth Csaba
Hello!
Its in the header:
------------
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
xmlns:a="http://www.w3.org/2005/08/addressing">
   <soapenv:Header>        
  <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext">
    <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0"
IssueInstant="2014-07-17T01:01:48Z">

  [assertion]

  </saml:Assertion>

  </wsse:Security>
  </soapenv:Header>
 <soapenv:Body>
      <ns:RequestSecurityToken >
  
<ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</ns:RequestType>
 
<ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
  <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy">  [url] 
</ns7:AppliesTo>
  <!--
   <ns:Claims Dialect="http://bag.admin.ch/epr/2017/annex/5/addendum/2">
 
[claims need to process too ]

 </ns:Claims>
-->
 </ns:RequestSecurityToken>
 </soapenv:Body>
</soapenv:Envelope>
---------------------

Its look like easy task for the first look:
get a SAML in the header, full of attributes, and a request with other
attributes.
Validate some attributes, and all header attributes + claims attributes
put the new SAML token.

but, about a week long, I google, read source code, google again, and
try to config the thing.
no good tutorial, no good documentation, no good description :(

Csaba



On 2018.01.23. 18:08, Colm O hEigeartaigh wrote:

> What does the request look like, e.g. where is the SAML token in the
> request? Is it referred to directly in the SOAP Body?
>
> Colm.
>
> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba <[hidden email]> wrote:
>
>> Hello!
>>
>> I'd like to parse the incomming SAML token to get the fields (user, etc)
>> and give it to the issuer.
>> I found, that is done in the
>> org.apache.cxf.sts.operation.TokenIssueOperation class but
>> stsProperties.getSamlRealmCodec() is always null in my code (how can i
>> set it, need to create a new one?)
>> but after in the fetchSAMLAssertionFromWSSecuritySAMLToken() function
>> List<WSSecurityEngineResult> engineResults = handlerResult.getResults();
>> line give back an empty list.
>>
>> In the request there is an SAML token.
>>
>> I try to find some solution, but every example is working with the
>> usernametoken, and/or dont provide a valid cxf config xml.
>>
>> Thanx
>> Csaba
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

coheigea
Administrator
The problem I think is that "http://schemas.xmlsoap.org/ws/2003/06/secext"
is not a standard WS-Security namespace, and hence CXF is not processing
the message header at all. The correct WS-Security namespace for the
security header is instead "
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
".

You could take a look at the CXF transformation feature to transform the
namespace into the correct version (no idea if this will work or not):

http://cxf.apache.org/docs/transformationfeature.html

Colm.


On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[hidden email]> wrote:

> Hello!
> Its in the header:
> ------------
> <soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
> xmlns:a="http://www.w3.org/2005/08/addressing">
>    <soapenv:Header>
>   <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext"
> >
>     <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0"
> IssueInstant="2014-07-17T01:01:48Z">
>
>   [assertion]
>
>   </saml:Assertion>
>
>   </wsse:Security>
>   </soapenv:Header>
>  <soapenv:Body>
>       <ns:RequestSecurityToken >
>
> <ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
> </ns:RequestType>
>
> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-
> saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
>   <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy">  [url]
> </ns7:AppliesTo>
>   <!--
>    <ns:Claims Dialect="http://bag.admin.ch/epr/2017/annex/5/addendum/2">
>
> [claims need to process too ]
>
>  </ns:Claims>
> -->
>  </ns:RequestSecurityToken>
>  </soapenv:Body>
> </soapenv:Envelope>
> ---------------------
>
> Its look like easy task for the first look:
> get a SAML in the header, full of attributes, and a request with other
> attributes.
> Validate some attributes, and all header attributes + claims attributes
> put the new SAML token.
>
> but, about a week long, I google, read source code, google again, and
> try to config the thing.
> no good tutorial, no good documentation, no good description :(
>
> Csaba
>
>
>
> On 2018.01.23. 18:08, Colm O hEigeartaigh wrote:
> > What does the request look like, e.g. where is the SAML token in the
> > request? Is it referred to directly in the SOAP Body?
> >
> > Colm.
> >
> > On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba <[hidden email]> wrote:
> >
> >> Hello!
> >>
> >> I'd like to parse the incomming SAML token to get the fields (user, etc)
> >> and give it to the issuer.
> >> I found, that is done in the
> >> org.apache.cxf.sts.operation.TokenIssueOperation class but
> >> stsProperties.getSamlRealmCodec() is always null in my code (how can i
> >> set it, need to create a new one?)
> >> but after in the fetchSAMLAssertionFromWSSecuritySAMLToken() function
> >> List<WSSecurityEngineResult> engineResults = handlerResult.getResults();
> >> line give back an empty list.
> >>
> >> In the request there is an SAML token.
> >>
> >> I try to find some solution, but every example is working with the
> >> usernametoken, and/or dont provide a valid cxf config xml.
> >>
> >> Thanx
> >> Csaba
> >>
> >>
> >
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

Tóth Csaba
Hello!
Thanx. I changed the namespace, but not helped.

The DefaultSubjectProvider cant retrieve the subject from this SAML:

<saml2:Assertion ID="..." IssueInstant="..." Version="2.0"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">

    <saml2:Subject>
        <saml2:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">[name]</saml2:NameID>
        <saml2:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <saml2:SubjectConfirmationData
InResponseTo="_9c7644ce0fb93649cd2ca77bb9b5e6db22f68b52a9"
NotOnOrAfter="2018-01-24T18:06:33.305Z"/>
        </saml2:SubjectConfirmation>
    </saml2:Subject>

</saml2:Assertion>

But I get an error, because the subject is null
(At this point I cant change the SAML in the request)

Thanx

Csaba

On 2018.01.24. 10:55, Colm O hEigeartaigh wrote:

> The problem I think is that "http://schemas.xmlsoap.org/ws/2003/06/secext"
> is not a standard WS-Security namespace, and hence CXF is not processing
> the message header at all. The correct WS-Security namespace for the
> security header is instead "
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> ".
>
> You could take a look at the CXF transformation feature to transform the
> namespace into the correct version (no idea if this will work or not):
>
> http://cxf.apache.org/docs/transformationfeature.html
>
> Colm.
>
>
> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[hidden email]> wrote:
>
>> Hello!
>> Its in the header:
>> ------------
>> <soapenv:Envelope
>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
>> xmlns:a="http://www.w3.org/2005/08/addressing">
>>    <soapenv:Header>
>>   <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext"
>>     <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0"
>> IssueInstant="2014-07-17T01:01:48Z">
>>
>>   [assertion]
>>
>>   </saml:Assertion>
>>
>>   </wsse:Security>
>>   </soapenv:Header>
>>  <soapenv:Body>
>>       <ns:RequestSecurityToken >
>>
>> <ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
>> </ns:RequestType>
>>
>> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-
>> saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
>>   <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy">  [url]
>> </ns7:AppliesTo>
>>   <!--
>>    <ns:Claims Dialect="http://bag.admin.ch/epr/2017/annex/5/addendum/2">
>>
>> [claims need to process too ]
>>
>>  </ns:Claims>
>> -->
>>  </ns:RequestSecurityToken>
>>  </soapenv:Body>
>> </soapenv:Envelope>
>> ---------------------
>>
>> Its look like easy task for the first look:
>> get a SAML in the header, full of attributes, and a request with other
>> attributes.
>> Validate some attributes, and all header attributes + claims attributes
>> put the new SAML token.
>>
>> but, about a week long, I google, read source code, google again, and
>> try to config the thing.
>> no good tutorial, no good documentation, no good description :(
>>
>> Csaba
>>
>>
>>
>> On 2018.01.23. 18:08, Colm O hEigeartaigh wrote:
>>> What does the request look like, e.g. where is the SAML token in the
>>> request? Is it referred to directly in the SOAP Body?
>>>
>>> Colm.
>>>
>>> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba <[hidden email]> wrote:
>>>
>>>> Hello!
>>>>
>>>> I'd like to parse the incomming SAML token to get the fields (user, etc)
>>>> and give it to the issuer.
>>>> I found, that is done in the
>>>> org.apache.cxf.sts.operation.TokenIssueOperation class but
>>>> stsProperties.getSamlRealmCodec() is always null in my code (how can i
>>>> set it, need to create a new one?)
>>>> but after in the fetchSAMLAssertionFromWSSecuritySAMLToken() function
>>>> List<WSSecurityEngineResult> engineResults = handlerResult.getResults();
>>>> line give back an empty list.
>>>>
>>>> In the request there is an SAML token.
>>>>
>>>> I try to find some solution, but every example is working with the
>>>> usernametoken, and/or dont provide a valid cxf config xml.
>>>>
>>>> Thanx
>>>> Csaba
>>>>
>>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

Tóth Csaba
Hello!

I dig deeper in the code:
The problem with the SAML was:
In the securty element contains not only the SAML, its contains before
the SAML an
<saml2:Issuer> and an <saml2p:Status> element
(in his case The same is not processed)

If I delete it, its go thru the SAML validator

Csaba

On 2018.01.24. 19:25, Tóth Csaba wrote:

> Hello!
> Thanx. I changed the namespace, but not helped.
>
> The DefaultSubjectProvider cant retrieve the subject from this SAML:
>
> <saml2:Assertion ID="..." IssueInstant="..." Version="2.0"
> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
>
>     <saml2:Subject>
>         <saml2:NameID
> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">[name]</saml2:NameID>
>         <saml2:SubjectConfirmation
> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
>             <saml2:SubjectConfirmationData
> InResponseTo="_9c7644ce0fb93649cd2ca77bb9b5e6db22f68b52a9"
> NotOnOrAfter="2018-01-24T18:06:33.305Z"/>
>         </saml2:SubjectConfirmation>
>     </saml2:Subject>
>
> </saml2:Assertion>
>
> But I get an error, because the subject is null
> (At this point I cant change the SAML in the request)
>
> Thanx
>
> Csaba
>
> On 2018.01.24. 10:55, Colm O hEigeartaigh wrote:
>> The problem I think is that "http://schemas.xmlsoap.org/ws/2003/06/secext"
>> is not a standard WS-Security namespace, and hence CXF is not processing
>> the message header at all. The correct WS-Security namespace for the
>> security header is instead "
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> ".
>>
>> You could take a look at the CXF transformation feature to transform the
>> namespace into the correct version (no idea if this will work or not):
>>
>> http://cxf.apache.org/docs/transformationfeature.html
>>
>> Colm.
>>
>>
>> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[hidden email]> wrote:
>>
>>> Hello!
>>> Its in the header:
>>> ------------
>>> <soapenv:Envelope
>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>>> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
>>> xmlns:a="http://www.w3.org/2005/08/addressing">
>>>    <soapenv:Header>
>>>   <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext"
>>>     <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0"
>>> IssueInstant="2014-07-17T01:01:48Z">
>>>
>>>   [assertion]
>>>
>>>   </saml:Assertion>
>>>
>>>   </wsse:Security>
>>>   </soapenv:Header>
>>>  <soapenv:Body>
>>>       <ns:RequestSecurityToken >
>>>
>>> <ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
>>> </ns:RequestType>
>>>
>>> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-
>>> saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
>>>   <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy">  [url]
>>> </ns7:AppliesTo>
>>>   <!--
>>>    <ns:Claims Dialect="http://bag.admin.ch/epr/2017/annex/5/addendum/2">
>>>
>>> [claims need to process too ]
>>>
>>>  </ns:Claims>
>>> -->
>>>  </ns:RequestSecurityToken>
>>>  </soapenv:Body>
>>> </soapenv:Envelope>
>>> ---------------------
>>>
>>> Its look like easy task for the first look:
>>> get a SAML in the header, full of attributes, and a request with other
>>> attributes.
>>> Validate some attributes, and all header attributes + claims attributes
>>> put the new SAML token.
>>>
>>> but, about a week long, I google, read source code, google again, and
>>> try to config the thing.
>>> no good tutorial, no good documentation, no good description :(
>>>
>>> Csaba
>>>
>>>
>>>
>>> On 2018.01.23. 18:08, Colm O hEigeartaigh wrote:
>>>> What does the request look like, e.g. where is the SAML token in the
>>>> request? Is it referred to directly in the SOAP Body?
>>>>
>>>> Colm.
>>>>
>>>> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba <[hidden email]> wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> I'd like to parse the incomming SAML token to get the fields (user, etc)
>>>>> and give it to the issuer.
>>>>> I found, that is done in the
>>>>> org.apache.cxf.sts.operation.TokenIssueOperation class but
>>>>> stsProperties.getSamlRealmCodec() is always null in my code (how can i
>>>>> set it, need to create a new one?)
>>>>> but after in the fetchSAMLAssertionFromWSSecuritySAMLToken() function
>>>>> List<WSSecurityEngineResult> engineResults = handlerResult.getResults();
>>>>> line give back an empty list.
>>>>>
>>>>> In the request there is an SAML token.
>>>>>
>>>>> I try to find some solution, but every example is working with the
>>>>> usernametoken, and/or dont provide a valid cxf config xml.
>>>>>
>>>>> Thanx
>>>>> Csaba
>>>>>
>>>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

coheigea
Administrator
Do you mean that there was a "saml2p:Status" element in the security header
before the Assertion? If so then this is not valid, only the SAML Assertion
should be there.

Colm.

On Thu, Jan 25, 2018 at 8:47 AM, Tóth Csaba <[hidden email]> wrote:

> Hello!
>
> I dig deeper in the code:
> The problem with the SAML was:
> In the securty element contains not only the SAML, its contains before
> the SAML an
> <saml2:Issuer> and an <saml2p:Status> element
> (in his case The same is not processed)
>
> If I delete it, its go thru the SAML validator
>
> Csaba
>
> On 2018.01.24. 19:25, Tóth Csaba wrote:
> > Hello!
> > Thanx. I changed the namespace, but not helped.
> >
> > The DefaultSubjectProvider cant retrieve the subject from this SAML:
> >
> > <saml2:Assertion ID="..." IssueInstant="..." Version="2.0"
> > xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
> >
> >     <saml2:Subject>
> >         <saml2:NameID
> > Format="urn:oasis:names:tc:SAML:2.0:nameid-format:
> persistent">[name]</saml2:NameID>
> >         <saml2:SubjectConfirmation
> > Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
> >             <saml2:SubjectConfirmationData
> > InResponseTo="_9c7644ce0fb93649cd2ca77bb9b5e6db22f68b52a9"
> > NotOnOrAfter="2018-01-24T18:06:33.305Z"/>
> >         </saml2:SubjectConfirmation>
> >     </saml2:Subject>
> >
> > </saml2:Assertion>
> >
> > But I get an error, because the subject is null
> > (At this point I cant change the SAML in the request)
> >
> > Thanx
> >
> > Csaba
> >
> > On 2018.01.24. 10:55, Colm O hEigeartaigh wrote:
> >> The problem I think is that "http://schemas.xmlsoap.org/
> ws/2003/06/secext"
> >> is not a standard WS-Security namespace, and hence CXF is not processing
> >> the message header at all. The correct WS-Security namespace for the
> >> security header is instead "
> >> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
> wssecurity-secext-1.0.xsd
> >> ".
> >>
> >> You could take a look at the CXF transformation feature to transform the
> >> namespace into the correct version (no idea if this will work or not):
> >>
> >> http://cxf.apache.org/docs/transformationfeature.html
> >>
> >> Colm.
> >>
> >>
> >> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[hidden email]> wrote:
> >>
> >>> Hello!
> >>> Its in the header:
> >>> ------------
> >>> <soapenv:Envelope
> >>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> >>> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
> >>> xmlns:a="http://www.w3.org/2005/08/addressing">
> >>>    <soapenv:Header>
> >>>   <wsse:Security xmlns:wsse="http://schemas.
> xmlsoap.org/ws/2003/06/secext"
> >>>     <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
> >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0"
> >>> IssueInstant="2014-07-17T01:01:48Z">
> >>>
> >>>   [assertion]
> >>>
> >>>   </saml:Assertion>
> >>>
> >>>   </wsse:Security>
> >>>   </soapenv:Header>
> >>>  <soapenv:Body>
> >>>       <ns:RequestSecurityToken >
> >>>
> >>> <ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
> >>> </ns:RequestType>
> >>>
> >>> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-
> >>> saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
> >>>   <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy">  [url]
> >>> </ns7:AppliesTo>
> >>>   <!--
> >>>    <ns:Claims Dialect="http://bag.admin.ch/epr/2017/annex/5/addendum/2
> ">
> >>>
> >>> [claims need to process too ]
> >>>
> >>>  </ns:Claims>
> >>> -->
> >>>  </ns:RequestSecurityToken>
> >>>  </soapenv:Body>
> >>> </soapenv:Envelope>
> >>> ---------------------
> >>>
> >>> Its look like easy task for the first look:
> >>> get a SAML in the header, full of attributes, and a request with other
> >>> attributes.
> >>> Validate some attributes, and all header attributes + claims attributes
> >>> put the new SAML token.
> >>>
> >>> but, about a week long, I google, read source code, google again, and
> >>> try to config the thing.
> >>> no good tutorial, no good documentation, no good description :(
> >>>
> >>> Csaba
> >>>
> >>>
> >>>
> >>> On 2018.01.23. 18:08, Colm O hEigeartaigh wrote:
> >>>> What does the request look like, e.g. where is the SAML token in the
> >>>> request? Is it referred to directly in the SOAP Body?
> >>>>
> >>>> Colm.
> >>>>
> >>>> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba <[hidden email]> wrote:
> >>>>
> >>>>> Hello!
> >>>>>
> >>>>> I'd like to parse the incomming SAML token to get the fields (user,
> etc)
> >>>>> and give it to the issuer.
> >>>>> I found, that is done in the
> >>>>> org.apache.cxf.sts.operation.TokenIssueOperation class but
> >>>>> stsProperties.getSamlRealmCodec() is always null in my code (how
> can i
> >>>>> set it, need to create a new one?)
> >>>>> but after in the fetchSAMLAssertionFromWSSecuritySAMLToken()
> function
> >>>>> List<WSSecurityEngineResult> engineResults =
> handlerResult.getResults();
> >>>>> line give back an empty list.
> >>>>>
> >>>>> In the request there is an SAML token.
> >>>>>
> >>>>> I try to find some solution, but every example is working with the
> >>>>> usernametoken, and/or dont provide a valid cxf config xml.
> >>>>>
> >>>>> Thanx
> >>>>> Csaba
> >>>>>
> >>>>>
> >
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

Tóth Csaba
Hello!
Yes, after I deleted it, its begin to parse the SAML.
the next error is about the SigVerCrypto is empty at the
SignatureTrustValidator.validate step.
 (get from the RequestData.sigVerCrypto)

I set up the thing:

<bean id="cryptoProperties" class="java.util.Properties">
    <constructor-arg>
        <props>
            <prop
key="org.apache.ws.security.crypto.provider">org.apache.ws.security.components.crypto.Merlin</prop>
            <prop
key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop>
            <prop
key="org.apache.ws.security.crypto.merlin.keystore.password"> .... </prop>
            <prop
key="org.apache.ws.security.crypto.merlin.file">key/key.jks</prop>
        </props>
    </constructor-arg>
</bean>
    <bean id="utSTSProperties"
class="org.apache.cxf.sts.StaticSTSProperties">
        <property name="SignatureCryptoProperties" ref="cryptoProperties"/>
    ....
    </bean>

and put the keyfile under the WEB-INF/classes/key
(in the keyfile the keys for signing the new SAML)

Thanx
Csaba


On 2018.01.25. 13:40, Colm O hEigeartaigh wrote:

> Do you mean that there was a "saml2p:Status" element in the security header
> before the Assertion? If so then this is not valid, only the SAML Assertion
> should be there.
>
> Colm.
>
> On Thu, Jan 25, 2018 at 8:47 AM, Tóth Csaba <[hidden email]> wrote:
>
>> Hello!
>>
>> I dig deeper in the code:
>> The problem with the SAML was:
>> In the securty element contains not only the SAML, its contains before
>> the SAML an
>> <saml2:Issuer> and an <saml2p:Status> element
>> (in his case The same is not processed)
>>
>> If I delete it, its go thru the SAML validator
>>
>> Csaba
>>
>> On 2018.01.24. 19:25, Tóth Csaba wrote:
>>> Hello!
>>> Thanx. I changed the namespace, but not helped.
>>>
>>> The DefaultSubjectProvider cant retrieve the subject from this SAML:
>>>
>>> <saml2:Assertion ID="..." IssueInstant="..." Version="2.0"
>>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
>>>
>>>     <saml2:Subject>
>>>         <saml2:NameID
>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:
>> persistent">[name]</saml2:NameID>
>>>         <saml2:SubjectConfirmation
>>> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
>>>             <saml2:SubjectConfirmationData
>>> InResponseTo="_9c7644ce0fb93649cd2ca77bb9b5e6db22f68b52a9"
>>> NotOnOrAfter="2018-01-24T18:06:33.305Z"/>
>>>         </saml2:SubjectConfirmation>
>>>     </saml2:Subject>
>>>
>>> </saml2:Assertion>
>>>
>>> But I get an error, because the subject is null
>>> (At this point I cant change the SAML in the request)
>>>
>>> Thanx
>>>
>>> Csaba
>>>
>>> On 2018.01.24. 10:55, Colm O hEigeartaigh wrote:
>>>> The problem I think is that "http://schemas.xmlsoap.org/
>> ws/2003/06/secext"
>>>> is not a standard WS-Security namespace, and hence CXF is not processing
>>>> the message header at all. The correct WS-Security namespace for the
>>>> security header is instead "
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
>> wssecurity-secext-1.0.xsd
>>>> ".
>>>>
>>>> You could take a look at the CXF transformation feature to transform the
>>>> namespace into the correct version (no idea if this will work or not):
>>>>
>>>> http://cxf.apache.org/docs/transformationfeature.html
>>>>
>>>> Colm.
>>>>
>>>>
>>>> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[hidden email]> wrote:
>>>>
>>>>> Hello!
>>>>> Its in the header:
>>>>> ------------
>>>>> <soapenv:Envelope
>>>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>>>>> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
>>>>> xmlns:a="http://www.w3.org/2005/08/addressing">
>>>>>    <soapenv:Header>
>>>>>   <wsse:Security xmlns:wsse="http://schemas.
>> xmlsoap.org/ws/2003/06/secext"
>>>>>     <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>>>> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0"
>>>>> IssueInstant="2014-07-17T01:01:48Z">
>>>>>
>>>>>   [assertion]
>>>>>
>>>>>   </saml:Assertion>
>>>>>
>>>>>   </wsse:Security>
>>>>>   </soapenv:Header>
>>>>>  <soapenv:Body>
>>>>>       <ns:RequestSecurityToken >
>>>>>
>>>>> <ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
>>>>> </ns:RequestType>
>>>>>
>>>>> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-
>>>>> saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
>>>>>   <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy">  [url]
>>>>> </ns7:AppliesTo>
>>>>>   <!--
>>>>>    <ns:Claims Dialect="http://bag.admin.ch/epr/2017/annex/5/addendum/2
>> ">
>>>>> [claims need to process too ]
>>>>>
>>>>>  </ns:Claims>
>>>>> -->
>>>>>  </ns:RequestSecurityToken>
>>>>>  </soapenv:Body>
>>>>> </soapenv:Envelope>
>>>>> ---------------------
>>>>>
>>>>> Its look like easy task for the first look:
>>>>> get a SAML in the header, full of attributes, and a request with other
>>>>> attributes.
>>>>> Validate some attributes, and all header attributes + claims attributes
>>>>> put the new SAML token.
>>>>>
>>>>> but, about a week long, I google, read source code, google again, and
>>>>> try to config the thing.
>>>>> no good tutorial, no good documentation, no good description :(
>>>>>
>>>>> Csaba
>>>>>
>>>>>
>>>>>
>>>>> On 2018.01.23. 18:08, Colm O hEigeartaigh wrote:
>>>>>> What does the request look like, e.g. where is the SAML token in the
>>>>>> request? Is it referred to directly in the SOAP Body?
>>>>>>
>>>>>> Colm.
>>>>>>
>>>>>> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba <[hidden email]> wrote:
>>>>>>
>>>>>>> Hello!
>>>>>>>
>>>>>>> I'd like to parse the incomming SAML token to get the fields (user,
>> etc)
>>>>>>> and give it to the issuer.
>>>>>>> I found, that is done in the
>>>>>>> org.apache.cxf.sts.operation.TokenIssueOperation class but
>>>>>>> stsProperties.getSamlRealmCodec() is always null in my code (how
>> can i
>>>>>>> set it, need to create a new one?)
>>>>>>> but after in the fetchSAMLAssertionFromWSSecuritySAMLToken()
>> function
>>>>>>> List<WSSecurityEngineResult> engineResults =
>> handlerResult.getResults();
>>>>>>> line give back an empty list.
>>>>>>>
>>>>>>> In the request there is an SAML token.
>>>>>>>
>>>>>>> I try to find some solution, but every example is working with the
>>>>>>> usernametoken, and/or dont provide a valid cxf config xml.
>>>>>>>
>>>>>>> Thanx
>>>>>>> Csaba
>>>>>>>
>>>>>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

coheigea
Administrator
What's the full stack-trace?

On Thu, Jan 25, 2018 at 1:44 PM, Tóth Csaba <[hidden email]> wrote:

> Hello!
> Yes, after I deleted it, its begin to parse the SAML.
> the next error is about the SigVerCrypto is empty at the
> SignatureTrustValidator.validate step.
>  (get from the RequestData.sigVerCrypto)
>
> I set up the thing:
>
> <bean id="cryptoProperties" class="java.util.Properties">
>     <constructor-arg>
>         <props>
>             <prop
> key="org.apache.ws.security.crypto.provider">org.apache.
> ws.security.components.crypto.Merlin</prop>
>             <prop
> key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop>
>             <prop
> key="org.apache.ws.security.crypto.merlin.keystore.password"> .... </prop>
>             <prop
> key="org.apache.ws.security.crypto.merlin.file">key/key.jks</prop>
>         </props>
>     </constructor-arg>
> </bean>
>     <bean id="utSTSProperties"
> class="org.apache.cxf.sts.StaticSTSProperties">
>         <property name="SignatureCryptoProperties"
> ref="cryptoProperties"/>
>     ....
>     </bean>
>
> and put the keyfile under the WEB-INF/classes/key
> (in the keyfile the keys for signing the new SAML)
>
> Thanx
> Csaba
>
>
> On 2018.01.25. 13:40, Colm O hEigeartaigh wrote:
> > Do you mean that there was a "saml2p:Status" element in the security
> header
> > before the Assertion? If so then this is not valid, only the SAML
> Assertion
> > should be there.
> >
> > Colm.
> >
> > On Thu, Jan 25, 2018 at 8:47 AM, Tóth Csaba <[hidden email]> wrote:
> >
> >> Hello!
> >>
> >> I dig deeper in the code:
> >> The problem with the SAML was:
> >> In the securty element contains not only the SAML, its contains before
> >> the SAML an
> >> <saml2:Issuer> and an <saml2p:Status> element
> >> (in his case The same is not processed)
> >>
> >> If I delete it, its go thru the SAML validator
> >>
> >> Csaba
> >>
> >> On 2018.01.24. 19:25, Tóth Csaba wrote:
> >>> Hello!
> >>> Thanx. I changed the namespace, but not helped.
> >>>
> >>> The DefaultSubjectProvider cant retrieve the subject from this SAML:
> >>>
> >>> <saml2:Assertion ID="..." IssueInstant="..." Version="2.0"
> >>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
> >>>
> >>>     <saml2:Subject>
> >>>         <saml2:NameID
> >>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:
> >> persistent">[name]</saml2:NameID>
> >>>         <saml2:SubjectConfirmation
> >>> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
> >>>             <saml2:SubjectConfirmationData
> >>> InResponseTo="_9c7644ce0fb93649cd2ca77bb9b5e6db22f68b52a9"
> >>> NotOnOrAfter="2018-01-24T18:06:33.305Z"/>
> >>>         </saml2:SubjectConfirmation>
> >>>     </saml2:Subject>
> >>>
> >>> </saml2:Assertion>
> >>>
> >>> But I get an error, because the subject is null
> >>> (At this point I cant change the SAML in the request)
> >>>
> >>> Thanx
> >>>
> >>> Csaba
> >>>
> >>> On 2018.01.24. 10:55, Colm O hEigeartaigh wrote:
> >>>> The problem I think is that "http://schemas.xmlsoap.org/
> >> ws/2003/06/secext"
> >>>> is not a standard WS-Security namespace, and hence CXF is not
> processing
> >>>> the message header at all. The correct WS-Security namespace for the
> >>>> security header is instead "
> >>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
> >> wssecurity-secext-1.0.xsd
> >>>> ".
> >>>>
> >>>> You could take a look at the CXF transformation feature to transform
> the
> >>>> namespace into the correct version (no idea if this will work or not):
> >>>>
> >>>> http://cxf.apache.org/docs/transformationfeature.html
> >>>>
> >>>> Colm.
> >>>>
> >>>>
> >>>> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[hidden email]> wrote:
> >>>>
> >>>>> Hello!
> >>>>> Its in the header:
> >>>>> ------------
> >>>>> <soapenv:Envelope
> >>>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> >>>>> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
> >>>>> xmlns:a="http://www.w3.org/2005/08/addressing">
> >>>>>    <soapenv:Header>
> >>>>>   <wsse:Security xmlns:wsse="http://schemas.
> >> xmlsoap.org/ws/2003/06/secext"
> >>>>>     <saml:Assertion xmlns:saml="urn:oasis:names:
> tc:SAML:2.0:assertion"
> >>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>>>> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0"
> >>>>> IssueInstant="2014-07-17T01:01:48Z">
> >>>>>
> >>>>>   [assertion]
> >>>>>
> >>>>>   </saml:Assertion>
> >>>>>
> >>>>>   </wsse:Security>
> >>>>>   </soapenv:Header>
> >>>>>  <soapenv:Body>
> >>>>>       <ns:RequestSecurityToken >
> >>>>>
> >>>>> <ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/
> 200512/Issue
> >>>>> </ns:RequestType>
> >>>>>
> >>>>> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-
> >>>>> saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
> >>>>>   <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy">  [url]
> >>>>> </ns7:AppliesTo>
> >>>>>   <!--
> >>>>>    <ns:Claims Dialect="http://bag.admin.ch/
> epr/2017/annex/5/addendum/2
> >> ">
> >>>>> [claims need to process too ]
> >>>>>
> >>>>>  </ns:Claims>
> >>>>> -->
> >>>>>  </ns:RequestSecurityToken>
> >>>>>  </soapenv:Body>
> >>>>> </soapenv:Envelope>
> >>>>> ---------------------
> >>>>>
> >>>>> Its look like easy task for the first look:
> >>>>> get a SAML in the header, full of attributes, and a request with
> other
> >>>>> attributes.
> >>>>> Validate some attributes, and all header attributes + claims
> attributes
> >>>>> put the new SAML token.
> >>>>>
> >>>>> but, about a week long, I google, read source code, google again, and
> >>>>> try to config the thing.
> >>>>> no good tutorial, no good documentation, no good description :(
> >>>>>
> >>>>> Csaba
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2018.01.23. 18:08, Colm O hEigeartaigh wrote:
> >>>>>> What does the request look like, e.g. where is the SAML token in the
> >>>>>> request? Is it referred to directly in the SOAP Body?
> >>>>>>
> >>>>>> Colm.
> >>>>>>
> >>>>>> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba <[hidden email]> wrote:
> >>>>>>
> >>>>>>> Hello!
> >>>>>>>
> >>>>>>> I'd like to parse the incomming SAML token to get the fields (user,
> >> etc)
> >>>>>>> and give it to the issuer.
> >>>>>>> I found, that is done in the
> >>>>>>> org.apache.cxf.sts.operation.TokenIssueOperation class but
> >>>>>>> stsProperties.getSamlRealmCodec() is always null in my code (how
> >> can i
> >>>>>>> set it, need to create a new one?)
> >>>>>>> but after in the fetchSAMLAssertionFromWSSecuritySAMLToken()
> >> function
> >>>>>>> List<WSSecurityEngineResult> engineResults =
> >> handlerResult.getResults();
> >>>>>>> line give back an empty list.
> >>>>>>>
> >>>>>>> In the request there is an SAML token.
> >>>>>>>
> >>>>>>> I try to find some solution, but every example is working with the
> >>>>>>> usernametoken, and/or dont provide a valid cxf config xml.
> >>>>>>>
> >>>>>>> Thanx
> >>>>>>> Csaba
> >>>>>>>
> >>>>>>>
> >>
> >
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

Tóth Csaba
Hello!
(Sorry for the wrong address)

It's go forward with little steps.
now I get this error:
jan. 26, 2018 12:42:21 DU
org.apache.cxf.ws.security.trust.STSSamlAssertionValidator
verifySignedAssertion
WARNING: Local trust verification of SAML assertion failed: Error during
certificate path validation: No trusted certs found
org.apache.wss4j.common.ext.WSSecurityException: Error during
certificate path validation: No trusted certs found
    at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:829)
    at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:919)
    at
org.apache.wss4j.dom.validate.SignatureTrustValidator.verifyTrustInCerts(SignatureTrustValidator.java:109)
    at
org.apache.wss4j.dom.validate.SignatureTrustValidator.validate(SignatureTrustValidator.java:64)
    at
org.apache.wss4j.dom.validate.SamlAssertionValidator.verifySignedAssertion(SamlAssertionValidator.java:214)
    at
org.apache.cxf.ws.security.trust.STSSamlAssertionValidator.verifySignedAssertion(STSSamlAssertionValidator.java:68)

I get the certification from the SAML, and put into the keystore what i
already setup (and put under the WEB-INF/classes/key directory

the strange thing, the next error come about:
jan. 26, 2018 12:42:24 DU org.apache.cxf.phase.PhaseInterceptorChain
doDefaultLogging
WARNING: Interceptor for
{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService
has thrown exception, unwinding now
org.apache.cxf.ws.security.trust.TrustException: The STSClient is not
configured with either a location or wsdlLocation property
    at
org.apache.cxf.ws.security.trust.AbstractSTSClient.createClient(AbstractSTSClient.java:673)
    at
org.apache.cxf.ws.security.trust.AbstractSTSClient.validate(AbstractSTSClient.java:1101)
    at
org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken(STSClient.java:105)

What STSClient? why want to create a client?
in the cxf settings no "client" string is found

Thanx
Csaba

On 2018.01.25. 15:48, Colm O hEigeartaigh wrote:

>
> Please reply to the CXF mailing list and not me directly...the problem
> is that the SAML Assertion is getting validated before it hits the
> STS, so you need to make a reference to the signature properties as a
> JAX-WS property of the endpoint. For example:
>
> https://github.com/apache/cxf/blob/6a3f97e9f0d02eef72bf10c266d444ec3af78bf5/services/sts/systests/basic/src/test/resources/org/apache/cxf/systest/sts/transport/cxf-service.xml#L44
>
> On Thu, Jan 25, 2018 at 2:38 PM, Tóth Csaba <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hello!
>     this is the full trace:
>
>     jan. 25, 2018 2:17:13 DU org.apache.cxf.phase.PhaseInterceptorChain
>     doDefaultLogging
>     WARNING: Interceptor for
>     {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService
>     <http://docs.oasis-open.org/ws-sx/ws-trust/200512/%7DSecurityTokenService>
>     has thrown exception, unwinding now
>     org.apache.cxf.binding.soap.SoapFault: No crypto property file
>     supplied
>     for signature
>         at
>     org.apache.cxf.ws.security.wss4j.WSS4JUtils.createSoapFault(WSS4JUtils.java:236)
>         at
>     org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:340)
>         at
>     org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:175)
>         at
>     org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:79)
>         at
>     org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:66)
>         at
>     org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>         at
>     org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>         at
>     org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
>         at
>     org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
>         at
>     org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
>         at
>     org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
>         at
>     org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:191)
>         at
>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
>         at
>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:661)
>         at
>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)
>         at
>     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
>         at
>     org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>         at
>     org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>         at
>     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>         at
>     org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>         at
>     org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
>         at
>     org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
>         at
>     org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504)
>         at
>     org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
>         at
>     org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
>         at
>     org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
>         at
>     org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
>         at
>     org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
>         at
>     org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:803)
>         at
>     org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
>         at
>     org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:790)
>         at
>     org.apache.tomcat.util.net
>     <http://org.apache.tomcat.util.net>.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459)
>         at
>     org.apache.tomcat.util.net
>     <http://org.apache.tomcat.util.net>.SocketProcessorBase.run(SocketProcessorBase.java:49)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
>     Source)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>     Source)
>         at
>     org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>         at java.lang.Thread.run(Unknown Source)
>
>     Csaba
>
>     On 2018.01.25. 15 <tel:2018.01.25.%2015>:32, Colm O hEigeartaigh
>     wrote:
>     > What's the full stack-trace?
>     >
>     > On Thu, Jan 25, 2018 at 1:44 PM, Tóth Csaba <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >
>     >> Hello!
>     >> Yes, after I deleted it, its begin to parse the SAML.
>     >> the next error is about the SigVerCrypto is empty at the
>     >> SignatureTrustValidator.validate step.
>     >>  (get from the RequestData.sigVerCrypto)
>     >>
>     >> I set up the thing:
>     >>
>     >> <bean id="cryptoProperties" class="java.util.Properties">
>     >>     <constructor-arg>
>     >>         <props>
>     >>             <prop
>     >> key="org.apache.ws.security.crypto.provider">org.apache.
>     >> ws.security.components.crypto.Merlin</prop>
>     >>             <prop
>     >> key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop>
>     >>             <prop
>     >> key="org.apache.ws.security.crypto.merlin.keystore.password">
>     .... </prop>
>     >>             <prop
>     >> key="org.apache.ws.security.crypto.merlin.file">key/key.jks</prop>
>     >>         </props>
>     >>     </constructor-arg>
>     >> </bean>
>     >>     <bean id="utSTSProperties"
>     >> class="org.apache.cxf.sts.StaticSTSProperties">
>     >>         <property name="SignatureCryptoProperties"
>     >> ref="cryptoProperties"/>
>     >>     ....
>     >>     </bean>
>     >>
>     >> and put the keyfile under the WEB-INF/classes/key
>     >> (in the keyfile the keys for signing the new SAML)
>     >>
>     >> Thanx
>     >> Csaba
>     >>
>     >>
>     >> On 2018.01.25. 13 <tel:2018.01.25.%2013>:40, Colm O
>     hEigeartaigh wrote:
>     >>> Do you mean that there was a "saml2p:Status" element in the
>     security
>     >> header
>     >>> before the Assertion? If so then this is not valid, only the SAML
>     >> Assertion
>     >>> should be there.
>     >>>
>     >>> Colm.
>     >>>
>     >>> On Thu, Jan 25, 2018 at 8:47 AM, Tóth Csaba <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >>>
>     >>>> Hello!
>     >>>>
>     >>>> I dig deeper in the code:
>     >>>> The problem with the SAML was:
>     >>>> In the securty element contains not only the SAML, its
>     contains before
>     >>>> the SAML an
>     >>>> <saml2:Issuer> and an <saml2p:Status> element
>     >>>> (in his case The same is not processed)
>     >>>>
>     >>>> If I delete it, its go thru the SAML validator
>     >>>>
>     >>>> Csaba
>     >>>>
>     >>>> On 2018.01.24. 19 <tel:2018.01.24.%2019>:25, Tóth Csaba wrote:
>     >>>>> Hello!
>     >>>>> Thanx. I changed the namespace, but not helped.
>     >>>>>
>     >>>>> The DefaultSubjectProvider cant retrieve the subject from
>     this SAML:
>     >>>>>
>     >>>>> <saml2:Assertion ID="..." IssueInstant="..." Version="2.0"
>     >>>>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
>     >>>>>
>     >>>>>     <saml2:Subject>
>     >>>>>         <saml2:NameID
>     >>>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:
>     >>>> persistent">[name]</saml2:NameID>
>     >>>>>         <saml2:SubjectConfirmation
>     >>>>> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
>     >>>>>             <saml2:SubjectConfirmationData
>     >>>>> InResponseTo="_9c7644ce0fb93649cd2ca77bb9b5e6db22f68b52a9"
>     >>>>> NotOnOrAfter="2018-01-24T18:06:33.305Z"/>
>     >>>>>         </saml2:SubjectConfirmation>
>     >>>>>     </saml2:Subject>
>     >>>>>
>     >>>>> </saml2:Assertion>
>     >>>>>
>     >>>>> But I get an error, because the subject is null
>     >>>>> (At this point I cant change the SAML in the request)
>     >>>>>
>     >>>>> Thanx
>     >>>>>
>     >>>>> Csaba
>     >>>>>
>     >>>>> On 2018.01.24. 10:55, Colm O hEigeartaigh wrote:
>     >>>>>> The problem I think is that "http://schemas.xmlsoap.org/
>     >>>> ws/2003/06/secext"
>     >>>>>> is not a standard WS-Security namespace, and hence CXF is not
>     >> processing
>     >>>>>> the message header at all. The correct WS-Security
>     namespace for the
>     >>>>>> security header is instead "
>     >>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
>     <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss->
>     >>>> wssecurity-secext-1.0.xsd
>     >>>>>> ".
>     >>>>>>
>     >>>>>> You could take a look at the CXF transformation feature to
>     transform
>     >> the
>     >>>>>> namespace into the correct version (no idea if this will
>     work or not):
>     >>>>>>
>     >>>>>> http://cxf.apache.org/docs/transformationfeature.html
>     <http://cxf.apache.org/docs/transformationfeature.html>
>     >>>>>>
>     >>>>>> Colm.
>     >>>>>>
>     >>>>>>
>     >>>>>> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >>>>>>
>     >>>>>>> Hello!
>     >>>>>>> Its in the header:
>     >>>>>>> ------------
>     >>>>>>> <soapenv:Envelope
>     >>>>>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/
>     <http://schemas.xmlsoap.org/soap/envelope/>"
>     >>>>>>> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512
>     <http://docs.oasis-open.org/ws-sx/ws-trust/200512>"
>     >>>>>>> xmlns:a="http://www.w3.org/2005/08/addressing
>     <http://www.w3.org/2005/08/addressing>">
>     >>>>>>>    <soapenv:Header>
>     >>>>>>>   <wsse:Security xmlns:wsse="http://schemas.
>     >>>> xmlsoap.org/ws/2003/06/secext
>     <http://xmlsoap.org/ws/2003/06/secext>"
>     >>>>>>>     <saml:Assertion xmlns:saml="urn:oasis:names:
>     >> tc:SAML:2.0:assertion"
>     >>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
>     <http://www.w3.org/2001/XMLSchema-instance>"
>     >>>>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema
>     <http://www.w3.org/2001/XMLSchema>"
>     >>>>>>> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0"
>     >>>>>>> IssueInstant="2014-07-17T01:01:48Z">
>     >>>>>>>
>     >>>>>>>   [assertion]
>     >>>>>>>
>     >>>>>>>   </saml:Assertion>
>     >>>>>>>
>     >>>>>>>   </wsse:Security>
>     >>>>>>>   </soapenv:Header>
>     >>>>>>>  <soapenv:Body>
>     >>>>>>>       <ns:RequestSecurityToken >
>     >>>>>>>
>     >>>>>>> <ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/
>     <http://docs.oasis-open.org/ws-sx/ws-trust/>
>     >> 200512/Issue
>     >>>>>>> </ns:RequestType>
>     >>>>>>>
>     >>>>>>> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-
>     <http://docs.oasis-open.org/wss/oasis-wss->
>     >>>>>>> saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
>     >>>>>>>   <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy
>     <http://www.w3.org/ns/ws-policy>">  [url]
>     >>>>>>> </ns7:AppliesTo>
>     >>>>>>>   <!--
>     >>>>>>>    <ns:Claims Dialect="http://bag.admin.ch/
>     >> epr/2017/annex/5/addendum/2
>     >>>> ">
>     >>>>>>> [claims need to process too ]
>     >>>>>>>
>     >>>>>>>  </ns:Claims>
>     >>>>>>> -->
>     >>>>>>>  </ns:RequestSecurityToken>
>     >>>>>>>  </soapenv:Body>
>     >>>>>>> </soapenv:Envelope>
>     >>>>>>> ---------------------
>     >>>>>>>
>     >>>>>>> Its look like easy task for the first look:
>     >>>>>>> get a SAML in the header, full of attributes, and a
>     request with
>     >> other
>     >>>>>>> attributes.
>     >>>>>>> Validate some attributes, and all header attributes + claims
>     >> attributes
>     >>>>>>> put the new SAML token.
>     >>>>>>>
>     >>>>>>> but, about a week long, I google, read source code, google
>     again, and
>     >>>>>>> try to config the thing.
>     >>>>>>> no good tutorial, no good documentation, no good
>     description :(
>     >>>>>>>
>     >>>>>>> Csaba
>     >>>>>>>
>     >>>>>>>
>     >>>>>>>
>     >>>>>>> On 2018.01.23. 18 <tel:2018.01.23.%2018>:08, Colm O
>     hEigeartaigh wrote:
>     >>>>>>>> What does the request look like, e.g. where is the SAML
>     token in the
>     >>>>>>>> request? Is it referred to directly in the SOAP Body?
>     >>>>>>>>
>     >>>>>>>> Colm.
>     >>>>>>>>
>     >>>>>>>> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba
>     <[hidden email] <mailto:[hidden email]>> wrote:
>     >>>>>>>>
>     >>>>>>>>> Hello!
>     >>>>>>>>>
>     >>>>>>>>> I'd like to parse the incomming SAML token to get the
>     fields (user,
>     >>>> etc)
>     >>>>>>>>> and give it to the issuer.
>     >>>>>>>>> I found, that is done in the
>     >>>>>>>>> org.apache.cxf.sts.operation.TokenIssueOperation class but
>     >>>>>>>>> stsProperties.getSamlRealmCodec() is always null in my
>     code (how
>     >>>> can i
>     >>>>>>>>> set it, need to create a new one?)
>     >>>>>>>>> but after in the fetchSAMLAssertionFromWSSecuritySAMLToken()
>     >>>> function
>     >>>>>>>>> List<WSSecurityEngineResult> engineResults =
>     >>>> handlerResult.getResults();
>     >>>>>>>>> line give back an empty list.
>     >>>>>>>>>
>     >>>>>>>>> In the request there is an SAML token.
>     >>>>>>>>>
>     >>>>>>>>> I try to find some solution, but every example is
>     working with the
>     >>>>>>>>> usernametoken, and/or dont provide a valid cxf config xml.
>     >>>>>>>>>
>     >>>>>>>>> Thanx
>     >>>>>>>>> Csaba
>     >>>>>>>>>
>     >>>>>>>>>
>     >>
>     >
>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com


Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

coheigea
Administrator
OK so it appears the problems with the STS issuing the token have been
fixed? The errors are from the STSSamlAssertionValidator, which is supposed
to be used on the service side. It tries to validate the Signature locally
on the token, and if it fails it dispatches the token to the STS for
validation, which is why you're seeing an error about STSClient.

What behaviour are you expecting on the service side? Normally the
STSSamlAssertionValidator
is not configured, because you have the CA cert of the STS in the service
keystore and it can validate the certificate locally. Is the STS cert (or
CA cert) in your crypto properties file pointing to by the
security.signature.properties configuration variable on the service side?

Colm.

On Fri, Jan 26, 2018 at 11:56 AM, Tóth Csaba <[hidden email]> wrote:

> Hello!
> (Sorry for the wrong address)
>
> It's go forward with little steps.
> now I get this error:
> jan. 26, 2018 12:42:21 DU
> org.apache.cxf.ws.security.trust.STSSamlAssertionValidator
> verifySignedAssertion
> WARNING: Local trust verification of SAML assertion failed: Error during
> certificate path validation: No trusted certs found
> org.apache.wss4j.common.ext.WSSecurityException: Error during
> certificate path validation: No trusted certs found
>     at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:829)
>     at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:919)
>     at
> org.apache.wss4j.dom.validate.SignatureTrustValidator.verifyTrustInCerts(
> SignatureTrustValidator.java:109)
>     at
> org.apache.wss4j.dom.validate.SignatureTrustValidator.validate(
> SignatureTrustValidator.java:64)
>     at
> org.apache.wss4j.dom.validate.SamlAssertionValidator.
> verifySignedAssertion(SamlAssertionValidator.java:214)
>     at
> org.apache.cxf.ws.security.trust.STSSamlAssertionValidator.
> verifySignedAssertion(STSSamlAssertionValidator.java:68)
>
> I get the certification from the SAML, and put into the keystore what i
> already setup (and put under the WEB-INF/classes/key directory
>
> the strange thing, the next error come about:
> jan. 26, 2018 12:42:24 DU org.apache.cxf.phase.PhaseInterceptorChain
> doDefaultLogging
> WARNING: Interceptor for
> {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService
> has thrown exception, unwinding now
> org.apache.cxf.ws.security.trust.TrustException: The STSClient is not
> configured with either a location or wsdlLocation property
>     at
> org.apache.cxf.ws.security.trust.AbstractSTSClient.createClient(
> AbstractSTSClient.java:673)
>     at
> org.apache.cxf.ws.security.trust.AbstractSTSClient.
> validate(AbstractSTSClient.java:1101)
>     at
> org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken(
> STSClient.java:105)
>
> What STSClient? why want to create a client?
> in the cxf settings no "client" string is found
>
> Thanx
> Csaba
>
> On 2018.01.25. 15:48, Colm O hEigeartaigh wrote:
> >
> > Please reply to the CXF mailing list and not me directly...the problem
> > is that the SAML Assertion is getting validated before it hits the
> > STS, so you need to make a reference to the signature properties as a
> > JAX-WS property of the endpoint. For example:
> >
> > https://github.com/apache/cxf/blob/6a3f97e9f0d02eef72bf10c266d444
> ec3af78bf5/services/sts/systests/basic/src/test/resources/org/apache/cxf/
> systest/sts/transport/cxf-service.xml#L44
> >
> > On Thu, Jan 25, 2018 at 2:38 PM, Tóth Csaba <[hidden email]
> > <mailto:[hidden email]>> wrote:
> >
> >     Hello!
> >     this is the full trace:
> >
> >     jan. 25, 2018 2:17:13 DU org.apache.cxf.phase.PhaseInterceptorChain
> >     doDefaultLogging
> >     WARNING: Interceptor for
> >     {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}
> SecurityTokenService
> >     <<a href="http://docs.oasis-open.org/ws-sx/ws-trust/200512/%">http://docs.oasis-open.org/ws-sx/ws-trust/200512/%
> 7DSecurityTokenService>
> >     has thrown exception, unwinding now
> >     org.apache.cxf.binding.soap.SoapFault: No crypto property file
> >     supplied
> >     for signature
> >         at
> >     org.apache.cxf.ws.security.wss4j.WSS4JUtils.
> createSoapFault(WSS4JUtils.java:236)
> >         at
> >     org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.
> handleMessageInternal(WSS4JInInterceptor.java:340)
> >         at
> >     org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(
> WSS4JInInterceptor.java:175)
> >         at
> >     org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.
> handleMessage(PolicyBasedWSS4JInInterceptor.java:79)
> >         at
> >     org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.
> handleMessage(PolicyBasedWSS4JInInterceptor.java:66)
> >         at
> >     org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> PhaseInterceptorChain.java:308)
> >         at
> >     org.apache.cxf.transport.ChainInitiationObserver.onMessage(
> ChainInitiationObserver.java:121)
> >         at
> >     org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(
> AbstractHTTPDestination.java:267)
> >         at
> >     org.apache.cxf.transport.servlet.ServletController.
> invokeDestination(ServletController.java:234)
> >         at
> >     org.apache.cxf.transport.servlet.ServletController.
> invoke(ServletController.java:208)
> >         at
> >     org.apache.cxf.transport.servlet.ServletController.
> invoke(ServletController.java:160)
> >         at
> >     org.apache.cxf.transport.servlet.CXFNonSpringServlet.
> invoke(CXFNonSpringServlet.java:191)
> >         at
> >     org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(
> AbstractHTTPServlet.java:301)
> >         at
> >     org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> doPost(AbstractHTTPServlet.java:220)
> >         at javax.servlet.http.HttpServlet.service(HttpServlet.java:661)
> >         at
> >     org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> service(AbstractHTTPServlet.java:276)
> >         at
> >     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:231)
> >         at
> >     org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:166)
> >         at
> >     org.apache.tomcat.websocket.server.WsFilter.doFilter(
> WsFilter.java:52)
> >         at
> >     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:193)
> >         at
> >     org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:166)
> >         at
> >     org.apache.catalina.core.StandardWrapperValve.invoke(
> StandardWrapperValve.java:198)
> >         at
> >     org.apache.catalina.core.StandardContextValve.invoke(
> StandardContextValve.java:96)
> >         at
> >     org.apache.catalina.authenticator.AuthenticatorBase.invoke(
> AuthenticatorBase.java:504)
> >         at
> >     org.apache.catalina.core.StandardHostValve.invoke(
> StandardHostValve.java:140)
> >         at
> >     org.apache.catalina.valves.ErrorReportValve.invoke(
> ErrorReportValve.java:81)
> >         at
> >     org.apache.catalina.valves.AbstractAccessLogValve.invoke(
> AbstractAccessLogValve.java:650)
> >         at
> >     org.apache.catalina.core.StandardEngineValve.invoke(
> StandardEngineValve.java:87)
> >         at
> >     org.apache.catalina.connector.CoyoteAdapter.service(
> CoyoteAdapter.java:342)
> >         at
> >     org.apache.coyote.http11.Http11Processor.service(
> Http11Processor.java:803)
> >         at
> >     org.apache.coyote.AbstractProcessorLight.process(
> AbstractProcessorLight.java:66)
> >         at
> >     org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
> AbstractProtocol.java:790)
> >         at
> >     org.apache.tomcat.util.net
> >     <http://org.apache.tomcat.util.net>.NioEndpoint$
> SocketProcessor.doRun(NioEndpoint.java:1459)
> >         at
> >     org.apache.tomcat.util.net
> >     <http://org.apache.tomcat.util.net>.SocketProcessorBase.
> run(SocketProcessorBase.java:49)
> >         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> >     Source)
> >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> >     Source)
> >         at
> >     org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
> TaskThread.java:61)
> >         at java.lang.Thread.run(Unknown Source)
> >
> >     Csaba
> >
> >     On 2018.01.25. 15 <tel:2018.01.25.%2015>:32, Colm O hEigeartaigh
> >     wrote:
> >     > What's the full stack-trace?
> >     >
> >     > On Thu, Jan 25, 2018 at 1:44 PM, Tóth Csaba <[hidden email]
> >     <mailto:[hidden email]>> wrote:
> >     >
> >     >> Hello!
> >     >> Yes, after I deleted it, its begin to parse the SAML.
> >     >> the next error is about the SigVerCrypto is empty at the
> >     >> SignatureTrustValidator.validate step.
> >     >>  (get from the RequestData.sigVerCrypto)
> >     >>
> >     >> I set up the thing:
> >     >>
> >     >> <bean id="cryptoProperties" class="java.util.Properties">
> >     >>     <constructor-arg>
> >     >>         <props>
> >     >>             <prop
> >     >> key="org.apache.ws.security.crypto.provider">org.apache.
> >     >> ws.security.components.crypto.Merlin</prop>
> >     >>             <prop
> >     >> key="org.apache.ws.security.crypto.merlin.keystore.type">
> jks</prop>
> >     >>             <prop
> >     >> key="org.apache.ws.security.crypto.merlin.keystore.password">
> >     .... </prop>
> >     >>             <prop
> >     >> key="org.apache.ws.security.crypto.merlin.file">key/key.
> jks</prop>
> >     >>         </props>
> >     >>     </constructor-arg>
> >     >> </bean>
> >     >>     <bean id="utSTSProperties"
> >     >> class="org.apache.cxf.sts.StaticSTSProperties">
> >     >>         <property name="SignatureCryptoProperties"
> >     >> ref="cryptoProperties"/>
> >     >>     ....
> >     >>     </bean>
> >     >>
> >     >> and put the keyfile under the WEB-INF/classes/key
> >     >> (in the keyfile the keys for signing the new SAML)
> >     >>
> >     >> Thanx
> >     >> Csaba
> >     >>
> >     >>
> >     >> On 2018.01.25. 13 <tel:2018.01.25.%2013>:40, Colm O
> >     hEigeartaigh wrote:
> >     >>> Do you mean that there was a "saml2p:Status" element in the
> >     security
> >     >> header
> >     >>> before the Assertion? If so then this is not valid, only the SAML
> >     >> Assertion
> >     >>> should be there.
> >     >>>
> >     >>> Colm.
> >     >>>
> >     >>> On Thu, Jan 25, 2018 at 8:47 AM, Tóth Csaba <[hidden email]
> >     <mailto:[hidden email]>> wrote:
> >     >>>
> >     >>>> Hello!
> >     >>>>
> >     >>>> I dig deeper in the code:
> >     >>>> The problem with the SAML was:
> >     >>>> In the securty element contains not only the SAML, its
> >     contains before
> >     >>>> the SAML an
> >     >>>> <saml2:Issuer> and an <saml2p:Status> element
> >     >>>> (in his case The same is not processed)
> >     >>>>
> >     >>>> If I delete it, its go thru the SAML validator
> >     >>>>
> >     >>>> Csaba
> >     >>>>
> >     >>>> On 2018.01.24. 19 <tel:2018.01.24.%2019>:25, Tóth Csaba wrote:
> >     >>>>> Hello!
> >     >>>>> Thanx. I changed the namespace, but not helped.
> >     >>>>>
> >     >>>>> The DefaultSubjectProvider cant retrieve the subject from
> >     this SAML:
> >     >>>>>
> >     >>>>> <saml2:Assertion ID="..." IssueInstant="..." Version="2.0"
> >     >>>>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
> >     >>>>>
> >     >>>>>     <saml2:Subject>
> >     >>>>>         <saml2:NameID
> >     >>>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:
> >     >>>> persistent">[name]</saml2:NameID>
> >     >>>>>         <saml2:SubjectConfirmation
> >     >>>>> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
> >     >>>>>             <saml2:SubjectConfirmationData
> >     >>>>> InResponseTo="_9c7644ce0fb93649cd2ca77bb9b5e6db22f68b52a9"
> >     >>>>> NotOnOrAfter="2018-01-24T18:06:33.305Z"/>
> >     >>>>>         </saml2:SubjectConfirmation>
> >     >>>>>     </saml2:Subject>
> >     >>>>>
> >     >>>>> </saml2:Assertion>
> >     >>>>>
> >     >>>>> But I get an error, because the subject is null
> >     >>>>> (At this point I cant change the SAML in the request)
> >     >>>>>
> >     >>>>> Thanx
> >     >>>>>
> >     >>>>> Csaba
> >     >>>>>
> >     >>>>> On 2018.01.24. 10:55, Colm O hEigeartaigh wrote:
> >     >>>>>> The problem I think is that "http://schemas.xmlsoap.org/
> >     >>>> ws/2003/06/secext"
> >     >>>>>> is not a standard WS-Security namespace, and hence CXF is not
> >     >> processing
> >     >>>>>> the message header at all. The correct WS-Security
> >     namespace for the
> >     >>>>>> security header is instead "
> >     >>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
> >     <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss->
> >     >>>> wssecurity-secext-1.0.xsd
> >     >>>>>> ".
> >     >>>>>>
> >     >>>>>> You could take a look at the CXF transformation feature to
> >     transform
> >     >> the
> >     >>>>>> namespace into the correct version (no idea if this will
> >     work or not):
> >     >>>>>>
> >     >>>>>> http://cxf.apache.org/docs/transformationfeature.html
> >     <http://cxf.apache.org/docs/transformationfeature.html>
> >     >>>>>>
> >     >>>>>> Colm.
> >     >>>>>>
> >     >>>>>>
> >     >>>>>> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[hidden email]
> >     <mailto:[hidden email]>> wrote:
> >     >>>>>>
> >     >>>>>>> Hello!
> >     >>>>>>> Its in the header:
> >     >>>>>>> ------------
> >     >>>>>>> <soapenv:Envelope
> >     >>>>>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/
> >     <http://schemas.xmlsoap.org/soap/envelope/>"
> >     >>>>>>> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512
> >     <http://docs.oasis-open.org/ws-sx/ws-trust/200512>"
> >     >>>>>>> xmlns:a="http://www.w3.org/2005/08/addressing
> >     <http://www.w3.org/2005/08/addressing>">
> >     >>>>>>>    <soapenv:Header>
> >     >>>>>>>   <wsse:Security xmlns:wsse="http://schemas.
> >     >>>> xmlsoap.org/ws/2003/06/secext
> >     <http://xmlsoap.org/ws/2003/06/secext>"
> >     >>>>>>>     <saml:Assertion xmlns:saml="urn:oasis:names:
> >     >> tc:SAML:2.0:assertion"
> >     >>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
> >     <http://www.w3.org/2001/XMLSchema-instance>"
> >     >>>>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema
> >     <http://www.w3.org/2001/XMLSchema>"
> >     >>>>>>> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0"
> >     >>>>>>> IssueInstant="2014-07-17T01:01:48Z">
> >     >>>>>>>
> >     >>>>>>>   [assertion]
> >     >>>>>>>
> >     >>>>>>>   </saml:Assertion>
> >     >>>>>>>
> >     >>>>>>>   </wsse:Security>
> >     >>>>>>>   </soapenv:Header>
> >     >>>>>>>  <soapenv:Body>
> >     >>>>>>>       <ns:RequestSecurityToken >
> >     >>>>>>>
> >     >>>>>>> <ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/
> >     <http://docs.oasis-open.org/ws-sx/ws-trust/>
> >     >> 200512/Issue
> >     >>>>>>> </ns:RequestType>
> >     >>>>>>>
> >     >>>>>>> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-
> >     <http://docs.oasis-open.org/wss/oasis-wss->
> >     >>>>>>> saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
> >     >>>>>>>   <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy
> >     <http://www.w3.org/ns/ws-policy>">  [url]
> >     >>>>>>> </ns7:AppliesTo>
> >     >>>>>>>   <!--
> >     >>>>>>>    <ns:Claims Dialect="http://bag.admin.ch/
> >     >> epr/2017/annex/5/addendum/2
> >     >>>> ">
> >     >>>>>>> [claims need to process too ]
> >     >>>>>>>
> >     >>>>>>>  </ns:Claims>
> >     >>>>>>> -->
> >     >>>>>>>  </ns:RequestSecurityToken>
> >     >>>>>>>  </soapenv:Body>
> >     >>>>>>> </soapenv:Envelope>
> >     >>>>>>> ---------------------
> >     >>>>>>>
> >     >>>>>>> Its look like easy task for the first look:
> >     >>>>>>> get a SAML in the header, full of attributes, and a
> >     request with
> >     >> other
> >     >>>>>>> attributes.
> >     >>>>>>> Validate some attributes, and all header attributes + claims
> >     >> attributes
> >     >>>>>>> put the new SAML token.
> >     >>>>>>>
> >     >>>>>>> but, about a week long, I google, read source code, google
> >     again, and
> >     >>>>>>> try to config the thing.
> >     >>>>>>> no good tutorial, no good documentation, no good
> >     description :(
> >     >>>>>>>
> >     >>>>>>> Csaba
> >     >>>>>>>
> >     >>>>>>>
> >     >>>>>>>
> >     >>>>>>> On 2018.01.23. 18 <tel:2018.01.23.%2018>:08, Colm O
> >     hEigeartaigh wrote:
> >     >>>>>>>> What does the request look like, e.g. where is the SAML
> >     token in the
> >     >>>>>>>> request? Is it referred to directly in the SOAP Body?
> >     >>>>>>>>
> >     >>>>>>>> Colm.
> >     >>>>>>>>
> >     >>>>>>>> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba
> >     <[hidden email] <mailto:[hidden email]>> wrote:
> >     >>>>>>>>
> >     >>>>>>>>> Hello!
> >     >>>>>>>>>
> >     >>>>>>>>> I'd like to parse the incomming SAML token to get the
> >     fields (user,
> >     >>>> etc)
> >     >>>>>>>>> and give it to the issuer.
> >     >>>>>>>>> I found, that is done in the
> >     >>>>>>>>> org.apache.cxf.sts.operation.TokenIssueOperation class but
> >     >>>>>>>>> stsProperties.getSamlRealmCodec() is always null in my
> >     code (how
> >     >>>> can i
> >     >>>>>>>>> set it, need to create a new one?)
> >     >>>>>>>>> but after in the fetchSAMLAssertionFromWSSecuri
> tySAMLToken()
> >     >>>> function
> >     >>>>>>>>> List<WSSecurityEngineResult> engineResults =
> >     >>>> handlerResult.getResults();
> >     >>>>>>>>> line give back an empty list.
> >     >>>>>>>>>
> >     >>>>>>>>> In the request there is an SAML token.
> >     >>>>>>>>>
> >     >>>>>>>>> I try to find some solution, but every example is
> >     working with the
> >     >>>>>>>>> usernametoken, and/or dont provide a valid cxf config xml.
> >     >>>>>>>>>
> >     >>>>>>>>> Thanx
> >     >>>>>>>>> Csaba
> >     >>>>>>>>>
> >     >>>>>>>>>
> >     >>
> >     >
> >
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
>
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

Tóth Csaba
Hello!
I'm now very confused:

I have this config file:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:cxf="http://cxf.apache.org/core"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:sec="http://cxf.apache.org/configuration/security"
    xmlns:http="http://cxf.apache.org/transports/http/configuration"
    xmlns:httpj="http://cxf.apache.org/transports/http-jetty/configuration"
    xmlns:jaxws="http://cxf.apache.org/jaxws"
    xmlns:util="http://www.springframework.org/schema/util"
    xmlns:soap="http://cxf.apache.org/bindings/soap"
    xsi:schemaLocation="http://cxf.apache.org/core
http://cxf.apache.org/schemas/core.xsd
http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd 
http://cxf.apache.org/transports/http-jetty/configuration
http://cxf.apache.org/schemas/configuration/http-jetty.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-4.2.xsd
http://cxf.apache.org/bindings/soap
http://cxf.apache.org/schemas/configuration/soap.xsd">

    <bean id="defaultTokenStore"
class="org.apache.cxf.sts.cache.DefaultInMemoryTokenStore">
        </bean>
<bean id="cryptoProperties" class="java.util.Properties">
    <constructor-arg>
        <props>
            <prop
key="org.apache.ws.security.crypto.provider">org.apache.ws.security.components.crypto.Merlin</prop>
            <prop
key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop>
            <prop
key="org.apache.ws.security.crypto.merlin.keystore.password">.....</prop>
            <prop
key="org.apache.ws.security.crypto.merlin.file">key/key.jks</prop>
        </props>
    </constructor-arg>
</bean>

    <bean id="utSTSProperties"
class="org.apache.cxf.sts.StaticSTSProperties">
        <property name="SignatureCryptoProperties" ref="cryptoProperties"/>
        <property name="issuer" value="issuer"/>
        <property name="signatureUsername" value="signature"/>
    </bean>

    <bean id="utService" class="org.apache.cxf.sts.service.StaticService">
        <property name="endpoints" value="http://localhost: xxxx
/services/SecurityTokenServiceProvider" />
    </bean>

     <bean id="utSCTSamlTokenProvider"
class="org.apache.cxf.sts.token.provider.SAMLTokenProvider">
     </bean>

    <util:list id="utTokenProviders">
        <ref bean="utSCTSamlTokenProvider"/>
    </util:list>
   
    <bean id="utIssueDelegate" class=" package .TokenIssueOperation">
        <property name="tokenProviders" ref="utTokenProviders"/>
                 <property name="services" ref="utService" />
        <property name="stsProperties" ref="utSTSProperties" />
        <property name="tokenStore" ref="defaultTokenStore"/>
    </bean>
   
    <bean id="utSTSProviderBean" class=" package
.SecurityTokenServiceProvider">
        <property name="issueOperation" ref="utIssueDelegate" />
    </bean>
    <!--
    <bean id="utSTSProviderBean"
class="org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider">
        <property name="issueOperation" ref="utIssueDelegate" />
    </bean>
    -->
   
    <jaxws:endpoint
xmlns:tns="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"
        id="securitytokenserviceprovider" implementor="#utSTSProviderBean"
        wsdlLocation="WEB-INF/wsdl/ws-trust-1.4-service.wsdl"
endpointName="tns:UT_Port"
        serviceName="tns:SecurityTokenService"
address="/SecurityTokenServiceProvider">
        <jaxws:properties>

            <entry key="security.return.security.error" value="true" />
            <entry key="security.validate.audience-restriction"
value="false" />
            <entry key="security.signature.properties">
                <bean id="signatureCryptoProperties"
class="java.util.Properties">
                    <constructor-arg>
                        <props>
             <prop
key="org.apache.ws.security.crypto.provider">org.apache.ws.security.components.crypto.Merlin</prop>
            <prop
key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop>
            <prop
key="org.apache.ws.security.crypto.merlin.keystore.password">.....</prop>
            <prop
key="org.apache.ws.security.crypto.merlin.file">key/key.jks</prop>
                        </props>
                    </constructor-arg>
                </bean>
            </entry>
            <entry key="ws-security.saml2.validator">
                <bean
class="org.apache.cxf.ws.security.trust.STSTokenValidator"/>
            </entry>
        </jaxws:properties>
        <jaxws:binding>
            <soap:soapBinding mtomEnabled="true" version="1.2" />
        </jaxws:binding>
    </jaxws:endpoint>
</beans>

the keystore is under WEB-INF, it cointains the cert from the incomming
Cert.

all help thanks.

Csaba

On 2018.01.26. 15:40, Colm O hEigeartaigh wrote:

> OK so it appears the problems with the STS issuing the token have been
> fixed? The errors are from the STSSamlAssertionValidator, which is supposed
> to be used on the service side. It tries to validate the Signature locally
> on the token, and if it fails it dispatches the token to the STS for
> validation, which is why you're seeing an error about STSClient.
>
> What behaviour are you expecting on the service side? Normally the
> STSSamlAssertionValidator
> is not configured, because you have the CA cert of the STS in the service
> keystore and it can validate the certificate locally. Is the STS cert (or
> CA cert) in your crypto properties file pointing to by the
> security.signature.properties configuration variable on the service side?
>
> Colm.
>
> On Fri, Jan 26, 2018 at 11:56 AM, Tóth Csaba <[hidden email]> wrote:
>
>> Hello!
>> (Sorry for the wrong address)
>>
>> It's go forward with little steps.
>> now I get this error:
>> jan. 26, 2018 12:42:21 DU
>> org.apache.cxf.ws.security.trust.STSSamlAssertionValidator
>> verifySignedAssertion
>> WARNING: Local trust verification of SAML assertion failed: Error during
>> certificate path validation: No trusted certs found
>> org.apache.wss4j.common.ext.WSSecurityException: Error during
>> certificate path validation: No trusted certs found
>>     at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:829)
>>     at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:919)
>>     at
>> org.apache.wss4j.dom.validate.SignatureTrustValidator.verifyTrustInCerts(
>> SignatureTrustValidator.java:109)
>>     at
>> org.apache.wss4j.dom.validate.SignatureTrustValidator.validate(
>> SignatureTrustValidator.java:64)
>>     at
>> org.apache.wss4j.dom.validate.SamlAssertionValidator.
>> verifySignedAssertion(SamlAssertionValidator.java:214)
>>     at
>> org.apache.cxf.ws.security.trust.STSSamlAssertionValidator.
>> verifySignedAssertion(STSSamlAssertionValidator.java:68)
>>
>> I get the certification from the SAML, and put into the keystore what i
>> already setup (and put under the WEB-INF/classes/key directory
>>
>> the strange thing, the next error come about:
>> jan. 26, 2018 12:42:24 DU org.apache.cxf.phase.PhaseInterceptorChain
>> doDefaultLogging
>> WARNING: Interceptor for
>> {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService
>> has thrown exception, unwinding now
>> org.apache.cxf.ws.security.trust.TrustException: The STSClient is not
>> configured with either a location or wsdlLocation property
>>     at
>> org.apache.cxf.ws.security.trust.AbstractSTSClient.createClient(
>> AbstractSTSClient.java:673)
>>     at
>> org.apache.cxf.ws.security.trust.AbstractSTSClient.
>> validate(AbstractSTSClient.java:1101)
>>     at
>> org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken(
>> STSClient.java:105)
>>
>> What STSClient? why want to create a client?
>> in the cxf settings no "client" string is found
>>
>> Thanx
>> Csaba
>>
>> On 2018.01.25. 15:48, Colm O hEigeartaigh wrote:
>>> Please reply to the CXF mailing list and not me directly...the problem
>>> is that the SAML Assertion is getting validated before it hits the
>>> STS, so you need to make a reference to the signature properties as a
>>> JAX-WS property of the endpoint. For example:
>>>
>>> https://github.com/apache/cxf/blob/6a3f97e9f0d02eef72bf10c266d444
>> ec3af78bf5/services/sts/systests/basic/src/test/resources/org/apache/cxf/
>> systest/sts/transport/cxf-service.xml#L44
>>> On Thu, Jan 25, 2018 at 2:38 PM, Tóth Csaba <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>     Hello!
>>>     this is the full trace:
>>>
>>>     jan. 25, 2018 2:17:13 DU org.apache.cxf.phase.PhaseInterceptorChain
>>>     doDefaultLogging
>>>     WARNING: Interceptor for
>>>     {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}
>> SecurityTokenService
>>>     <<a href="http://docs.oasis-open.org/ws-sx/ws-trust/200512/%">http://docs.oasis-open.org/ws-sx/ws-trust/200512/%
>> 7DSecurityTokenService>
>>>     has thrown exception, unwinding now
>>>     org.apache.cxf.binding.soap.SoapFault: No crypto property file
>>>     supplied
>>>     for signature
>>>         at
>>>     org.apache.cxf.ws.security.wss4j.WSS4JUtils.
>> createSoapFault(WSS4JUtils.java:236)
>>>         at
>>>     org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.
>> handleMessageInternal(WSS4JInInterceptor.java:340)
>>>         at
>>>     org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(
>> WSS4JInInterceptor.java:175)
>>>         at
>>>     org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.
>> handleMessage(PolicyBasedWSS4JInInterceptor.java:79)
>>>         at
>>>     org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.
>> handleMessage(PolicyBasedWSS4JInInterceptor.java:66)
>>>         at
>>>     org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
>> PhaseInterceptorChain.java:308)
>>>         at
>>>     org.apache.cxf.transport.ChainInitiationObserver.onMessage(
>> ChainInitiationObserver.java:121)
>>>         at
>>>     org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(
>> AbstractHTTPDestination.java:267)
>>>         at
>>>     org.apache.cxf.transport.servlet.ServletController.
>> invokeDestination(ServletController.java:234)
>>>         at
>>>     org.apache.cxf.transport.servlet.ServletController.
>> invoke(ServletController.java:208)
>>>         at
>>>     org.apache.cxf.transport.servlet.ServletController.
>> invoke(ServletController.java:160)
>>>         at
>>>     org.apache.cxf.transport.servlet.CXFNonSpringServlet.
>> invoke(CXFNonSpringServlet.java:191)
>>>         at
>>>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(
>> AbstractHTTPServlet.java:301)
>>>         at
>>>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.
>> doPost(AbstractHTTPServlet.java:220)
>>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:661)
>>>         at
>>>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.
>> service(AbstractHTTPServlet.java:276)
>>>         at
>>>     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
>> ApplicationFilterChain.java:231)
>>>         at
>>>     org.apache.catalina.core.ApplicationFilterChain.doFilter(
>> ApplicationFilterChain.java:166)
>>>         at
>>>     org.apache.tomcat.websocket.server.WsFilter.doFilter(
>> WsFilter.java:52)
>>>         at
>>>     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
>> ApplicationFilterChain.java:193)
>>>         at
>>>     org.apache.catalina.core.ApplicationFilterChain.doFilter(
>> ApplicationFilterChain.java:166)
>>>         at
>>>     org.apache.catalina.core.StandardWrapperValve.invoke(
>> StandardWrapperValve.java:198)
>>>         at
>>>     org.apache.catalina.core.StandardContextValve.invoke(
>> StandardContextValve.java:96)
>>>         at
>>>     org.apache.catalina.authenticator.AuthenticatorBase.invoke(
>> AuthenticatorBase.java:504)
>>>         at
>>>     org.apache.catalina.core.StandardHostValve.invoke(
>> StandardHostValve.java:140)
>>>         at
>>>     org.apache.catalina.valves.ErrorReportValve.invoke(
>> ErrorReportValve.java:81)
>>>         at
>>>     org.apache.catalina.valves.AbstractAccessLogValve.invoke(
>> AbstractAccessLogValve.java:650)
>>>         at
>>>     org.apache.catalina.core.StandardEngineValve.invoke(
>> StandardEngineValve.java:87)
>>>         at
>>>     org.apache.catalina.connector.CoyoteAdapter.service(
>> CoyoteAdapter.java:342)
>>>         at
>>>     org.apache.coyote.http11.Http11Processor.service(
>> Http11Processor.java:803)
>>>         at
>>>     org.apache.coyote.AbstractProcessorLight.process(
>> AbstractProcessorLight.java:66)
>>>         at
>>>     org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
>> AbstractProtocol.java:790)
>>>         at
>>>     org.apache.tomcat.util.net
>>>     <http://org.apache.tomcat.util.net>.NioEndpoint$
>> SocketProcessor.doRun(NioEndpoint.java:1459)
>>>         at
>>>     org.apache.tomcat.util.net
>>>     <http://org.apache.tomcat.util.net>.SocketProcessorBase.
>> run(SocketProcessorBase.java:49)
>>>         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
>>>     Source)
>>>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>>>     Source)
>>>         at
>>>     org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
>> TaskThread.java:61)
>>>         at java.lang.Thread.run(Unknown Source)
>>>
>>>     Csaba
>>>
>>>     On 2018.01.25. 15 <tel:2018.01.25.%2015>:32, Colm O hEigeartaigh
>>>     wrote:
>>>     > What's the full stack-trace?
>>>     >
>>>     > On Thu, Jan 25, 2018 at 1:44 PM, Tóth Csaba <[hidden email]
>>>     <mailto:[hidden email]>> wrote:
>>>     >
>>>     >> Hello!
>>>     >> Yes, after I deleted it, its begin to parse the SAML.
>>>     >> the next error is about the SigVerCrypto is empty at the
>>>     >> SignatureTrustValidator.validate step.
>>>     >>  (get from the RequestData.sigVerCrypto)
>>>     >>
>>>     >> I set up the thing:
>>>     >>
>>>     >> <bean id="cryptoProperties" class="java.util.Properties">
>>>     >>     <constructor-arg>
>>>     >>         <props>
>>>     >>             <prop
>>>     >> key="org.apache.ws.security.crypto.provider">org.apache.
>>>     >> ws.security.components.crypto.Merlin</prop>
>>>     >>             <prop
>>>     >> key="org.apache.ws.security.crypto.merlin.keystore.type">
>> jks</prop>
>>>     >>             <prop
>>>     >> key="org.apache.ws.security.crypto.merlin.keystore.password">
>>>     .... </prop>
>>>     >>             <prop
>>>     >> key="org.apache.ws.security.crypto.merlin.file">key/key.
>> jks</prop>
>>>     >>         </props>
>>>     >>     </constructor-arg>
>>>     >> </bean>
>>>     >>     <bean id="utSTSProperties"
>>>     >> class="org.apache.cxf.sts.StaticSTSProperties">
>>>     >>         <property name="SignatureCryptoProperties"
>>>     >> ref="cryptoProperties"/>
>>>     >>     ....
>>>     >>     </bean>
>>>     >>
>>>     >> and put the keyfile under the WEB-INF/classes/key
>>>     >> (in the keyfile the keys for signing the new SAML)
>>>     >>
>>>     >> Thanx
>>>     >> Csaba
>>>     >>
>>>     >>
>>>     >> On 2018.01.25. 13 <tel:2018.01.25.%2013>:40, Colm O
>>>     hEigeartaigh wrote:
>>>     >>> Do you mean that there was a "saml2p:Status" element in the
>>>     security
>>>     >> header
>>>     >>> before the Assertion? If so then this is not valid, only the SAML
>>>     >> Assertion
>>>     >>> should be there.
>>>     >>>
>>>     >>> Colm.
>>>     >>>
>>>     >>> On Thu, Jan 25, 2018 at 8:47 AM, Tóth Csaba <[hidden email]
>>>     <mailto:[hidden email]>> wrote:
>>>     >>>
>>>     >>>> Hello!
>>>     >>>>
>>>     >>>> I dig deeper in the code:
>>>     >>>> The problem with the SAML was:
>>>     >>>> In the securty element contains not only the SAML, its
>>>     contains before
>>>     >>>> the SAML an
>>>     >>>> <saml2:Issuer> and an <saml2p:Status> element
>>>     >>>> (in his case The same is not processed)
>>>     >>>>
>>>     >>>> If I delete it, its go thru the SAML validator
>>>     >>>>
>>>     >>>> Csaba
>>>     >>>>
>>>     >>>> On 2018.01.24. 19 <tel:2018.01.24.%2019>:25, Tóth Csaba wrote:
>>>     >>>>> Hello!
>>>     >>>>> Thanx. I changed the namespace, but not helped.
>>>     >>>>>
>>>     >>>>> The DefaultSubjectProvider cant retrieve the subject from
>>>     this SAML:
>>>     >>>>>
>>>     >>>>> <saml2:Assertion ID="..." IssueInstant="..." Version="2.0"
>>>     >>>>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
>>>     >>>>>
>>>     >>>>>     <saml2:Subject>
>>>     >>>>>         <saml2:NameID
>>>     >>>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:
>>>     >>>> persistent">[name]</saml2:NameID>
>>>     >>>>>         <saml2:SubjectConfirmation
>>>     >>>>> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
>>>     >>>>>             <saml2:SubjectConfirmationData
>>>     >>>>> InResponseTo="_9c7644ce0fb93649cd2ca77bb9b5e6db22f68b52a9"
>>>     >>>>> NotOnOrAfter="2018-01-24T18:06:33.305Z"/>
>>>     >>>>>         </saml2:SubjectConfirmation>
>>>     >>>>>     </saml2:Subject>
>>>     >>>>>
>>>     >>>>> </saml2:Assertion>
>>>     >>>>>
>>>     >>>>> But I get an error, because the subject is null
>>>     >>>>> (At this point I cant change the SAML in the request)
>>>     >>>>>
>>>     >>>>> Thanx
>>>     >>>>>
>>>     >>>>> Csaba
>>>     >>>>>
>>>     >>>>> On 2018.01.24. 10:55, Colm O hEigeartaigh wrote:
>>>     >>>>>> The problem I think is that "http://schemas.xmlsoap.org/
>>>     >>>> ws/2003/06/secext"
>>>     >>>>>> is not a standard WS-Security namespace, and hence CXF is not
>>>     >> processing
>>>     >>>>>> the message header at all. The correct WS-Security
>>>     namespace for the
>>>     >>>>>> security header is instead "
>>>     >>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
>>>     <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss->
>>>     >>>> wssecurity-secext-1.0.xsd
>>>     >>>>>> ".
>>>     >>>>>>
>>>     >>>>>> You could take a look at the CXF transformation feature to
>>>     transform
>>>     >> the
>>>     >>>>>> namespace into the correct version (no idea if this will
>>>     work or not):
>>>     >>>>>>
>>>     >>>>>> http://cxf.apache.org/docs/transformationfeature.html
>>>     <http://cxf.apache.org/docs/transformationfeature.html>
>>>     >>>>>>
>>>     >>>>>> Colm.
>>>     >>>>>>
>>>     >>>>>>
>>>     >>>>>> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[hidden email]
>>>     <mailto:[hidden email]>> wrote:
>>>     >>>>>>
>>>     >>>>>>> Hello!
>>>     >>>>>>> Its in the header:
>>>     >>>>>>> ------------
>>>     >>>>>>> <soapenv:Envelope
>>>     >>>>>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/
>>>     <http://schemas.xmlsoap.org/soap/envelope/>"
>>>     >>>>>>> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512
>>>     <http://docs.oasis-open.org/ws-sx/ws-trust/200512>"
>>>     >>>>>>> xmlns:a="http://www.w3.org/2005/08/addressing
>>>     <http://www.w3.org/2005/08/addressing>">
>>>     >>>>>>>    <soapenv:Header>
>>>     >>>>>>>   <wsse:Security xmlns:wsse="http://schemas.
>>>     >>>> xmlsoap.org/ws/2003/06/secext
>>>     <http://xmlsoap.org/ws/2003/06/secext>"
>>>     >>>>>>>     <saml:Assertion xmlns:saml="urn:oasis:names:
>>>     >> tc:SAML:2.0:assertion"
>>>     >>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
>>>     <http://www.w3.org/2001/XMLSchema-instance>"
>>>     >>>>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema
>>>     <http://www.w3.org/2001/XMLSchema>"
>>>     >>>>>>> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0"
>>>     >>>>>>> IssueInstant="2014-07-17T01:01:48Z">
>>>     >>>>>>>
>>>     >>>>>>>   [assertion]
>>>     >>>>>>>
>>>     >>>>>>>   </saml:Assertion>
>>>     >>>>>>>
>>>     >>>>>>>   </wsse:Security>
>>>     >>>>>>>   </soapenv:Header>
>>>     >>>>>>>  <soapenv:Body>
>>>     >>>>>>>       <ns:RequestSecurityToken >
>>>     >>>>>>>
>>>     >>>>>>> <ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/
>>>     <http://docs.oasis-open.org/ws-sx/ws-trust/>
>>>     >> 200512/Issue
>>>     >>>>>>> </ns:RequestType>
>>>     >>>>>>>
>>>     >>>>>>> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-
>>>     <http://docs.oasis-open.org/wss/oasis-wss->
>>>     >>>>>>> saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
>>>     >>>>>>>   <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy
>>>     <http://www.w3.org/ns/ws-policy>">  [url]
>>>     >>>>>>> </ns7:AppliesTo>
>>>     >>>>>>>   <!--
>>>     >>>>>>>    <ns:Claims Dialect="http://bag.admin.ch/
>>>     >> epr/2017/annex/5/addendum/2
>>>     >>>> ">
>>>     >>>>>>> [claims need to process too ]
>>>     >>>>>>>
>>>     >>>>>>>  </ns:Claims>
>>>     >>>>>>> -->
>>>     >>>>>>>  </ns:RequestSecurityToken>
>>>     >>>>>>>  </soapenv:Body>
>>>     >>>>>>> </soapenv:Envelope>
>>>     >>>>>>> ---------------------
>>>     >>>>>>>
>>>     >>>>>>> Its look like easy task for the first look:
>>>     >>>>>>> get a SAML in the header, full of attributes, and a
>>>     request with
>>>     >> other
>>>     >>>>>>> attributes.
>>>     >>>>>>> Validate some attributes, and all header attributes + claims
>>>     >> attributes
>>>     >>>>>>> put the new SAML token.
>>>     >>>>>>>
>>>     >>>>>>> but, about a week long, I google, read source code, google
>>>     again, and
>>>     >>>>>>> try to config the thing.
>>>     >>>>>>> no good tutorial, no good documentation, no good
>>>     description :(
>>>     >>>>>>>
>>>     >>>>>>> Csaba
>>>     >>>>>>>
>>>     >>>>>>>
>>>     >>>>>>>
>>>     >>>>>>> On 2018.01.23. 18 <tel:2018.01.23.%2018>:08, Colm O
>>>     hEigeartaigh wrote:
>>>     >>>>>>>> What does the request look like, e.g. where is the SAML
>>>     token in the
>>>     >>>>>>>> request? Is it referred to directly in the SOAP Body?
>>>     >>>>>>>>
>>>     >>>>>>>> Colm.
>>>     >>>>>>>>
>>>     >>>>>>>> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba
>>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>>     >>>>>>>>
>>>     >>>>>>>>> Hello!
>>>     >>>>>>>>>
>>>     >>>>>>>>> I'd like to parse the incomming SAML token to get the
>>>     fields (user,
>>>     >>>> etc)
>>>     >>>>>>>>> and give it to the issuer.
>>>     >>>>>>>>> I found, that is done in the
>>>     >>>>>>>>> org.apache.cxf.sts.operation.TokenIssueOperation class but
>>>     >>>>>>>>> stsProperties.getSamlRealmCodec() is always null in my
>>>     code (how
>>>     >>>> can i
>>>     >>>>>>>>> set it, need to create a new one?)
>>>     >>>>>>>>> but after in the fetchSAMLAssertionFromWSSecuri
>> tySAMLToken()
>>>     >>>> function
>>>     >>>>>>>>> List<WSSecurityEngineResult> engineResults =
>>>     >>>> handlerResult.getResults();
>>>     >>>>>>>>> line give back an empty list.
>>>     >>>>>>>>>
>>>     >>>>>>>>> In the request there is an SAML token.
>>>     >>>>>>>>>
>>>     >>>>>>>>> I try to find some solution, but every example is
>>>     working with the
>>>     >>>>>>>>> usernametoken, and/or dont provide a valid cxf config xml.
>>>     >>>>>>>>>
>>>     >>>>>>>>> Thanx
>>>     >>>>>>>>> Csaba
>>>     >>>>>>>>>
>>>     >>>>>>>>>
>>>     >>
>>>     >
>>>
>>>
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

Tóth Csaba
Hello!
Its SOLVED!

there were multiple errors:
- typo in the keystore filename,
- the Cryptoproperties must be in a property file, what need to put
under WEB-INF/classes/
- the SignatureUsername is the alias in the keystore
- must be a password callback handler for the password to the private
key (and its hard to config thru the config files)

thanx
Csaba

On 2018.01.26. 18:49, Tóth Csaba wrote:

> Hello!
> I'm now very confused:
>
> I have this config file:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <beans xmlns="http://www.springframework.org/schema/beans"
>     xmlns:cxf="http://cxf.apache.org/core"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xmlns:sec="http://cxf.apache.org/configuration/security"
>     xmlns:http="http://cxf.apache.org/transports/http/configuration"
>     xmlns:httpj="http://cxf.apache.org/transports/http-jetty/configuration"
>     xmlns:jaxws="http://cxf.apache.org/jaxws"
>     xmlns:util="http://www.springframework.org/schema/util"
>     xmlns:soap="http://cxf.apache.org/bindings/soap"
>     xsi:schemaLocation="http://cxf.apache.org/core
> http://cxf.apache.org/schemas/core.xsd
> http://cxf.apache.org/configuration/security
> http://cxf.apache.org/schemas/configuration/security.xsd
> http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
> http://cxf.apache.org/transports/http/configuration
> http://cxf.apache.org/schemas/configuration/http-conf.xsd 
> http://cxf.apache.org/transports/http-jetty/configuration
> http://cxf.apache.org/schemas/configuration/http-jetty.xsd
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util-4.2.xsd
> http://cxf.apache.org/bindings/soap
> http://cxf.apache.org/schemas/configuration/soap.xsd">
>
>     <bean id="defaultTokenStore"
> class="org.apache.cxf.sts.cache.DefaultInMemoryTokenStore">
>         </bean>
> <bean id="cryptoProperties" class="java.util.Properties">
>     <constructor-arg>
>         <props>
>             <prop
> key="org.apache.ws.security.crypto.provider">org.apache.ws.security.components.crypto.Merlin</prop>
>             <prop
> key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop>
>             <prop
> key="org.apache.ws.security.crypto.merlin.keystore.password">.....</prop>
>             <prop
> key="org.apache.ws.security.crypto.merlin.file">key/key.jks</prop>
>         </props>
>     </constructor-arg>
> </bean>
>
>     <bean id="utSTSProperties"
> class="org.apache.cxf.sts.StaticSTSProperties">
>         <property name="SignatureCryptoProperties" ref="cryptoProperties"/>
>         <property name="issuer" value="issuer"/>
>         <property name="signatureUsername" value="signature"/>
>     </bean>
>
>     <bean id="utService" class="org.apache.cxf.sts.service.StaticService">
>         <property name="endpoints" value="http://localhost: xxxx
> /services/SecurityTokenServiceProvider" />
>     </bean>
>
>      <bean id="utSCTSamlTokenProvider"
> class="org.apache.cxf.sts.token.provider.SAMLTokenProvider">
>      </bean>
>
>     <util:list id="utTokenProviders">
>         <ref bean="utSCTSamlTokenProvider"/>
>     </util:list>
>    
>     <bean id="utIssueDelegate" class=" package .TokenIssueOperation">
>         <property name="tokenProviders" ref="utTokenProviders"/>
>                  <property name="services" ref="utService" />
>         <property name="stsProperties" ref="utSTSProperties" />
>         <property name="tokenStore" ref="defaultTokenStore"/>
>     </bean>
>    
>     <bean id="utSTSProviderBean" class=" package
> .SecurityTokenServiceProvider">
>         <property name="issueOperation" ref="utIssueDelegate" />
>     </bean>
>     <!--
>     <bean id="utSTSProviderBean"
> class="org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider">
>         <property name="issueOperation" ref="utIssueDelegate" />
>     </bean>
>     -->
>    
>     <jaxws:endpoint
> xmlns:tns="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"
>         id="securitytokenserviceprovider" implementor="#utSTSProviderBean"
>         wsdlLocation="WEB-INF/wsdl/ws-trust-1.4-service.wsdl"
> endpointName="tns:UT_Port"
>         serviceName="tns:SecurityTokenService"
> address="/SecurityTokenServiceProvider">
>         <jaxws:properties>
>
>             <entry key="security.return.security.error" value="true" />
>             <entry key="security.validate.audience-restriction"
> value="false" />
>             <entry key="security.signature.properties">
>                 <bean id="signatureCryptoProperties"
> class="java.util.Properties">
>                     <constructor-arg>
>                         <props>
>              <prop
> key="org.apache.ws.security.crypto.provider">org.apache.ws.security.components.crypto.Merlin</prop>
>             <prop
> key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop>
>             <prop
> key="org.apache.ws.security.crypto.merlin.keystore.password">.....</prop>
>             <prop
> key="org.apache.ws.security.crypto.merlin.file">key/key.jks</prop>
>                         </props>
>                     </constructor-arg>
>                 </bean>
>             </entry>
>             <entry key="ws-security.saml2.validator">
>                 <bean
> class="org.apache.cxf.ws.security.trust.STSTokenValidator"/>
>             </entry>
>         </jaxws:properties>
>         <jaxws:binding>
>             <soap:soapBinding mtomEnabled="true" version="1.2" />
>         </jaxws:binding>
>     </jaxws:endpoint>
> </beans>
>
> the keystore is under WEB-INF, it cointains the cert from the incomming
> Cert.
>
> all help thanks.
>
> Csaba
>
> On 2018.01.26. 15:40, Colm O hEigeartaigh wrote:
>> OK so it appears the problems with the STS issuing the token have been
>> fixed? The errors are from the STSSamlAssertionValidator, which is supposed
>> to be used on the service side. It tries to validate the Signature locally
>> on the token, and if it fails it dispatches the token to the STS for
>> validation, which is why you're seeing an error about STSClient.
>>
>> What behaviour are you expecting on the service side? Normally the
>> STSSamlAssertionValidator
>> is not configured, because you have the CA cert of the STS in the service
>> keystore and it can validate the certificate locally. Is the STS cert (or
>> CA cert) in your crypto properties file pointing to by the
>> security.signature.properties configuration variable on the service side?
>>
>> Colm.
>>
>> On Fri, Jan 26, 2018 at 11:56 AM, Tóth Csaba <[hidden email]> wrote:
>>
>>> Hello!
>>> (Sorry for the wrong address)
>>>
>>> It's go forward with little steps.
>>> now I get this error:
>>> jan. 26, 2018 12:42:21 DU
>>> org.apache.cxf.ws.security.trust.STSSamlAssertionValidator
>>> verifySignedAssertion
>>> WARNING: Local trust verification of SAML assertion failed: Error during
>>> certificate path validation: No trusted certs found
>>> org.apache.wss4j.common.ext.WSSecurityException: Error during
>>> certificate path validation: No trusted certs found
>>>     at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:829)
>>>     at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:919)
>>>     at
>>> org.apache.wss4j.dom.validate.SignatureTrustValidator.verifyTrustInCerts(
>>> SignatureTrustValidator.java:109)
>>>     at
>>> org.apache.wss4j.dom.validate.SignatureTrustValidator.validate(
>>> SignatureTrustValidator.java:64)
>>>     at
>>> org.apache.wss4j.dom.validate.SamlAssertionValidator.
>>> verifySignedAssertion(SamlAssertionValidator.java:214)
>>>     at
>>> org.apache.cxf.ws.security.trust.STSSamlAssertionValidator.
>>> verifySignedAssertion(STSSamlAssertionValidator.java:68)
>>>
>>> I get the certification from the SAML, and put into the keystore what i
>>> already setup (and put under the WEB-INF/classes/key directory
>>>
>>> the strange thing, the next error come about:
>>> jan. 26, 2018 12:42:24 DU org.apache.cxf.phase.PhaseInterceptorChain
>>> doDefaultLogging
>>> WARNING: Interceptor for
>>> {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService
>>> has thrown exception, unwinding now
>>> org.apache.cxf.ws.security.trust.TrustException: The STSClient is not
>>> configured with either a location or wsdlLocation property
>>>     at
>>> org.apache.cxf.ws.security.trust.AbstractSTSClient.createClient(
>>> AbstractSTSClient.java:673)
>>>     at
>>> org.apache.cxf.ws.security.trust.AbstractSTSClient.
>>> validate(AbstractSTSClient.java:1101)
>>>     at
>>> org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken(
>>> STSClient.java:105)
>>>
>>> What STSClient? why want to create a client?
>>> in the cxf settings no "client" string is found
>>>
>>> Thanx
>>> Csaba
>>>
>>> On 2018.01.25. 15:48, Colm O hEigeartaigh wrote:
>>>> Please reply to the CXF mailing list and not me directly...the problem
>>>> is that the SAML Assertion is getting validated before it hits the
>>>> STS, so you need to make a reference to the signature properties as a
>>>> JAX-WS property of the endpoint. For example:
>>>>
>>>> https://github.com/apache/cxf/blob/6a3f97e9f0d02eef72bf10c266d444
>>> ec3af78bf5/services/sts/systests/basic/src/test/resources/org/apache/cxf/
>>> systest/sts/transport/cxf-service.xml#L44
>>>> On Thu, Jan 25, 2018 at 2:38 PM, Tóth Csaba <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>>     Hello!
>>>>     this is the full trace:
>>>>
>>>>     jan. 25, 2018 2:17:13 DU org.apache.cxf.phase.PhaseInterceptorChain
>>>>     doDefaultLogging
>>>>     WARNING: Interceptor for
>>>>     {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}
>>> SecurityTokenService
>>>>     <<a href="http://docs.oasis-open.org/ws-sx/ws-trust/200512/%">http://docs.oasis-open.org/ws-sx/ws-trust/200512/%
>>> 7DSecurityTokenService>
>>>>     has thrown exception, unwinding now
>>>>     org.apache.cxf.binding.soap.SoapFault: No crypto property file
>>>>     supplied
>>>>     for signature
>>>>         at
>>>>     org.apache.cxf.ws.security.wss4j.WSS4JUtils.
>>> createSoapFault(WSS4JUtils.java:236)
>>>>         at
>>>>     org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.
>>> handleMessageInternal(WSS4JInInterceptor.java:340)
>>>>         at
>>>>     org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(
>>> WSS4JInInterceptor.java:175)
>>>>         at
>>>>     org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.
>>> handleMessage(PolicyBasedWSS4JInInterceptor.java:79)
>>>>         at
>>>>     org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.
>>> handleMessage(PolicyBasedWSS4JInInterceptor.java:66)
>>>>         at
>>>>     org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
>>> PhaseInterceptorChain.java:308)
>>>>         at
>>>>     org.apache.cxf.transport.ChainInitiationObserver.onMessage(
>>> ChainInitiationObserver.java:121)
>>>>         at
>>>>     org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(
>>> AbstractHTTPDestination.java:267)
>>>>         at
>>>>     org.apache.cxf.transport.servlet.ServletController.
>>> invokeDestination(ServletController.java:234)
>>>>         at
>>>>     org.apache.cxf.transport.servlet.ServletController.
>>> invoke(ServletController.java:208)
>>>>         at
>>>>     org.apache.cxf.transport.servlet.ServletController.
>>> invoke(ServletController.java:160)
>>>>         at
>>>>     org.apache.cxf.transport.servlet.CXFNonSpringServlet.
>>> invoke(CXFNonSpringServlet.java:191)
>>>>         at
>>>>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(
>>> AbstractHTTPServlet.java:301)
>>>>         at
>>>>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.
>>> doPost(AbstractHTTPServlet.java:220)
>>>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:661)
>>>>         at
>>>>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.
>>> service(AbstractHTTPServlet.java:276)
>>>>         at
>>>>     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
>>> ApplicationFilterChain.java:231)
>>>>         at
>>>>     org.apache.catalina.core.ApplicationFilterChain.doFilter(
>>> ApplicationFilterChain.java:166)
>>>>         at
>>>>     org.apache.tomcat.websocket.server.WsFilter.doFilter(
>>> WsFilter.java:52)
>>>>         at
>>>>     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
>>> ApplicationFilterChain.java:193)
>>>>         at
>>>>     org.apache.catalina.core.ApplicationFilterChain.doFilter(
>>> ApplicationFilterChain.java:166)
>>>>         at
>>>>     org.apache.catalina.core.StandardWrapperValve.invoke(
>>> StandardWrapperValve.java:198)
>>>>         at
>>>>     org.apache.catalina.core.StandardContextValve.invoke(
>>> StandardContextValve.java:96)
>>>>         at
>>>>     org.apache.catalina.authenticator.AuthenticatorBase.invoke(
>>> AuthenticatorBase.java:504)
>>>>         at
>>>>     org.apache.catalina.core.StandardHostValve.invoke(
>>> StandardHostValve.java:140)
>>>>         at
>>>>     org.apache.catalina.valves.ErrorReportValve.invoke(
>>> ErrorReportValve.java:81)
>>>>         at
>>>>     org.apache.catalina.valves.AbstractAccessLogValve.invoke(
>>> AbstractAccessLogValve.java:650)
>>>>         at
>>>>     org.apache.catalina.core.StandardEngineValve.invoke(
>>> StandardEngineValve.java:87)
>>>>         at
>>>>     org.apache.catalina.connector.CoyoteAdapter.service(
>>> CoyoteAdapter.java:342)
>>>>         at
>>>>     org.apache.coyote.http11.Http11Processor.service(
>>> Http11Processor.java:803)
>>>>         at
>>>>     org.apache.coyote.AbstractProcessorLight.process(
>>> AbstractProcessorLight.java:66)
>>>>         at
>>>>     org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
>>> AbstractProtocol.java:790)
>>>>         at
>>>>     org.apache.tomcat.util.net
>>>>     <http://org.apache.tomcat.util.net>.NioEndpoint$
>>> SocketProcessor.doRun(NioEndpoint.java:1459)
>>>>         at
>>>>     org.apache.tomcat.util.net
>>>>     <http://org.apache.tomcat.util.net>.SocketProcessorBase.
>>> run(SocketProcessorBase.java:49)
>>>>         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
>>>>     Source)
>>>>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>>>>     Source)
>>>>         at
>>>>     org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
>>> TaskThread.java:61)
>>>>         at java.lang.Thread.run(Unknown Source)
>>>>
>>>>     Csaba
>>>>
>>>>     On 2018.01.25. 15 <tel:2018.01.25.%2015>:32, Colm O hEigeartaigh
>>>>     wrote:
>>>>     > What's the full stack-trace?
>>>>     >
>>>>     > On Thu, Jan 25, 2018 at 1:44 PM, Tóth Csaba <[hidden email]
>>>>     <mailto:[hidden email]>> wrote:
>>>>     >
>>>>     >> Hello!
>>>>     >> Yes, after I deleted it, its begin to parse the SAML.
>>>>     >> the next error is about the SigVerCrypto is empty at the
>>>>     >> SignatureTrustValidator.validate step.
>>>>     >>  (get from the RequestData.sigVerCrypto)
>>>>     >>
>>>>     >> I set up the thing:
>>>>     >>
>>>>     >> <bean id="cryptoProperties" class="java.util.Properties">
>>>>     >>     <constructor-arg>
>>>>     >>         <props>
>>>>     >>             <prop
>>>>     >> key="org.apache.ws.security.crypto.provider">org.apache.
>>>>     >> ws.security.components.crypto.Merlin</prop>
>>>>     >>             <prop
>>>>     >> key="org.apache.ws.security.crypto.merlin.keystore.type">
>>> jks</prop>
>>>>     >>             <prop
>>>>     >> key="org.apache.ws.security.crypto.merlin.keystore.password">
>>>>     .... </prop>
>>>>     >>             <prop
>>>>     >> key="org.apache.ws.security.crypto.merlin.file">key/key.
>>> jks</prop>
>>>>     >>         </props>
>>>>     >>     </constructor-arg>
>>>>     >> </bean>
>>>>     >>     <bean id="utSTSProperties"
>>>>     >> class="org.apache.cxf.sts.StaticSTSProperties">
>>>>     >>         <property name="SignatureCryptoProperties"
>>>>     >> ref="cryptoProperties"/>
>>>>     >>     ....
>>>>     >>     </bean>
>>>>     >>
>>>>     >> and put the keyfile under the WEB-INF/classes/key
>>>>     >> (in the keyfile the keys for signing the new SAML)
>>>>     >>
>>>>     >> Thanx
>>>>     >> Csaba
>>>>     >>
>>>>     >>
>>>>     >> On 2018.01.25. 13 <tel:2018.01.25.%2013>:40, Colm O
>>>>     hEigeartaigh wrote:
>>>>     >>> Do you mean that there was a "saml2p:Status" element in the
>>>>     security
>>>>     >> header
>>>>     >>> before the Assertion? If so then this is not valid, only the SAML
>>>>     >> Assertion
>>>>     >>> should be there.
>>>>     >>>
>>>>     >>> Colm.
>>>>     >>>
>>>>     >>> On Thu, Jan 25, 2018 at 8:47 AM, Tóth Csaba <[hidden email]
>>>>     <mailto:[hidden email]>> wrote:
>>>>     >>>
>>>>     >>>> Hello!
>>>>     >>>>
>>>>     >>>> I dig deeper in the code:
>>>>     >>>> The problem with the SAML was:
>>>>     >>>> In the securty element contains not only the SAML, its
>>>>     contains before
>>>>     >>>> the SAML an
>>>>     >>>> <saml2:Issuer> and an <saml2p:Status> element
>>>>     >>>> (in his case The same is not processed)
>>>>     >>>>
>>>>     >>>> If I delete it, its go thru the SAML validator
>>>>     >>>>
>>>>     >>>> Csaba
>>>>     >>>>
>>>>     >>>> On 2018.01.24. 19 <tel:2018.01.24.%2019>:25, Tóth Csaba wrote:
>>>>     >>>>> Hello!
>>>>     >>>>> Thanx. I changed the namespace, but not helped.
>>>>     >>>>>
>>>>     >>>>> The DefaultSubjectProvider cant retrieve the subject from
>>>>     this SAML:
>>>>     >>>>>
>>>>     >>>>> <saml2:Assertion ID="..." IssueInstant="..." Version="2.0"
>>>>     >>>>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
>>>>     >>>>>
>>>>     >>>>>     <saml2:Subject>
>>>>     >>>>>         <saml2:NameID
>>>>     >>>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:
>>>>     >>>> persistent">[name]</saml2:NameID>
>>>>     >>>>>         <saml2:SubjectConfirmation
>>>>     >>>>> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
>>>>     >>>>>             <saml2:SubjectConfirmationData
>>>>     >>>>> InResponseTo="_9c7644ce0fb93649cd2ca77bb9b5e6db22f68b52a9"
>>>>     >>>>> NotOnOrAfter="2018-01-24T18:06:33.305Z"/>
>>>>     >>>>>         </saml2:SubjectConfirmation>
>>>>     >>>>>     </saml2:Subject>
>>>>     >>>>>
>>>>     >>>>> </saml2:Assertion>
>>>>     >>>>>
>>>>     >>>>> But I get an error, because the subject is null
>>>>     >>>>> (At this point I cant change the SAML in the request)
>>>>     >>>>>
>>>>     >>>>> Thanx
>>>>     >>>>>
>>>>     >>>>> Csaba
>>>>     >>>>>
>>>>     >>>>> On 2018.01.24. 10:55, Colm O hEigeartaigh wrote:
>>>>     >>>>>> The problem I think is that "http://schemas.xmlsoap.org/
>>>>     >>>> ws/2003/06/secext"
>>>>     >>>>>> is not a standard WS-Security namespace, and hence CXF is not
>>>>     >> processing
>>>>     >>>>>> the message header at all. The correct WS-Security
>>>>     namespace for the
>>>>     >>>>>> security header is instead "
>>>>     >>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
>>>>     <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss->
>>>>     >>>> wssecurity-secext-1.0.xsd
>>>>     >>>>>> ".
>>>>     >>>>>>
>>>>     >>>>>> You could take a look at the CXF transformation feature to
>>>>     transform
>>>>     >> the
>>>>     >>>>>> namespace into the correct version (no idea if this will
>>>>     work or not):
>>>>     >>>>>>
>>>>     >>>>>> http://cxf.apache.org/docs/transformationfeature.html
>>>>     <http://cxf.apache.org/docs/transformationfeature.html>
>>>>     >>>>>>
>>>>     >>>>>> Colm.
>>>>     >>>>>>
>>>>     >>>>>>
>>>>     >>>>>> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[hidden email]
>>>>     <mailto:[hidden email]>> wrote:
>>>>     >>>>>>
>>>>     >>>>>>> Hello!
>>>>     >>>>>>> Its in the header:
>>>>     >>>>>>> ------------
>>>>     >>>>>>> <soapenv:Envelope
>>>>     >>>>>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/
>>>>     <http://schemas.xmlsoap.org/soap/envelope/>"
>>>>     >>>>>>> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512
>>>>     <http://docs.oasis-open.org/ws-sx/ws-trust/200512>"
>>>>     >>>>>>> xmlns:a="http://www.w3.org/2005/08/addressing
>>>>     <http://www.w3.org/2005/08/addressing>">
>>>>     >>>>>>>    <soapenv:Header>
>>>>     >>>>>>>   <wsse:Security xmlns:wsse="http://schemas.
>>>>     >>>> xmlsoap.org/ws/2003/06/secext
>>>>     <http://xmlsoap.org/ws/2003/06/secext>"
>>>>     >>>>>>>     <saml:Assertion xmlns:saml="urn:oasis:names:
>>>>     >> tc:SAML:2.0:assertion"
>>>>     >>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
>>>>     <http://www.w3.org/2001/XMLSchema-instance>"
>>>>     >>>>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema
>>>>     <http://www.w3.org/2001/XMLSchema>"
>>>>     >>>>>>> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0"
>>>>     >>>>>>> IssueInstant="2014-07-17T01:01:48Z">
>>>>     >>>>>>>
>>>>     >>>>>>>   [assertion]
>>>>     >>>>>>>
>>>>     >>>>>>>   </saml:Assertion>
>>>>     >>>>>>>
>>>>     >>>>>>>   </wsse:Security>
>>>>     >>>>>>>   </soapenv:Header>
>>>>     >>>>>>>  <soapenv:Body>
>>>>     >>>>>>>       <ns:RequestSecurityToken >
>>>>     >>>>>>>
>>>>     >>>>>>> <ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/
>>>>     <http://docs.oasis-open.org/ws-sx/ws-trust/>
>>>>     >> 200512/Issue
>>>>     >>>>>>> </ns:RequestType>
>>>>     >>>>>>>
>>>>     >>>>>>> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-
>>>>     <http://docs.oasis-open.org/wss/oasis-wss->
>>>>     >>>>>>> saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
>>>>     >>>>>>>   <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy
>>>>     <http://www.w3.org/ns/ws-policy>">  [url]
>>>>     >>>>>>> </ns7:AppliesTo>
>>>>     >>>>>>>   <!--
>>>>     >>>>>>>    <ns:Claims Dialect="http://bag.admin.ch/
>>>>     >> epr/2017/annex/5/addendum/2
>>>>     >>>> ">
>>>>     >>>>>>> [claims need to process too ]
>>>>     >>>>>>>
>>>>     >>>>>>>  </ns:Claims>
>>>>     >>>>>>> -->
>>>>     >>>>>>>  </ns:RequestSecurityToken>
>>>>     >>>>>>>  </soapenv:Body>
>>>>     >>>>>>> </soapenv:Envelope>
>>>>     >>>>>>> ---------------------
>>>>     >>>>>>>
>>>>     >>>>>>> Its look like easy task for the first look:
>>>>     >>>>>>> get a SAML in the header, full of attributes, and a
>>>>     request with
>>>>     >> other
>>>>     >>>>>>> attributes.
>>>>     >>>>>>> Validate some attributes, and all header attributes + claims
>>>>     >> attributes
>>>>     >>>>>>> put the new SAML token.
>>>>     >>>>>>>
>>>>     >>>>>>> but, about a week long, I google, read source code, google
>>>>     again, and
>>>>     >>>>>>> try to config the thing.
>>>>     >>>>>>> no good tutorial, no good documentation, no good
>>>>     description :(
>>>>     >>>>>>>
>>>>     >>>>>>> Csaba
>>>>     >>>>>>>
>>>>     >>>>>>>
>>>>     >>>>>>>
>>>>     >>>>>>> On 2018.01.23. 18 <tel:2018.01.23.%2018>:08, Colm O
>>>>     hEigeartaigh wrote:
>>>>     >>>>>>>> What does the request look like, e.g. where is the SAML
>>>>     token in the
>>>>     >>>>>>>> request? Is it referred to directly in the SOAP Body?
>>>>     >>>>>>>>
>>>>     >>>>>>>> Colm.
>>>>     >>>>>>>>
>>>>     >>>>>>>> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba
>>>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>>>     >>>>>>>>
>>>>     >>>>>>>>> Hello!
>>>>     >>>>>>>>>
>>>>     >>>>>>>>> I'd like to parse the incomming SAML token to get the
>>>>     fields (user,
>>>>     >>>> etc)
>>>>     >>>>>>>>> and give it to the issuer.
>>>>     >>>>>>>>> I found, that is done in the
>>>>     >>>>>>>>> org.apache.cxf.sts.operation.TokenIssueOperation class but
>>>>     >>>>>>>>> stsProperties.getSamlRealmCodec() is always null in my
>>>>     code (how
>>>>     >>>> can i
>>>>     >>>>>>>>> set it, need to create a new one?)
>>>>     >>>>>>>>> but after in the fetchSAMLAssertionFromWSSecuri
>>> tySAMLToken()
>>>>     >>>> function
>>>>     >>>>>>>>> List<WSSecurityEngineResult> engineResults =
>>>>     >>>> handlerResult.getResults();
>>>>     >>>>>>>>> line give back an empty list.
>>>>     >>>>>>>>>
>>>>     >>>>>>>>> In the request there is an SAML token.
>>>>     >>>>>>>>>
>>>>     >>>>>>>>> I try to find some solution, but every example is
>>>>     working with the
>>>>     >>>>>>>>> usernametoken, and/or dont provide a valid cxf config xml.
>>>>     >>>>>>>>>
>>>>     >>>>>>>>> Thanx
>>>>     >>>>>>>>> Csaba
>>>>     >>>>>>>>>
>>>>     >>>>>>>>>
>>>>     >>
>>>>     >
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Colm O hEigeartaigh
>>>>
>>>> Talend Community Coder
>>>> http://coders.talend.com
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Parse the incomming SAML token at server side

coheigea
Administrator
It's great that it's working for you, but the STS endpoint should not have
a "ws-security.saml2.validator" pointing to the STSTokenValidator. The
STSTokenValidator is used by a service to send a received SAML token off to
an STS for validation. In your case, the validation is done locally, so you
shouldn't need to specify "ws-security.saml2.validator" at all.

Colm.

On Sun, Jan 28, 2018 at 8:59 AM, Tóth Csaba <[hidden email]> wrote:

> Hello!
> Its SOLVED!
>
> there were multiple errors:
> - typo in the keystore filename,
> - the Cryptoproperties must be in a property file, what need to put
> under WEB-INF/classes/
> - the SignatureUsername is the alias in the keystore
> - must be a password callback handler for the password to the private
> key (and its hard to config thru the config files)
>
> thanx
> Csaba
>
> On 2018.01.26. 18:49, Tóth Csaba wrote:
> > Hello!
> > I'm now very confused:
> >
> > I have this config file:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <beans xmlns="http://www.springframework.org/schema/beans"
> >     xmlns:cxf="http://cxf.apache.org/core"
> >     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >     xmlns:sec="http://cxf.apache.org/configuration/security"
> >     xmlns:http="http://cxf.apache.org/transports/http/configuration"
> >     xmlns:httpj="http://cxf.apache.org/transports/http-
> jetty/configuration"
> >     xmlns:jaxws="http://cxf.apache.org/jaxws"
> >     xmlns:util="http://www.springframework.org/schema/util"
> >     xmlns:soap="http://cxf.apache.org/bindings/soap"
> >     xsi:schemaLocation="http://cxf.apache.org/core
> > http://cxf.apache.org/schemas/core.xsd
> > http://cxf.apache.org/configuration/security
> > http://cxf.apache.org/schemas/configuration/security.xsd
> > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
> > http://cxf.apache.org/transports/http/configuration
> > http://cxf.apache.org/schemas/configuration/http-conf.xsd
> > http://cxf.apache.org/transports/http-jetty/configuration
> > http://cxf.apache.org/schemas/configuration/http-jetty.xsd
> > http://www.springframework.org/schema/beans
> > http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
> > http://www.springframework.org/schema/util
> > http://www.springframework.org/schema/util/spring-util-4.2.xsd
> > http://cxf.apache.org/bindings/soap
> > http://cxf.apache.org/schemas/configuration/soap.xsd">
> >
> >     <bean id="defaultTokenStore"
> > class="org.apache.cxf.sts.cache.DefaultInMemoryTokenStore">
> >         </bean>
> > <bean id="cryptoProperties" class="java.util.Properties">
> >     <constructor-arg>
> >         <props>
> >             <prop
> > key="org.apache.ws.security.crypto.provider">org.apache.
> ws.security.components.crypto.Merlin</prop>
> >             <prop
> > key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop>
> >             <prop
> > key="org.apache.ws.security.crypto.merlin.keystore.
> password">.....</prop>
> >             <prop
> > key="org.apache.ws.security.crypto.merlin.file">key/key.jks</prop>
> >         </props>
> >     </constructor-arg>
> > </bean>
> >
> >     <bean id="utSTSProperties"
> > class="org.apache.cxf.sts.StaticSTSProperties">
> >         <property name="SignatureCryptoProperties"
> ref="cryptoProperties"/>
> >         <property name="issuer" value="issuer"/>
> >         <property name="signatureUsername" value="signature"/>
> >     </bean>
> >
> >     <bean id="utService" class="org.apache.cxf.sts.
> service.StaticService">
> >         <property name="endpoints" value="http://localhost: xxxx
> > /services/SecurityTokenServiceProvider" />
> >     </bean>
> >
> >      <bean id="utSCTSamlTokenProvider"
> > class="org.apache.cxf.sts.token.provider.SAMLTokenProvider">
> >      </bean>
> >
> >     <util:list id="utTokenProviders">
> >         <ref bean="utSCTSamlTokenProvider"/>
> >     </util:list>
> >
> >     <bean id="utIssueDelegate" class=" package .TokenIssueOperation">
> >         <property name="tokenProviders" ref="utTokenProviders"/>
> >                  <property name="services" ref="utService" />
> >         <property name="stsProperties" ref="utSTSProperties" />
> >         <property name="tokenStore" ref="defaultTokenStore"/>
> >     </bean>
> >
> >     <bean id="utSTSProviderBean" class=" package
> > .SecurityTokenServiceProvider">
> >         <property name="issueOperation" ref="utIssueDelegate" />
> >     </bean>
> >     <!--
> >     <bean id="utSTSProviderBean"
> > class="org.apache.cxf.ws.security.sts.provider.
> SecurityTokenServiceProvider">
> >         <property name="issueOperation" ref="utIssueDelegate" />
> >     </bean>
> >     -->
> >
> >     <jaxws:endpoint
> > xmlns:tns="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"
> >         id="securitytokenserviceprovider" implementor="#
> utSTSProviderBean"
> >         wsdlLocation="WEB-INF/wsdl/ws-trust-1.4-service.wsdl"
> > endpointName="tns:UT_Port"
> >         serviceName="tns:SecurityTokenService"
> > address="/SecurityTokenServiceProvider">
> >         <jaxws:properties>
> >
> >             <entry key="security.return.security.error" value="true" />
> >             <entry key="security.validate.audience-restriction"
> > value="false" />
> >             <entry key="security.signature.properties">
> >                 <bean id="signatureCryptoProperties"
> > class="java.util.Properties">
> >                     <constructor-arg>
> >                         <props>
> >              <prop
> > key="org.apache.ws.security.crypto.provider">org.apache.
> ws.security.components.crypto.Merlin</prop>
> >             <prop
> > key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop>
> >             <prop
> > key="org.apache.ws.security.crypto.merlin.keystore.
> password">.....</prop>
> >             <prop
> > key="org.apache.ws.security.crypto.merlin.file">key/key.jks</prop>
> >                         </props>
> >                     </constructor-arg>
> >                 </bean>
> >             </entry>
> >             <entry key="ws-security.saml2.validator">
> >                 <bean
> > class="org.apache.cxf.ws.security.trust.STSTokenValidator"/>
> >             </entry>
> >         </jaxws:properties>
> >         <jaxws:binding>
> >             <soap:soapBinding mtomEnabled="true" version="1.2" />
> >         </jaxws:binding>
> >     </jaxws:endpoint>
> > </beans>
> >
> > the keystore is under WEB-INF, it cointains the cert from the incomming
> > Cert.
> >
> > all help thanks.
> >
> > Csaba
> >
> > On 2018.01.26. 15:40, Colm O hEigeartaigh wrote:
> >> OK so it appears the problems with the STS issuing the token have been
> >> fixed? The errors are from the STSSamlAssertionValidator, which is
> supposed
> >> to be used on the service side. It tries to validate the Signature
> locally
> >> on the token, and if it fails it dispatches the token to the STS for
> >> validation, which is why you're seeing an error about STSClient.
> >>
> >> What behaviour are you expecting on the service side? Normally the
> >> STSSamlAssertionValidator
> >> is not configured, because you have the CA cert of the STS in the
> service
> >> keystore and it can validate the certificate locally. Is the STS cert
> (or
> >> CA cert) in your crypto properties file pointing to by the
> >> security.signature.properties configuration variable on the service
> side?
> >>
> >> Colm.
> >>
> >> On Fri, Jan 26, 2018 at 11:56 AM, Tóth Csaba <[hidden email]> wrote:
> >>
> >>> Hello!
> >>> (Sorry for the wrong address)
> >>>
> >>> It's go forward with little steps.
> >>> now I get this error:
> >>> jan. 26, 2018 12:42:21 DU
> >>> org.apache.cxf.ws.security.trust.STSSamlAssertionValidator
> >>> verifySignedAssertion
> >>> WARNING: Local trust verification of SAML assertion failed: Error
> during
> >>> certificate path validation: No trusted certs found
> >>> org.apache.wss4j.common.ext.WSSecurityException: Error during
> >>> certificate path validation: No trusted certs found
> >>>     at org.apache.wss4j.common.crypto.Merlin.verifyTrust(
> Merlin.java:829)
> >>>     at org.apache.wss4j.common.crypto.Merlin.verifyTrust(
> Merlin.java:919)
> >>>     at
> >>> org.apache.wss4j.dom.validate.SignatureTrustValidator.
> verifyTrustInCerts(
> >>> SignatureTrustValidator.java:109)
> >>>     at
> >>> org.apache.wss4j.dom.validate.SignatureTrustValidator.validate(
> >>> SignatureTrustValidator.java:64)
> >>>     at
> >>> org.apache.wss4j.dom.validate.SamlAssertionValidator.
> >>> verifySignedAssertion(SamlAssertionValidator.java:214)
> >>>     at
> >>> org.apache.cxf.ws.security.trust.STSSamlAssertionValidator.
> >>> verifySignedAssertion(STSSamlAssertionValidator.java:68)
> >>>
> >>> I get the certification from the SAML, and put into the keystore what i
> >>> already setup (and put under the WEB-INF/classes/key directory
> >>>
> >>> the strange thing, the next error come about:
> >>> jan. 26, 2018 12:42:24 DU org.apache.cxf.phase.PhaseInterceptorChain
> >>> doDefaultLogging
> >>> WARNING: Interceptor for
> >>> {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}
> SecurityTokenService
> >>> has thrown exception, unwinding now
> >>> org.apache.cxf.ws.security.trust.TrustException: The STSClient is not
> >>> configured with either a location or wsdlLocation property
> >>>     at
> >>> org.apache.cxf.ws.security.trust.AbstractSTSClient.createClient(
> >>> AbstractSTSClient.java:673)
> >>>     at
> >>> org.apache.cxf.ws.security.trust.AbstractSTSClient.
> >>> validate(AbstractSTSClient.java:1101)
> >>>     at
> >>> org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken(
> >>> STSClient.java:105)
> >>>
> >>> What STSClient? why want to create a client?
> >>> in the cxf settings no "client" string is found
> >>>
> >>> Thanx
> >>> Csaba
> >>>
> >>> On 2018.01.25. 15:48, Colm O hEigeartaigh wrote:
> >>>> Please reply to the CXF mailing list and not me directly...the problem
> >>>> is that the SAML Assertion is getting validated before it hits the
> >>>> STS, so you need to make a reference to the signature properties as a
> >>>> JAX-WS property of the endpoint. For example:
> >>>>
> >>>> https://github.com/apache/cxf/blob/6a3f97e9f0d02eef72bf10c266d444
> >>> ec3af78bf5/services/sts/systests/basic/src/test/
> resources/org/apache/cxf/
> >>> systest/sts/transport/cxf-service.xml#L44
> >>>> On Thu, Jan 25, 2018 at 2:38 PM, Tóth Csaba <[hidden email]
> >>>> <mailto:[hidden email]>> wrote:
> >>>>
> >>>>     Hello!
> >>>>     this is the full trace:
> >>>>
> >>>>     jan. 25, 2018 2:17:13 DU org.apache.cxf.phase.
> PhaseInterceptorChain
> >>>>     doDefaultLogging
> >>>>     WARNING: Interceptor for
> >>>>     {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}
> >>> SecurityTokenService
> >>>>     <<a href="http://docs.oasis-open.org/ws-sx/ws-trust/200512/%">http://docs.oasis-open.org/ws-sx/ws-trust/200512/%
> >>> 7DSecurityTokenService>
> >>>>     has thrown exception, unwinding now
> >>>>     org.apache.cxf.binding.soap.SoapFault: No crypto property file
> >>>>     supplied
> >>>>     for signature
> >>>>         at
> >>>>     org.apache.cxf.ws.security.wss4j.WSS4JUtils.
> >>> createSoapFault(WSS4JUtils.java:236)
> >>>>         at
> >>>>     org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.
> >>> handleMessageInternal(WSS4JInInterceptor.java:340)
> >>>>         at
> >>>>     org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.
> handleMessage(
> >>> WSS4JInInterceptor.java:175)
> >>>>         at
> >>>>     org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.
> >>> handleMessage(PolicyBasedWSS4JInInterceptor.java:79)
> >>>>         at
> >>>>     org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.
> >>> handleMessage(PolicyBasedWSS4JInInterceptor.java:66)
> >>>>         at
> >>>>     org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> >>> PhaseInterceptorChain.java:308)
> >>>>         at
> >>>>     org.apache.cxf.transport.ChainInitiationObserver.onMessage(
> >>> ChainInitiationObserver.java:121)
> >>>>         at
> >>>>     org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(
> >>> AbstractHTTPDestination.java:267)
> >>>>         at
> >>>>     org.apache.cxf.transport.servlet.ServletController.
> >>> invokeDestination(ServletController.java:234)
> >>>>         at
> >>>>     org.apache.cxf.transport.servlet.ServletController.
> >>> invoke(ServletController.java:208)
> >>>>         at
> >>>>     org.apache.cxf.transport.servlet.ServletController.
> >>> invoke(ServletController.java:160)
> >>>>         at
> >>>>     org.apache.cxf.transport.servlet.CXFNonSpringServlet.
> >>> invoke(CXFNonSpringServlet.java:191)
> >>>>         at
> >>>>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> handleRequest(
> >>> AbstractHTTPServlet.java:301)
> >>>>         at
> >>>>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> >>> doPost(AbstractHTTPServlet.java:220)
> >>>>         at javax.servlet.http.HttpServlet.service(
> HttpServlet.java:661)
> >>>>         at
> >>>>     org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> >>> service(AbstractHTTPServlet.java:276)
> >>>>         at
> >>>>     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> >>> ApplicationFilterChain.java:231)
> >>>>         at
> >>>>     org.apache.catalina.core.ApplicationFilterChain.doFilter(
> >>> ApplicationFilterChain.java:166)
> >>>>         at
> >>>>     org.apache.tomcat.websocket.server.WsFilter.doFilter(
> >>> WsFilter.java:52)
> >>>>         at
> >>>>     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> >>> ApplicationFilterChain.java:193)
> >>>>         at
> >>>>     org.apache.catalina.core.ApplicationFilterChain.doFilter(
> >>> ApplicationFilterChain.java:166)
> >>>>         at
> >>>>     org.apache.catalina.core.StandardWrapperValve.invoke(
> >>> StandardWrapperValve.java:198)
> >>>>         at
> >>>>     org.apache.catalina.core.StandardContextValve.invoke(
> >>> StandardContextValve.java:96)
> >>>>         at
> >>>>     org.apache.catalina.authenticator.AuthenticatorBase.invoke(
> >>> AuthenticatorBase.java:504)
> >>>>         at
> >>>>     org.apache.catalina.core.StandardHostValve.invoke(
> >>> StandardHostValve.java:140)
> >>>>         at
> >>>>     org.apache.catalina.valves.ErrorReportValve.invoke(
> >>> ErrorReportValve.java:81)
> >>>>         at
> >>>>     org.apache.catalina.valves.AbstractAccessLogValve.invoke(
> >>> AbstractAccessLogValve.java:650)
> >>>>         at
> >>>>     org.apache.catalina.core.StandardEngineValve.invoke(
> >>> StandardEngineValve.java:87)
> >>>>         at
> >>>>     org.apache.catalina.connector.CoyoteAdapter.service(
> >>> CoyoteAdapter.java:342)
> >>>>         at
> >>>>     org.apache.coyote.http11.Http11Processor.service(
> >>> Http11Processor.java:803)
> >>>>         at
> >>>>     org.apache.coyote.AbstractProcessorLight.process(
> >>> AbstractProcessorLight.java:66)
> >>>>         at
> >>>>     org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
> >>> AbstractProtocol.java:790)
> >>>>         at
> >>>>     org.apache.tomcat.util.net
> >>>>     <http://org.apache.tomcat.util.net>.NioEndpoint$
> >>> SocketProcessor.doRun(NioEndpoint.java:1459)
> >>>>         at
> >>>>     org.apache.tomcat.util.net
> >>>>     <http://org.apache.tomcat.util.net>.SocketProcessorBase.
> >>> run(SocketProcessorBase.java:49)
> >>>>         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> >>>>     Source)
> >>>>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> >>>>     Source)
> >>>>         at
> >>>>     org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
> >>> TaskThread.java:61)
> >>>>         at java.lang.Thread.run(Unknown Source)
> >>>>
> >>>>     Csaba
> >>>>
> >>>>     On 2018.01.25. 15 <tel:2018.01.25.%2015>:32, Colm O hEigeartaigh
> >>>>     wrote:
> >>>>     > What's the full stack-trace?
> >>>>     >
> >>>>     > On Thu, Jan 25, 2018 at 1:44 PM, Tóth Csaba <[hidden email]
> >>>>     <mailto:[hidden email]>> wrote:
> >>>>     >
> >>>>     >> Hello!
> >>>>     >> Yes, after I deleted it, its begin to parse the SAML.
> >>>>     >> the next error is about the SigVerCrypto is empty at the
> >>>>     >> SignatureTrustValidator.validate step.
> >>>>     >>  (get from the RequestData.sigVerCrypto)
> >>>>     >>
> >>>>     >> I set up the thing:
> >>>>     >>
> >>>>     >> <bean id="cryptoProperties" class="java.util.Properties">
> >>>>     >>     <constructor-arg>
> >>>>     >>         <props>
> >>>>     >>             <prop
> >>>>     >> key="org.apache.ws.security.crypto.provider">org.apache.
> >>>>     >> ws.security.components.crypto.Merlin</prop>
> >>>>     >>             <prop
> >>>>     >> key="org.apache.ws.security.crypto.merlin.keystore.type">
> >>> jks</prop>
> >>>>     >>             <prop
> >>>>     >> key="org.apache.ws.security.crypto.merlin.keystore.password">
> >>>>     .... </prop>
> >>>>     >>             <prop
> >>>>     >> key="org.apache.ws.security.crypto.merlin.file">key/key.
> >>> jks</prop>
> >>>>     >>         </props>
> >>>>     >>     </constructor-arg>
> >>>>     >> </bean>
> >>>>     >>     <bean id="utSTSProperties"
> >>>>     >> class="org.apache.cxf.sts.StaticSTSProperties">
> >>>>     >>         <property name="SignatureCryptoProperties"
> >>>>     >> ref="cryptoProperties"/>
> >>>>     >>     ....
> >>>>     >>     </bean>
> >>>>     >>
> >>>>     >> and put the keyfile under the WEB-INF/classes/key
> >>>>     >> (in the keyfile the keys for signing the new SAML)
> >>>>     >>
> >>>>     >> Thanx
> >>>>     >> Csaba
> >>>>     >>
> >>>>     >>
> >>>>     >> On 2018.01.25. 13 <tel:2018.01.25.%2013>:40, Colm O
> >>>>     hEigeartaigh wrote:
> >>>>     >>> Do you mean that there was a "saml2p:Status" element in the
> >>>>     security
> >>>>     >> header
> >>>>     >>> before the Assertion? If so then this is not valid, only the
> SAML
> >>>>     >> Assertion
> >>>>     >>> should be there.
> >>>>     >>>
> >>>>     >>> Colm.
> >>>>     >>>
> >>>>     >>> On Thu, Jan 25, 2018 at 8:47 AM, Tóth Csaba <[hidden email]
> >>>>     <mailto:[hidden email]>> wrote:
> >>>>     >>>
> >>>>     >>>> Hello!
> >>>>     >>>>
> >>>>     >>>> I dig deeper in the code:
> >>>>     >>>> The problem with the SAML was:
> >>>>     >>>> In the securty element contains not only the SAML, its
> >>>>     contains before
> >>>>     >>>> the SAML an
> >>>>     >>>> <saml2:Issuer> and an <saml2p:Status> element
> >>>>     >>>> (in his case The same is not processed)
> >>>>     >>>>
> >>>>     >>>> If I delete it, its go thru the SAML validator
> >>>>     >>>>
> >>>>     >>>> Csaba
> >>>>     >>>>
> >>>>     >>>> On 2018.01.24. 19 <tel:2018.01.24.%2019>:25, Tóth Csaba
> wrote:
> >>>>     >>>>> Hello!
> >>>>     >>>>> Thanx. I changed the namespace, but not helped.
> >>>>     >>>>>
> >>>>     >>>>> The DefaultSubjectProvider cant retrieve the subject from
> >>>>     this SAML:
> >>>>     >>>>>
> >>>>     >>>>> <saml2:Assertion ID="..." IssueInstant="..." Version="2.0"
> >>>>     >>>>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
> >>>>     >>>>>
> >>>>     >>>>>     <saml2:Subject>
> >>>>     >>>>>         <saml2:NameID
> >>>>     >>>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:
> >>>>     >>>> persistent">[name]</saml2:NameID>
> >>>>     >>>>>         <saml2:SubjectConfirmation
> >>>>     >>>>> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
> >>>>     >>>>>             <saml2:SubjectConfirmationData
> >>>>     >>>>> InResponseTo="_9c7644ce0fb93649cd2ca77bb9b5e6db22f68b52a9"
> >>>>     >>>>> NotOnOrAfter="2018-01-24T18:06:33.305Z"/>
> >>>>     >>>>>         </saml2:SubjectConfirmation>
> >>>>     >>>>>     </saml2:Subject>
> >>>>     >>>>>
> >>>>     >>>>> </saml2:Assertion>
> >>>>     >>>>>
> >>>>     >>>>> But I get an error, because the subject is null
> >>>>     >>>>> (At this point I cant change the SAML in the request)
> >>>>     >>>>>
> >>>>     >>>>> Thanx
> >>>>     >>>>>
> >>>>     >>>>> Csaba
> >>>>     >>>>>
> >>>>     >>>>> On 2018.01.24. 10:55, Colm O hEigeartaigh wrote:
> >>>>     >>>>>> The problem I think is that "http://schemas.xmlsoap.org/
> >>>>     >>>> ws/2003/06/secext"
> >>>>     >>>>>> is not a standard WS-Security namespace, and hence CXF is
> not
> >>>>     >> processing
> >>>>     >>>>>> the message header at all. The correct WS-Security
> >>>>     namespace for the
> >>>>     >>>>>> security header is instead "
> >>>>     >>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
> >>>>     <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss->
> >>>>     >>>> wssecurity-secext-1.0.xsd
> >>>>     >>>>>> ".
> >>>>     >>>>>>
> >>>>     >>>>>> You could take a look at the CXF transformation feature to
> >>>>     transform
> >>>>     >> the
> >>>>     >>>>>> namespace into the correct version (no idea if this will
> >>>>     work or not):
> >>>>     >>>>>>
> >>>>     >>>>>> http://cxf.apache.org/docs/transformationfeature.html
> >>>>     <http://cxf.apache.org/docs/transformationfeature.html>
> >>>>     >>>>>>
> >>>>     >>>>>> Colm.
> >>>>     >>>>>>
> >>>>     >>>>>>
> >>>>     >>>>>> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <
> [hidden email]
> >>>>     <mailto:[hidden email]>> wrote:
> >>>>     >>>>>>
> >>>>     >>>>>>> Hello!
> >>>>     >>>>>>> Its in the header:
> >>>>     >>>>>>> ------------
> >>>>     >>>>>>> <soapenv:Envelope
> >>>>     >>>>>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/
> >>>>     <http://schemas.xmlsoap.org/soap/envelope/>"
> >>>>     >>>>>>> xmlns:ns="http://docs.oasis-
> open.org/ws-sx/ws-trust/200512
> >>>>     <http://docs.oasis-open.org/ws-sx/ws-trust/200512>"
> >>>>     >>>>>>> xmlns:a="http://www.w3.org/2005/08/addressing
> >>>>     <http://www.w3.org/2005/08/addressing>">
> >>>>     >>>>>>>    <soapenv:Header>
> >>>>     >>>>>>>   <wsse:Security xmlns:wsse="http://schemas.
> >>>>     >>>> xmlsoap.org/ws/2003/06/secext
> >>>>     <http://xmlsoap.org/ws/2003/06/secext>"
> >>>>     >>>>>>>     <saml:Assertion xmlns:saml="urn:oasis:names:
> >>>>     >> tc:SAML:2.0:assertion"
> >>>>     >>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
> >>>>     <http://www.w3.org/2001/XMLSchema-instance>"
> >>>>     >>>>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema
> >>>>     <http://www.w3.org/2001/XMLSchema>"
> >>>>     >>>>>>> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc"
> Version="2.0"
> >>>>     >>>>>>> IssueInstant="2014-07-17T01:01:48Z">
> >>>>     >>>>>>>
> >>>>     >>>>>>>   [assertion]
> >>>>     >>>>>>>
> >>>>     >>>>>>>   </saml:Assertion>
> >>>>     >>>>>>>
> >>>>     >>>>>>>   </wsse:Security>
> >>>>     >>>>>>>   </soapenv:Header>
> >>>>     >>>>>>>  <soapenv:Body>
> >>>>     >>>>>>>       <ns:RequestSecurityToken >
> >>>>     >>>>>>>
> >>>>     >>>>>>> <ns:RequestType>http://docs.
> oasis-open.org/ws-sx/ws-trust/
> >>>>     <http://docs.oasis-open.org/ws-sx/ws-trust/>
> >>>>     >> 200512/Issue
> >>>>     >>>>>>> </ns:RequestType>
> >>>>     >>>>>>>
> >>>>     >>>>>>> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss-
> >>>>     <http://docs.oasis-open.org/wss/oasis-wss->
> >>>>     >>>>>>> saml-token-profile-1.1#SAMLV2.0</ns:TokenType>
> >>>>     >>>>>>>   <ns7:AppliesTo xmlns:ns7="http://www.w3.org/
> ns/ws-policy
> >>>>     <http://www.w3.org/ns/ws-policy>">  [url]
> >>>>     >>>>>>> </ns7:AppliesTo>
> >>>>     >>>>>>>   <!--
> >>>>     >>>>>>>    <ns:Claims Dialect="http://bag.admin.ch/
> >>>>     >> epr/2017/annex/5/addendum/2
> >>>>     >>>> ">
> >>>>     >>>>>>> [claims need to process too ]
> >>>>     >>>>>>>
> >>>>     >>>>>>>  </ns:Claims>
> >>>>     >>>>>>> -->
> >>>>     >>>>>>>  </ns:RequestSecurityToken>
> >>>>     >>>>>>>  </soapenv:Body>
> >>>>     >>>>>>> </soapenv:Envelope>
> >>>>     >>>>>>> ---------------------
> >>>>     >>>>>>>
> >>>>     >>>>>>> Its look like easy task for the first look:
> >>>>     >>>>>>> get a SAML in the header, full of attributes, and a
> >>>>     request with
> >>>>     >> other
> >>>>     >>>>>>> attributes.
> >>>>     >>>>>>> Validate some attributes, and all header attributes +
> claims
> >>>>     >> attributes
> >>>>     >>>>>>> put the new SAML token.
> >>>>     >>>>>>>
> >>>>     >>>>>>> but, about a week long, I google, read source code, google
> >>>>     again, and
> >>>>     >>>>>>> try to config the thing.
> >>>>     >>>>>>> no good tutorial, no good documentation, no good
> >>>>     description :(
> >>>>     >>>>>>>
> >>>>     >>>>>>> Csaba
> >>>>     >>>>>>>
> >>>>     >>>>>>>
> >>>>     >>>>>>>
> >>>>     >>>>>>> On 2018.01.23. 18 <tel:2018.01.23.%2018>:08, Colm O
> >>>>     hEigeartaigh wrote:
> >>>>     >>>>>>>> What does the request look like, e.g. where is the SAML
> >>>>     token in the
> >>>>     >>>>>>>> request? Is it referred to directly in the SOAP Body?
> >>>>     >>>>>>>>
> >>>>     >>>>>>>> Colm.
> >>>>     >>>>>>>>
> >>>>     >>>>>>>> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba
> >>>>     <[hidden email] <mailto:[hidden email]>> wrote:
> >>>>     >>>>>>>>
> >>>>     >>>>>>>>> Hello!
> >>>>     >>>>>>>>>
> >>>>     >>>>>>>>> I'd like to parse the incomming SAML token to get the
> >>>>     fields (user,
> >>>>     >>>> etc)
> >>>>     >>>>>>>>> and give it to the issuer.
> >>>>     >>>>>>>>> I found, that is done in the
> >>>>     >>>>>>>>> org.apache.cxf.sts.operation.TokenIssueOperation class
> but
> >>>>     >>>>>>>>> stsProperties.getSamlRealmCodec() is always null in my
> >>>>     code (how
> >>>>     >>>> can i
> >>>>     >>>>>>>>> set it, need to create a new one?)
> >>>>     >>>>>>>>> but after in the fetchSAMLAssertionFromWSSecuri
> >>> tySAMLToken()
> >>>>     >>>> function
> >>>>     >>>>>>>>> List<WSSecurityEngineResult> engineResults =
> >>>>     >>>> handlerResult.getResults();
> >>>>     >>>>>>>>> line give back an empty list.
> >>>>     >>>>>>>>>
> >>>>     >>>>>>>>> In the request there is an SAML token.
> >>>>     >>>>>>>>>
> >>>>     >>>>>>>>> I try to find some solution, but every example is
> >>>>     working with the
> >>>>     >>>>>>>>> usernametoken, and/or dont provide a valid cxf config
> xml.
> >>>>     >>>>>>>>>
> >>>>     >>>>>>>>> Thanx
> >>>>     >>>>>>>>> Csaba
> >>>>     >>>>>>>>>
> >>>>     >>>>>>>>>
> >>>>     >>
> >>>>     >
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Colm O hEigeartaigh
> >>>>
> >>>> Talend Community Coder
> >>>> http://coders.talend.com
> >>>
> >
>
>


--
Colm O hEigeartaigh

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