If I use this one, it gives me these results: curl -i -X POST $apigee/add-wssec-username-token/t1 -H content-type:text/xml -d ' Attached here please find a reproduction of that example proxy (the one that uses JavaScript and XSL). The README for that repo describes it in more detail and there's an example API Proxy that shows you how to do it.Ībout the 403 - I guess you were trying to download the example proxy showing the other option, which was to use JavaScript + XSL to do the same thing? I just tried that and also got the 403 Forbidden. You can use it just like a builtin policy, but you need to add the Java JAR to the API proxy. This Java callout does what I think you described - inserts a username token that complies with WS-Security standard into a SOAP message. In Apigee, thereis no "builtin" policy step type that does that work, though there is a "community contributed" callout that does this. I understand what your'e saying regarding the SOAP message and adding a username token. So I'm not clear on exactly what the obstacle is. here is the screenshot from layer7Īt one point you said you want to "apply WS-Security" and at another point you said " we just need to drop Assertions." The latter sounds like "removing WS-Security". are adding plain username/password and then applying ws-security to the request payload and sending it to backend. so in the future, other people won't trip over this.Īlso, you can avoid the AssignMessage completely, by substituting ntent for the output variable in that custom java policy. I'll update the sample to inject the username token in the proxy request flow. If you're going to use this Java policy ( Java-WSSEC-Inject-UsernameToken-with-Plaintext-Password) you probably want it to be attached in the target request preflow, just prior to your AssignMessage to set the payload. In retrospect, it was probably a mistake for me to attach the java policy there, but with no target, it didn't matter.īut, If you add a target to that proxy bundle and try to access the output variable in the target Request preflow, which is obviously prior to the Response flow on the proxy endpoint, the output variable hasn't been set yet, so it will be empty. ![]() those flows call the custom Java callout policy to inject the UsernameToken and set the variable called output, in the Response flow. If you look at the proxy endpoint configuration, for the flows for /inject1 and /inject2. If you are using the sample proxy bundle included in that repository as your starting point, then this is an easy one.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |