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.
Related
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
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>
I've been trying to use the NetSuite api for sometime using the netsuite gem.
I can login to the website, but when I try to authenticate from the API I get an INVALID_LOGIN_CREDENTIALS error.
This is the payload of the request:
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:platformMsgs="urn:messages_2011_1.platform.webservices.netsuite.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:platformCore="urn:core_2011_1.platform.webservices.netsuite.com">
<env:Header>
<platformMsgs:passport>
<platformCore:email>email#email.com</platformCore:email>
<platformCore:password>--snip--</platformCore:password>
<platformCore:account>ACCOUNTNO</platformCore:account>
<platformCore:role type="role" internalId="ROLE"/>
</platformMsgs:passport>
</env:Header>
<env:Body>
<platformMsgs:get>
<platformMsgs:baseRef xsi:type="platformCore:RecordRef" internalId="4" type="customer"/>
</platformMsgs:get>
</env:Body>
</env:Envelope>
This is the payload of the response:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server.userException</faultcode>
<faultstring>You have entered an invalid email address or account number. Please try again.</faultstring>
<detail>
<platformFaults:invalidCredentialsFault xmlns:platformFaults="urn:faults_2011_1.platform.webservices.netsuite.com">
<platformFaults:code>INVALID_LOGIN_CREDENTIALS</platformFaults:code>
<platformFaults:message>You have entered an invalid email address or account number. Please try again.</platformFaults:message>
</platformFaults:invalidCredentialsFault>
<ns1:hostname xmlns:ns1="http://xml.apache.org/axis/">sb-partners-java002.svale.netledger.com</ns1:hostname>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
I've just solved the issue. If you're having trouble make sure that:
You are connecting to the right environment. (non-sandbox vs sandbox)
Your user (or your role) have WebServices permission (see in Permissions > Setup)
I faced both of the issues. My account, even belonging to an Administrator role, lacked Web Services permission. And I was using the sandbox url to a non-sandbox account.
https://webservices.na1.netsuite.com/wsdl/v2012_1_0/netsuite.wsdl (non-sandbox)
https://webservices.sandbox.netsuite.com/wsdl/v2012_1_0/netsuite.wsdl (sandbox)
Another possible cause of this issue is if the password contains + or % characters. Removing these from the password fixed this for me.