DocumentSubmission: These policy alternatives can not be satisfied

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

DocumentSubmission: These policy alternatives can not be satisfied

ParanoidUser
Hi everyone,

Could somebody share with me the manual "How configure security policy for: DocumentSubmission service and client side (I use SoapUI)"?


At now, when I try to send ProvideAndRegisterDocumentSetRequest to DocumentSubmission (1.1 or 2.0) I catch the response with the following policy errors:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
   <soap:Header>
      <Action xmlns="http://www.w3.org/2005/08/addressing">urn:ihe:iti:xdr:2007:DocumentRepositoryXDR_PortType:DocumentRepository_ProvideAndRegisterDocumentSet-b:Fault:PolicyException</Action>
      <MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:1a42b484-abb4-474e-943e-9ef12691f92e</MessageID>
      <To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
      <RelatesTo xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:0df8e2c4-08a2-4fb4-9950-2cc0cab9ce51</RelatesTo>
   </soap:Header>
   <soap:Body>
      <soap:Fault>
         <soap:Code>
            <soap:Value>soap:Receiver</soap:Value>
         </soap:Code>
         <soap:Reason>
            <soap:Text xml:lang="en">These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportBinding: TLS is not enabled
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}HttpsToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}IncludeTimestamp
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EndorsingSupportingTokens: The received token does not match the endorsing supporting token requirement
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SamlToken: The received token does not match the token inclusion requirement</soap:Text>
         </soap:Reason>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>

I saw a few topics with the same issue but the list of policy problems was the different.
Unfortunately, I didn't find any document that will help me to fix this.

I would be grateful for any help!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

AlameluChidambaram
There is a  ValidationSuite in CONNECT source code (Product/SoapUI_Test/ValidationSuite) and that can be used to send a DocumentSubmission request to the Entity interface. There are g0 and g1 suites where g0 send the DocumentSubmission request to 1.1 endpoint and g1 send the request to 2.0 endpoint.

Please follow CONNECT installation instructions to configure the 2 way ssl and there are instructions available for CONNECT supported Application servers. This a link to 4.4 installation instructions and there are instructions available for other supported CONNECT versions.

https://connectopensource.atlassian.net/wiki/display/CONNECT4/Building+CONNECT+4.4+from+Source

Please let us know if you have any questions.

Thanks,
Alamelu

CONNECT Product Team



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

ParanoidUser
Thank you for reply!

In the installation guide I see the following recommendations about SSL:
keytool -genkey -keyalg RSA -keysize 2048 -keystore gateway.jks -keypass changeit -storepass changeit -validity 365 -alias gateway -dname "cn=host1"
keytool -export -rfc -alias gateway -file HOST1.cer -keystore gateway.jks -keypass changeit -storepass changeit
keytool -import -v -noprompt -trustcacerts -alias HOST1 -file HOST1.cer -keystore cacerts.jks -storepass changeit

As a result I have 3 files:
gateway.jks - key store with generated public/private keys;
HOST1.cer - extracted X509 certificate;
cacerts.jks - trust store that contains single certificate after importing (or it might be default Java trusted store? <JAVA_HOME>\lib\security\cacerts);

After this I put cacerts.jks and gateway.jks into <GLASSFISG_HOME>/glassfish/domains/domain1/config and configure it from Glassfish admin console.
In console Common Tasks: Configurations > Network Config > Network Listeners > http-listener-1 (or -2 for HTTPS) > SSL > Trust Store

And specify gateway.jks as a key store for SoapUI:
In SoapUI preferences: SSL Settings: KeyStore

Finally, I restart Glassfish server.
But, I observe the same behavior in my HTTP response.

Please direct me, what am I doing wrong?

Thank you.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

ParanoidUser
I repeat all step from guide for binares. All operations with keytool.exe were performed in <GLASSFISG_HOME>/glassfish/domains/domain1/config folder. And modify default cacerts.jks located here.

In server.log I observe the following information:
Jun 02, 2015 6:07:14 PM org.glassfish.hk2.classmodel.reflect.Parser$5 on
SEVERE: Exception while visiting com/sun/gjc/spi/JdbcObjectsFactory.class of size 3630
java.lang.NullPointerException
        at org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78)
        at org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
        at org.glassfish.hk2.classmodel.reflect.util.JarArchive.onSelectedEntries(JarArchive.java:125)
        at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
        at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
        at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
        at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

