Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
MIME-Version: 1.0
Reply-To: coheigea@apache.org
In-Reply-To: 
 <CAEnbdEB2nKPZKah2g1PWBbHiGLjNWSrF-+ZWK7CZKYFy3At2rw@mail.gmail.com>
References: <1343058117990-5711426.post@n5.nabble.com>
	<CAB8XdGBXhS2Sxdy9id1-xumu+UP0J6-dzjFju8xN+3fb+3D0+Q@mail.gmail.com>
	<CAEnbdECJrhJfcM04JLqcbUsXB49e7CR3ZOM=X_xSZWo9d-KTMA@mail.gmail.com>
	<CAEnbdEB2nKPZKah2g1PWBbHiGLjNWSrF-+ZWK7CZKYFy3At2rw@mail.gmail.com>
Date: Tue, 24 Jul 2012 15:28:36 +0100
Message-ID: 
 <CAB8XdGBrL9KNG0EH+oRHhWmCCcC-ehNC6bdfFH3x3T8sVuCFrg@mail.gmail.com>
Subject: Re: RequestSecurityToken without Encrypting and Signing
From: Colm O hEigeartaigh <coheigea@apache.org>
To: Gina Choi <ginachoi88@gmail.com>
Cc: users@cxf.apache.org
Content-Type: multipart/alternative; boundary=bcaec54ee7b88855c904c5942d9c

--bcaec54ee7b88855c904c5942d9c
Content-Type: text/plain; charset=ISO-8859-1

What security policy are you using for the TransportUT_Port? It sounds like
the WS-SecurityPolicy layer is not getting invoked.

Colm.

On Tue, Jul 24, 2012 at 2:35 PM, Gina Choi <ginachoi88@gmail.com> wrote:

> Hi Colm,
>
> Alex and I working together to get this work. I am responsible to
> configure Fediz STS for him. Could you take a look following exceptions
> from Alex's RST. We decided to use TransportUT_Port. I think that is being
> used for WS-Federation SSO as well. Anyway, please ignore previous our
> emails. Could you tell us what is wrong with his RST?
>
>
> ID: 1
> Address: https://wkqasv0805.global.sdl.corp:9443/fedizidpsts/STSService
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: application/soap+xml; charset=utf-8
> Headers: {accept-encoding=[gzip, deflate], connection=[Keep-Alive],
> Content-Length=[1908], content-type=[application/soap+xml; charset=utf-8],
> expect=
> [100-continue], host=[wkqasv0805.global.sdl.corp:9443]}
> Payload: <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
> xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="
> http://docs.oasis-open.
> org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><s:Header><a:Action
> s:mustUnderstand="1">http://docs.oasis-open.org/ws-sx/ws-trust/200512
>
> /RST/Issue</a:Action><a:MessageID>urn:uuid:24a48857-71ec-466e-bfe6-675c08f84c6e</a:MessageID><a:ReplyTo><a:Address>
> http://www.w3.org/2005/08/addressin
> g/anonymous</a:Address></a:ReplyTo><VsDebuggerCausalityData xmlns="
> http://schemas.microsoft.com/vstudio/diagnostics/servicemodelsink
> ">uIDPo8DHZtWXyK1J
> n2JxXCS85z4AAAAAlruHm4rOAUCcZNvbjFb/PND3aSmMn0JLk9BMBxOE9WoACQAA</VsDebuggerCausalityData><a:To
> s:mustUnderstand="1">https://wkqasv0805.global.sdl.cor
> p:9443/fedizidpsts/STSService</a:To><o:Security s:mustUnderstand="1"
> xmlns:o="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secex
> t-1.0.xsd"><u:Timestamp
> u:Id="_0"><u:Created>2012-07-24T13:27:55.050Z</u:Created><u:Expires>2012-07-24T13:32:55.050Z</u:Expires></u:Timestamp><o:Usern
> ameToken
> u:Id="uuid-64599397-270f-4886-975c-086f44f45f27-1"><o:Username>gchoi</o:Username><o:Password
> Type="http://docs.oasis-open.org/wss/2004/01/oas
>
> is-200401-wss-username-token-profile-1.0#PasswordText">gchoi</o:Password></o:UsernameToken></o:Security></s:Header><s:Body><trust:RequestSecurityToken
>  xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512"><wsp:AppliesTo
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"><a:EndpointRef
> erence><a:Address>https://medevasarafia01.global.sdl.corp/Agency/
> </a:Address></a:EndpointReference></wsp:AppliesTo><trust:KeyType>
> http://docs.oasis-op
> en.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType><trust:RequestType>
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
> </trust:RequestType><trust
>
> :TokenType>urn:oasis:names:tc:SAML:1.0:assertion</trust:TokenType></trust:RequestSecurityToken></s:Body></s:Envelope>
> --------------------------------------
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
> details.
>                 [LdapLoginModule] authentication-only mode; SSL disabled
>                 [LdapLoginModule] user provider:
> ldap://wkqasv0805.global.sdl.corp:389/ou=People,dc=maxcrc,dc=com
>                 [LdapLoginModule] attempting to authenticate user: gchoi
>                 [LdapLoginModule] authentication succeeded
>                 [LdapLoginModule] added LdapPrincipal
> "cn=gchoi,ou=People,dc=maxcrc,dc=com" to Subject
>                 [LdapLoginModule] added UserPrincipal "gchoi" to Subject
> Jul 24, 2012 9:28:00 AM 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/}Va
> lidate has thrown exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
> http://www.w3.org/2005/08/addressing}Action, {
> http://www.w3.org/2005/08/addressing}To
> ] are not understood.
>         at
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor.checkUltimateReceiverHeaders(MustUnderstandInterceptor.java:150)
>         at
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:96)
>         at
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:49)
>         at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
>         at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
>         at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:211)
>         at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
>         at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:193)
>         at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:129)
>         at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:187)
>         at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:110)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
>         at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:166)
>         at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
>         at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>         at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
>         at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
>         at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
>         at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
>         at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
>         at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
>         at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>         at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
>         at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999)
>         at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
>         at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
>         at java.lang.Thread.run(Unknown Source)
> Jul 24, 2012 9:28:00 AM
> org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor$Soap12FaultOutInterceptorInternal
> handleMessage
> INFO: class
> org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor$Soap12FaultOutInterceptorInternalapplication/soap+xml
> Jul 24, 2012 9:28:00 AM
> org.apache.cxf.services.SecurityTokenService.TransportUT_Port.STS
> INFO: Outbound Message
> ---------------------------
> ID: 1
> Response-Code: 500
> Encoding: UTF-8
> Content-Type: application/soap+xml
> Headers: {}
> Payload: <soap:Envelope xmlns:soap="
> http://www.w3.org/2003/05/soap-envelope
> "><soap:Body><soap:Fault><soap:Code><soap:Value>soap:MustUnderstand</soap:V
> alue></soap:Code><soap:Reason><soap:Text xml:lang="en">MustUnderstand
> headers: [{http://www.w3.org/2005/08/addressing}Action, {
> http://www.w3.org/2005/
> 08/addressing}To] are not
> understood.</soap:Text></soap:Reason></soap:Fault></soap:Body></soap:Envelope>
> --------------------------------------
>
>
> On Tue, Jul 24, 2012 at 8:58 AM, Gina Choi <ginachoi88@gmail.com> wrote:
>
>> Hi Colm,
>>
>> I would like to confirm if I understand you correctly. So, do we need to
>> add following content to Fediz STS wsdl file to issue a token? At this
>> point we mostly interested in(minimum) issuing a a token. I am not sure if
>> we need to "Validate" operation to issue a RSTR.
>>
>>
>>
>> <!-- 2.1.1.3 UsernameToken with timestamp, nonce and password hash -->
>> <wsp:Policy wsu:Id="DoubleItDigestPolicy">
>>   <sp:SupportingTokens>
>>     <wsp:Policy>
>>       <sp:UsernameToken sp:IncludeToken="
>> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
>> ">
>>         <wsp:Policy>
>>           <sp:HashPassword />
>>         </wsp:Policy>
>>       </sp:UsernameToken>
>>     </wsp:Policy>
>>   </sp:SupportingTokens>
>> </wsp:Policy>
>> <wsdl:binding name="DoubleItDigestBinding" type="tns:DoubleItPortType">
>>   <wsp:PolicyReference URI="#DoubleItDigestPolicy" />
>>   <soap:binding style="document"
>>   transport="http://schemas.xmlsoap.org/soap/http" />
>>   <wsdl:operation name="Issue">
>>     <soap:operation soapAction="
>> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue" />
>>     <wsdl:input>
>>       <soap:body use="literal" />
>>     </wsdl:input>
>>     <wsdl:output>
>>       <soap:body use="literal" />
>>     </wsdl:output>
>>   </wsdl:operation>
>> </wsdl:binding>
>>
>>
>> Thanks.
>>
>> Gina
>>
>> On Tue, Jul 24, 2012 at 6:34 AM, Colm O hEigeartaigh <coheigea@apache.org
>> > wrote:
>>
>>> You could use a SecurityPolicy that just requires a UsernameToken
>>> without a
>>> binding. For example see the policy "<!-- 2.1.1.3 UsernameToken with
>>> timestamp, nonce and password hash -->" starting on line 214:
>>>
>>>
>>> http://svn.apache.org/viewvc/cxf/trunk/systests/ws-security-examples/src/test/resources/org/apache/cxf/systest/wssec/examples/ut/DoubleItUt.wsdl?view=markup
>>>
>>> Of course, in practise one would combine a UsernameToken with the
>>> Transport
>>> binding to secure the message exchange...
>>>
>>> Colm.
>>>
>>> On Mon, Jul 23, 2012 at 4:41 PM, Sarafian <sarafian_developer@yahoo.gr
>>> >wrote:
>>>
>>> > I have a C# code that asks the STS for a token using username password
>>> > credentials.
>>> > I'm using the UT or UTEncrypted endpoints but I get this error:
>>> >
>>> > These policy alternatives can not be satisfied:
>>> > {
>>> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}ProtectionToken
>>> > {
>>> >
>>> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}IncludeTimestamp
>>> > :
>>> > Received Timestamp does not match the requirements
>>> > {
>>> >
>>> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SymmetricBinding
>>> > :
>>> > Received Timestamp does not match the requirements
>>> > {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts
>>> :
>>> > {http://schemas.xmlsoap.org/soap/envelope/}Body not SIGNED
>>> > {
>>> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EncryptedParts
>>> :
>>> > {http://schemas.xmlsoap.org/soap/envelope/}Body not ENCRYPTED
>>> >
>>> > Is there a way for the STS to be configured not to apply the above
>>> > policies?
>>> > Is there another endpoint for these kind of things?
>>> >
>>> > I simply want to use a username/password credential combination to
>>> request
>>> > a
>>> > security token.
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > View this message in context:
>>> >
>>> http://cxf.547215.n5.nabble.com/RequestSecurityToken-without-Encrypting-and-Signing-tp5711426.html
>>> > Sent from the cxf-user mailing list archive at Nabble.com.
>>> >
>>>
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>
>>
>


-- 
Colm O hEigeartaigh

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

--bcaec54ee7b88855c904c5942d9c--