I'm new in wso2 esb.
I am trying to make a secure proxy to protect a non secure web service.
I follow different tutorials and I do the following configuration for my proxy:
`<proxy xmlns="http://ws.apache.org/ns/synapse"
name="ProxyStockeSecure"
transports="https,http,local"
statistics="disable"
trace="disable"
startOnLoad="true"><target inSequence="LogAndRemoveHeader" outSequence="LogSeqResponse">
<endpoint>
<address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
</endpoint></target><publishWSDL uri="http://localhost:9000/services/SimpleStockQuoteService?wsdl"/><enableSec/><policy key="sec_policy"/><description/></proxy>
The LogAndRemoveHeader sequence removes the security Header and log the flow.
<sequence xmlns="http://ws.apache.org/ns/synapse" name="LogAndRemoveHeader"><log level="full"></log><header xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" name="wsse:Security" scope="default" action="remove"></header><log level="full"></log></sequence>
When I send a signed request to the secure proxy I can see that the proxy validates it well (thanks to rampart).
But when I look at the log on the back end server, I see that the Security header is still present while I remove it in the "LogAndRemoveHeader" sequence.
In the WSO2 server, I can see that the Security is correctly removed:
TID: [0] [ESB] [2015-03-19 01:20:31,508] INFO {org.apache.synapse.mediators.builtin.LogMediator} - To: /services/ProxyStockeSecure, WSAction: urn:getSimpleQuote, SOAPAction: urn:getSimpleQuote, MessageID: urn:uuid:7d951378-9a98-4b60-bcba-cded778ee977, Direction: request, Envelope: <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:ser="http://services.samples"><soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-1150340834">
<ser:getSimpleQuote>
<!--Optional:-->
<ser:symbol>1</ser:symbol>
</ser:getSimpleQuote></soap:Body></soap:Envelope>
But, on the back end server, the security header is back and I feel that wso2 has re-signed the request. Indeed, the DigestValue or SignatureValue differs from the original request...
Use send mediator to send your request to backend service inside your LogAndRemoveHeader sequence. Here is the sample send mediator code.
<send>
<endpoint>
<address uri="http://localhost:9000/services/SimpleStockQuoteService"></address>
</endpoint>
</send>
Related
I'm using node and the soap package. The code works and fetches the account info I need. This is legacy code which I'm trying to reverse engineer. When I call the soap packages' client.lastRequest, console.log('last request: ', client.lastRequest) I see the SOAP call that was made:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract"
xmlns:tns="https://bingads.microsoft.com/Customer/v13"
xmlns:q1="https://adapi.microsoft.com"
xmlns:q2="https://adapi.microsoft.com"
xmlns:q3="https://adapi.microsoft.com"
xmlns:q4="https://adapi.microsoft.com"
xmlns:q5="https://adapi.microsoft.com"
xmlns:q6="https://adapi.microsoft.com"
xmlns:q7="https://adapi.microsoft.com"
xmlns:q8="https://adapi.microsoft.com"
xmlns:q9="https://adapi.microsoft.com"
xmlns:q10="https://adapi.microsoft.com"
xmlns:q11="https://adapi.microsoft.com"
xmlns:q12="https://adapi.microsoft.com"
xmlns:q13="https://adapi.microsoft.com"
xmlns:q14="https://adapi.microsoft.com"
xmlns:q15="https://adapi.microsoft.com"
xmlns:q16="https://adapi.microsoft.com"
xmlns:q17="https://adapi.microsoft.com"
xmlns:q18="https://adapi.microsoft.com"
xmlns:q19="https://adapi.microsoft.com"
xmlns:q20="https://adapi.microsoft.com"
xmlns:q21="https://adapi.microsoft.com"
xmlns:q22="https://adapi.microsoft.com"
xmlns:q23="https://adapi.microsoft.com"
xmlns:q24="https://adapi.microsoft.com"
xmlns:q25="https://adapi.microsoft.com"
xmlns:q26="https://adapi.microsoft.com"
xmlns:q27="https://adapi.microsoft.com"
xmlns:q28="https://adapi.microsoft.com"
xmlns:q29="https://adapi.microsoft.com"
xmlns:q30="https://adapi.microsoft.com"
xmlns:q31="https://adapi.microsoft.com"
xmlns:q32="https://adapi.microsoft.com"
xmlns:q33="https://adapi.microsoft.com"
xmlns:q34="https://adapi.microsoft.com"
xmlns:q35="https://adapi.microsoft.com"
xmlns:q36="https://adapi.microsoft.com"
xmlns:q37="https://adapi.microsoft.com">
<soap:Header>
<tns:Action>GetAccountsInfo</tns:Action>
<tns:ApplicationToken>actual_token</tns:ApplicationToken>
<tns:AuthenticationToken>actual_token</tns:AuthenticationToken>
<tns:DeveloperToken>actual_token</tns:DeveloperToken>
</soap:Header>
<soap:Body>
<GetAccountsInfoRequest
xmlns="https://bingads.microsoft.com/Customer/v13" xsi:nil="true">
</GetAccountsInfoRequest>
</soap:Body>
</soap:Envelope>
I also output the URL:
https://clientcenter.api.bingads.microsoft.com/Api/CustomerManagement/V13/CustomerManagementService.svc?wsdl
When I copy these into Postman/Insomia/other API clients I get a 200 OK response BUT not the data I need. The returned XML is 1000s of lines of what looks like the API (Microsoft/Bing Ads API for their customer management service) definition.
I assume it's telling me that the request is wrong, so here, take a guide. But I don't know where to begin looking.
Anything I should look out for when translating Nodes' soap package -> a SOAP call within Postman?
I am using passport-saml as a SAML client and requesting to external IDP. I want to add <Extensions> element in SAML request like below:
<samlp:AuthnRequest AssertionConsumerServiceURL="https://iam.test.fi/oxauth/postlogin" Destination="https://testidp.fi/idp/profile/SAML2/Redirect/SSO" ID="_3a5525fc-f5cc-46af-add6-70bbc27ecebf" IssueInstant="2021-05-19T11:05:04Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://iam.test.fi/oxauth/1</saml:Issuer>
<samlp:Extensions>
<vetuma xmlns="urn:vetuma:SAML:2.0:extensions"><test>fi</test></vetuma>
</samlp:Extensions>
<samlp:NameIDPolicy AllowCreate="true"/>
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://testidp.fi/2017/loa3</saml:AuthnContextClassRef>
</samlp:AuthnRequest>
I checked passport-saml config parameters but didn't find any one which gives facility to add <Exntesions> element.
Thank you.
I'm trying to secure an application using picketlink. I'm using JBoss 6.4.18.
The SSO operation works without any issues. The problem is with the SLO, basically, picketlink sends the LogoutRequest assertion to the wrong endpoint. The IdP metadata inside my war has these endpoints:
<md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://myidp.com/saml2/soap" index="0" isDefault="true"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://myidp.com/saml2/slo" ResponseLocation="https://myidp.com/saml2/slo_return"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://myidp.com/saml2/slo" ResponseLocation="https://myidp.com/saml2/slo_return"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://myidp.com/saml2/soap"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://myidp.com/saml2/rni" ResponseLocation="https://myidp.com/saml2/rni_return"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://myidp.com/saml2/rni" ResponseLocation="https://myidp.com/saml2/rni_return"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://myidp.com/saml2/soap"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://myidp.com/saml2/sso"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://myidp.com/saml2/sso"/>
<md:NameIDMappingService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://myidp.com/saml2/soap"/>
LogoutRequest assertion looks good to me, but, picketlink sends it to the /sso endpoint instead of using /slo (as indicated by the metadata). When the idp receives that LogoutRequest it doesn't even redirect the browser back to the SP application.
The assertion actually has the correct destination, but as I said, the browser sends to the /sso endpoint.
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
Destination="https://myidp.com/saml2/sso"
Is this a bug in picketlink?
I must say that I've configured it using other IdP servers where the endpoint is the same for both types of assertions, in such cases, the SLO worked perfectly.
I'd appreciate your help on this one.
Thank you.
In the end I couldn't fix this by configuration. One would expect picketlink to send the SLO assertions to the endpoint declared in the metadata file, but as I described in the question above it doesn't.
By checking the plugin code I saw that it can read a request parameter to decide what endpoint send the Logout Request assertion to.
So, when the SP requests a GLO I add another request parameter as follows:
/?GLO=true&picketlink.desired.idp="+encodedSLOEndpointURL
picketlink reads that parameter (picketlink.desired.idp) and sends the assertion to that endpoint on the IdP side.
P.S. I hope this is the last time I have to deal with such an old library like picketlink.
I'm using the ews-javascript-api to manage my EWS contacts on an exchange server.
I'm trying to update a contact object by removing an email address.
I've followed this blog post and it's got me most of the way there. However, when I remove the ExtendedProperty's for EmailAddress1 the ews-javascript-api throws an exception due to an HTTP 500 coming back from the EWS soap request to update a contact. Looking at the SOAP request, I can see that there is an empty FieldURI which is what the response error is complaining about.
Here is my soap request
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<soap:Header>
<t:RequestServerVersion Version="Exchange2010_SP2"></t:RequestServerVersion>
</soap:Header>
<soap:Body>
<m:UpdateItem MessageDisposition="SaveOnly" ConflictResolution="AutoResolve">
<m:ItemChanges>
<t:ItemChange>
<t:ItemId Id="AAMkADczNzM2MTM4LTZmNWItNDBhYy05ZjcwLWUxMDc3ZDY2NjFiMABGAAAAAAC3bTmWRbrTRqYt+VZXGp68BwD5r6sZ7j5YSprMfvM2gaMkAAAAAAAQAAD5r6sZ7j5YSprMfvM2gaMkAAB4CjURAAA=" ChangeKey="EQAAABYAAAD5r6sZ7j5YSprMfvM2gaMkAAB4CkS4"></t:ItemId>
<t:Updates>
<t:SetItemField>
<t:FieldURI FieldURI="contacts:DisplayName"></t:FieldURI>
<t:Contact>
<t:DisplayName>Craig </t:DisplayName>
</t:Contact>
</t:SetItemField>
<t:SetItemField>
<t:FieldURI FieldURI="contacts:GivenName"></t:FieldURI>
<t:Contact>
<t:GivenName>Craig</t:GivenName>
</t:Contact>
</t:SetItemField>
<t:DeleteItemField>
<t:FieldURI></t:FieldURI>
</t:DeleteItemField>
<t:DeleteItemField>
<t:FieldURI FieldURI="contacts:MiddleName"></t:FieldURI>
</t:DeleteItemField>
<t:DeleteItemField>
<t:FieldURI FieldURI="contacts:Surname"></t:FieldURI>
</t:DeleteItemField>
</t:Updates>
</t:ItemChange>
</m:ItemChanges>
</m:UpdateItem>
</soap:Body>
And here is the soap response
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<s:Fault>
<faultcode
xmlns:a="http://schemas.microsoft.com/exchange/services/2006/types">a:ErrorSchemaValidation
</faultcode>
<faultstring xml:lang="en-US">The request failed schema validation: The required attribute 'FieldURI' is missing.</faultstring>
<detail>
<e:ResponseCode
xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">ErrorSchemaValidation
</e:ResponseCode>
<e:Message
xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">The request failed schema validation.
</e:Message>
<t:MessageXml
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<t:LineNumber>1</t:LineNumber>
<t:LinePosition>1037</t:LinePosition>
<t:Violation>The required attribute 'FieldURI' is missing.</t:Violation>
</t:MessageXml>
</detail>
</s:Fault>
</s:Body>
And finally here is the exception that the javascript api throws.
"Exception
at UpdateItemRequest../node_modules/ews-javascript-api/js/Core/Requests/ServiceRequestBase.js.ServiceRequestBase.ProcessWebException (https://sr1.genband.com/genlync/bundle-electron.js:44707:36)
at https://sr1.genband.com/genlync/bundle-electron.js:45557:41
at <anonymous>"
Finally I'll mention that I can remove an email address without removing any extended properties with the following function.
response.EmailAddresses._setItem(ews.EmailAddressKey.EmailAddress1, address.value);
However, the problem with this is, while it looks like it works, if I try to edit that contact on my outlook web interface, I get an error about some property mismatch. Looks like if I don't remove those extended properties when deleting an email, then they stay around and cause issues for other clients.
this should work in 0.9.3 version, available starting 0.9.3-dev.1 which is ews-javascript-api#next currently.
My ACS URL is being rewritten from https://foo.com/ to http://foo.com/ which is causing the below Exception.
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.AssertionConsumerServiceUrlDoesNotMatchPolicyException: MSIS3200: No AssertionConsumerService is configured on the relying party trust 'foo-shibboleth-sp' that is a prefix match of the AssertionConsumerService URL 'http://foo/Shibboleth.sso/SAML2/POST' specified by the request.
The log message reflects that the auth request was sent as http as well:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="http://foo/Shibboleth.sso/SAML2/POST"
Destination="https://bar/adfs/ls/"
ID="_12345ID" IssueInstant="2017-08-08T22:24:28Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"><saml:Issuerxmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">foo-shibboleth-sp</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/></samlp:AuthnRequest>
2017-08-08 22:24:28 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: message encoded, sending redirect to client
I have included my configuration below.
The SP metadata I've configured in my IDP has the correct URL with https, but is being changed to http somewhere downstream and can be seen in the Shibboleth logs for the samlp auth request.
If I switch handlerSSL to TRUE, the ACS URL in the samlp auth request shows https. However, when it's set to TRUE, anything at the path of /Shibboleth.sso/ such as /Status, or /SAML2/POST are 404ing.
I should also note that this is actually a site migration and this was all on windows in a datacenter now it's on Linux in AWS. There could be an issue with the Load Balancer where we terminate SSL, but haven't been able to debug that.
In the SP metadata that was provided to the IDP, I specify the https /SAML2/POST url. There is a bunch of config here, but I tried to highlight the relevant stuff.
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_97e389f1c212...." entityID="foo-shibboleth-sp">
...
<init:RequestInitiator xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://foo/Shibboleth.sso/Login"/>
....
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://foo/Shibboleth.sso/SAML2/POST" index="10"/>
Then, in the shibboleth2.xml on my SP, I have the following application override config:
<ApplicationOverride id="lms" entityID="foo-shibboleth-sp"
homeURL="/path/to/sso/location">
<Sessions lifetime="28800" timeout="3600" checkAddress="false"
handlerURL="/Shibboleth.sso" handlerSSL="false"
exportLocation="https://foo/Shibboleth.sso/GetAssertion" exportACL="127.0.0.1"
idpHistory="false" idpHistoryDays="7">
<!-- Default example directs to a specific IdP's SSO service (favoring SAML 2 over Shib 1). -->
<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
relayState="cookie" entityID="http://bar/adfs/services/trust">
<SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" acsIndex="5"/>
</SessionInitiator>
</Sessions>
<MetadataProvider type="XML" file="/etc/shibboleth/metadata-sp.xml"/>
<!-- Map to extract attributes from SAML assertions. -->
<AttributeExtractor type="XML" validate="true" path="/etc/shibboleth/attribute-map.xml"/>
</ApplicationOverride>
Finally, the only other piece that I have determined could be causing issues, is the IDP metadata here:
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ID="_1234-..." entityID="http://bar/adfs/services/trust">
...
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://bar/adfs/ls/" index="0" isDefault="true" />
....
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://bar/adfs/ls/" />
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://bar/adfs/ls/" />
apache config also, though it seems pretty cookie-cutter
<Location />
ShibRequestSetting applicationId lms
</Location>
<Location /path/to/sso/location>
ShibRequestSetting applicationId lms
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
</Location>
The problem ended up being related to SSL Offload with the AWS Load Balancer. Because we were terminating at the ELB, we needed to set https:// on the ServerName directive in Apache config so that it would generate the https self-referential urls.
http://httpd.apache.org/docs/2.2/mod/core.html#servername