As far as I known this is a still opened bug in GlassFish (link to bug). Please check my logs if it helps to solve my problem (logs.zip).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

AlameluChidambaram
Can you deploy DocumentSubmission service and execute the Validation Suite available within Binary?

This will make sure the configuration part is successfully done.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

ParanoidUser
Sure, I had import ConnectValidation-soapui-project.xml as a SoapUI project and run TestRunner for g1 and g0. In this case, test execution finished with error.

Please take a look to my SoapUI logs (soapui-errors.log).

The most oftern encountered error is:
2015-06-03 13:00:48,134 ERROR [errorlog] groovy.lang.MissingPropertyException: No such property: nhinc for class: Script1
and
2015-06-03 13:00:48,136 ERROR [errorlog] java.lang.Exception: TestCase [Document Submission Deferred Req] failed without assertions

Thank you.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

AlameluChidambaram
It seems SoapUI could not find the FileUtils jar. Can you please copy FileUtils jar which will be available within Binary to SoapUI/bin/ext and SoapUI/lib folders?

MySQL connector jar will also be needed by SoapUI to successfully execute the test cases. MySQL connector jar will also be available within Binary and needs to be copied to SoapUI/bin/ext and SoapUI/lib folders.

Thanks,
Alamelu Chidambaram

CONNECT Product Team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

ParanoidUser
Thank you  Alamelu,

After adding missing dependencies I have a new set of errors in my logs.

Firstly, SoapUI didn't see one more dependency:
2015-06-03 14:58:05,767 ERROR [errorlog] groovy.lang.MissingPropertyException: No such property: org for class: Script1

Secondly, retrived response from CONNECT contains unexpented status:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
   <soap:Header>
      <Action xmlns="http://www.w3.org/2005/08/addressing">urn:gov:hhs:fha:nhinc:nhincentityxdr:async:request:ProvideAndRegisterDocumentSet-bAsyncRequest_ResponseMessage</Action>
      <MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:77eaa719-33e2-455f-8536-3427a1488c24</MessageID>
      <To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
      <RelatesTo xmlns="http://www.w3.org/2005/08/addressing">uuid:26dbaaee-c683-49b4-b555-398a431c239e</RelatesTo>
   </soap:Header>
   <soap:Body>
      <ns8:XDRAcknowledgement xmlns:ns10="http://nhinc.services.com/schema/auditmessage" xmlns:ns11="http://docs.oasis-open.org/wsn/b-2" xmlns:ns12="http://docs.oasis-open.org/wsrf/bf-2" xmlns:ns13="http://docs.oasis-open.org/wsn/t-1" xmlns:ns14="urn:gov:hhs:fha:nhinc:common:nhinccommon" xmlns:ns15="http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd" xmlns:ns16="urn:gov:hhs:fha:nhinc:common:subscriptionb2overridefordocuments" xmlns:ns17="urn:oasis:names:tc:emergency:EDXL:DE:1.0" xmlns:ns18="http://www.hhs.gov/healthit/nhin/cdc" xmlns:ns19="urn:gov:hhs:fha:nhinc:common:subscriptionb2overrideforcdc" xmlns:ns2="urn:gov:hhs:fha:nhinc:common:nhinccommonentity" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns6="urn:ihe:iti:xds-b:2007" xmlns:ns7="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns8="http://www.hhs.gov/healthit/nhin" xmlns:ns9="http://www.w3.org/2005/08/addressing">
         <ns8:message status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure">
            <ns4:RegistryErrorList highestSeverity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error">
               <ns4:RegistryError codeContext="Security processing failed." errorCode="XDSRegistryError" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/>
            </ns4:RegistryErrorList>
         </ns8:message>
      </ns8:XDRAcknowledgement>
   </soap:Body>

Thank you!
</soap:Envelope>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

ParanoidUser
Attached logs (soapui-errors.log)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

AlameluChidambaram
This seems like the environment configuration is not quite complete. If you are using the self signed certificates there is a glassfish domain template available within CONNECT source code  in the following location CONNECT\Product\Install\GlassFish\templates\connect\domain.selfsigned.xml.template. you can replace domain.xml with this one and specify the name of keystores and truststores that you wish to use.


please check out the following link which has CONNECT source build wiki instructions. If you use the source build you can take advantage of auto-installer that comes with CONNECT.
https://connectopensource.atlassian.net/wiki/display/CONNECT4/Building+CONNECT+4.4+from+Source
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

ParanoidUser
I did it in process of installation. After running and deployment CONNECT-GF-4.4.ear GlassFish modify domain.xml.

Could you please check is this problem caused by invalid configuration (domain.xml)?

I can try to install CONNECT from source , but it will be better if I could install it from binaries.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

AlameluChidambaram
I was reading through your previous forum post and you have mentioned the following

"And specify gateway.jks as a key store for SoapUI:
In SoapUI preferences: SSL Settings: KeyStore"

CONNECT ValidationSuite send the requests to Unsecured Entity interfaces and the above configuration is not needed. Can you please try removing that and execute those testcases?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

ParanoidUser
Yep, I did it. And I test sending SOAP request to the following CONNECT service:
http://localhost:8080/Gateway/DocumentSubmission/1_1/DocumentRepositoryXDR_Service

My expectations that after successful sending I can see my document in my MySQL DB (select * from docrepository.document). And get my document back by execution of SOAP method "DocumentRepository_RetriveDocumentSet" for the same service. Please correct me if it is not.

I try to find differences between requests from Validation Suite (that successfuly passed) and my request (unsecure-soap-request.xml) that return policy error in response (unsecure-soap-response.xml). And I found that the most requests from Validation Suite contain "Security" header. I think this is the reason of my problems.

If add the same to my request (copy-pasted from Validation Suite sample), and after this I observe "SAML signature validation failed". From my point of view it caused by invalid signature configuration in Security header, or unsigned document content that I try to send in request.

Modified SOAP request (secure-soap-request.xml)
Retrived response (secure-soap-response.xml)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

AlameluChidambaram
I understood from above post that DocumentSubmission from ValidationSuite worked successfully. That's awesome to hear!

This makes clear that configuration/environmnet is working. A successful DocumentSubmission sends a Success status in the Response. This won't be stored in database.

The below endpoint that you have been trying to use seems like secured endpoint. so it should be "HTTPS" endpoint instead of "HTTP".


http://localhost:8080/Gateway/DocumentSubmission/1_1/DocumentRepositoryXDR_Service

Thanks,
Alamelu.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

ParanoidUser
Hmm... It seems like HTTPS (port 8181) is not configured properly.

URL: https://localhost:8181/Gateway/DocumentSubmission/1_1/DocumentRepositoryXDR_Service
Reponse: empty response

In SoapUI error log I observe java.net.SocketException: Software caused connection abort: recv failed
   java.net.SocketException: Software caused connection abort: recv failed
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(Unknown Source)
    at java.net.SocketInputStream.read(Unknown Source)
    at sun.security.ssl.InputRecord.readFully(Unknown Source)
    at sun.security.ssl.InputRecord.read(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.waitForClose(Unknown Source)
    at sun.security.ssl.HandshakeOutStream.flush(Unknown Source)
    at sun.security.ssl.Handshaker.sendChangeCipherSpec(Unknown Source)
    at sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(Unknown Source)
    at sun.security.ssl.ClientHandshaker.serverHelloDone(Unknown Source)
    at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
    at sun.security.ssl.Handshaker.processLoop(Unknown Source)
    at sun.security.ssl.Handshaker.process_record(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source)
    at sun.security.ssl.AppOutputStream.write(Unknown Source)
    at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:131)
    at org.apache.http.impl.io.AbstractSessionOutputBuffer.write(AbstractSessionOutputBuffer.java:151)
    at org.apache.http.impl.conn.LoggingSessionOutputBuffer.write(LoggingSessionOutputBuffer.java:74)
    at org.apache.http.impl.io.ContentLengthOutputStream.write(ContentLengthOutputStream.java:114)
    at org.apache.http.impl.io.ContentLengthOutputStream.write(ContentLengthOutputStream.java:120)
    at org.apache.http.entity.ByteArrayEntity.writeTo(ByteArrayEntity.java:68)
    at org.apache.http.entity.HttpEntityWrapper.writeTo(HttpEntityWrapper.java:96)
    at org.apache.http.impl.client.EntityEnclosingRequestWrapper$EntityWrapper.writeTo(EntityEnclosingRequestWrapper.java:108)
    at org.apache.http.impl.entity.EntitySerializer.serialize(EntitySerializer.java:120)
    at org.apache.http.impl.AbstractHttpClientConnection.sendRequestEntity(AbstractHttpClientConnection.java:263)
    at org.apache.http.impl.conn.AbstractClientConnAdapter.sendRequestEntity(AbstractClientConnAdapter.java:227)
    at org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:255)
    at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$SoapUIHttpRequestExecutor.doSendRequest(HttpClientSupport.java:119)
    at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
    at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:633)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:454)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
    at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$Helper.execute(HttpClientSupport.java:233)
    at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport.execute(HttpClientSupport.java:323)
    at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.submitRequest(HttpClientRequestTransport.java:290)
    at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.sendRequest(HttpClientRequestTransport.java:220)
    at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:119)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

anji
This post was updated on .
In reply to this post by ParanoidUser
Hi,
   I am also facing the same problem. Can you please tell us the elements inside wsse:security Header that you set in the request. Because, I couldn't find security header in none of the Validation suite test soap requests. Your quick help is much appreciated!!!!

I am trying to call this webservice
http:/<hostname>:8080/Gateway/CORE_X12DocumentSubmission/1_0/GenericBatchResponseTransaction_Service

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:cor="http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd" xmlns:urn="urn:gov:hhs:fha:nhinc:common:nhinccommonentity" xmlns:urn1="urn:gov:hhs:fha:nhinc:common:nhinccommon" xmlns:add="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:urn2="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:urn3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:urn4="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:urn5="urn:ihe:iti:xds-b:2007">
   

   <soap:Header>
     <wsse:Security>
   <wsse11:SignatureConfirmation xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" Value="Uk1mcI+zBnDxJ4Z+AqoHxCLxZVZlVGgfB5zW/jO7xFyt97DvUjk6xDaC4lNxvrOvSwpnwEe9iq8548BommlWNHbN40UKwmYTP8Dq3vY1pmewswdcQmQ2S5VitjpOTaj7RHzg7dIXJPjFoKUBXKzFxglnLJrajy3VMgfUv0iPbylMqMCJoptJN2v0Yux/TXvwyjO9ES50bMA7GYSslkWNEWXOmJJQfImwAb+xjdP6s0sQ4ixGK05/dWP8M7Iw/RL/rHh4mLgh39DoUA9ljJ5lZNYWMfGUm6Er578Blyc0/wTETPB/hkywfxWVzV6zhwhYjm5q498V59ieafXnMgO+DA==" wsu:Id="SC-162"/>
   </wsse:Security>
   </soap:Header>
   
   <soap:Body>
       
     <cor:COREEnvelopeBatchSubmission>
         <PayloadType>X12_278_Request_005010X217E1_2</PayloadType>
         <ProcessingMode>RealTime</ProcessingMode>
         <PayloadID>somepayloadid</PayloadID>
         <PayloadLength>739</PayloadLength>
         <TimeStamp>2016-10-15T14:45:21Z</TimeStamp>
         <SenderID>somesenderid</SenderID>
         <ReceiverID>somerecvrid</ReceiverID>
         <CORERuleVersion>v2.2.0</CORERuleVersion>
         <CheckSum>?</CheckSum>
         <Payload>somepayload</Payload>
     </cor:COREEnvelopeBatchSubmission>
   </soap:Body>
</soap:Envelope>


Response:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
   <soap:Header>
      <Action xmlns="http://www.w3.org/2005/08/addressing">http://www.caqh.org/SOAP/WSDL/GenericBatchTransactionPort/BatchSubmitTransaction/Fault/PolicyException</Action>
      <MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:556cb6de-e2ce-4cfc-8af3-b294b2764aeb</MessageID>
      <To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
      <RelatesTo xmlns="http://www.w3.org/2005/08/addressing">uuid:93732bde-bc11-4474-8458-67ea05f5c676</RelatesTo>
   </soap:Header>
   <soap:Body>
      <soap:Fault>
         <soap:Code>
            <soap:Value>soap:Receiver</soap:Value>
         </soap:Code>
         <soap:Reason>
            <soap:Text xml:lang="en">These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportBinding: TLS is not enabled
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}HttpsToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}IncludeTimestamp
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EndorsingSupportingTokens: The received token does not match the endorsing supporting token requirement
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SamlToken: The received token does not match the token inclusion requirement</soap:Text>
         </soap:Reason>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>


Thanks,
Prasanna
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DocumentSubmission: These policy alternatives can not be satisfied

ravin
hi Anji: I am also in the same boat as you are but i was able to get rid of the following messages. but we did this by using apache axis rampart configuration by creating a policy file.

{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportBinding: TLS is not enabled
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}HttpsToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}IncludeTimestamp



Loading...