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.
Related
I didn't even know how to set the title but I'm having this issue:
Recently I needed to create a logout request(HTTP-POST) from app 1 (using Node & Angular) with the SAML2-JS library and send it to another app in RoR using saml_idp to process the SAML request.
The main issue I saw it's SAML2-JS sends the SAML request in one format like this:
{"SigAlg"=>"http://www.w3.org/2000/09/xmldsig#rsa-sha1",
"SAMLRequest"=>"lVLLaoQwFP0VyT5jEqPG4AiFoSDMtNApXXQzxDxaQRObRDqfX3XoolAKXd7DPQ/uuXUQ4zDxo3tzc3zSH7MOMWkPe3DpcixzVVVQl4RBqoiCncEY23455QSNoQZt3aEIWNC4RwCRGSGDDFGDFGDGKHUPYKksPi0lsRN+Z7jFPgafqpvejtbtQpSK7jYAPfsu3B7C13IvSBWzHqwKPk57vTkS+WfPIuOukG0NSbub9R/yaJELRfzUGzrhmtFut15qdeeheciY926K2u05toUz8sIu0huXd+FPFv9RXpFTTbKp/WA4WobQT/jEYrykwhNaQ66yDNMwY7wijEtMCmysqqo6xOb8Ga+tbjWYe1jtYqfW0uCucoYwWCHS3F0kRGoajWTpAiiJRZJRmu01+Y3+CPt2i+AA==",
"Signature"=>"WkDaGzC6vPTlzh+EnFA5/8IMmV7LviyRh2DA5EHF0K0nl+xzBlKfNCYRnunpwoEvGhereGdI5xBpv+mc9IguiCaLZSZjDh6lIDdpvctCnmSNzORqzWQw43H46Hfdsfi2cL+ObrUDS2gV1XvBA3Q3RRhoDmi+XE89Ztnd1cNpR3XdA+EL2ENbMI2XAD9qSgMufUJY/3GBBpT7Vg1ODtPxBudq+sXrgPh/+WtUUitLkkfC8tdRTCS1EZPv+h27I5g/VNza23Xl8w2HdAuYP0F2FjREo8VV2aUtaOUd/jAF9+bfkGV93y1PzFttLxdBbFoxp6qBg=="}
But the ruby gem(saml_idp) expects all the 3 properties being just one in XML format like this one:
<samlp:LogoutRequest>
<...saml message...>
<ds:Signature>
<ds:SignedInfo />
<ds:SignatureValue />
<ds:KeyInfo />
</ds:Signature>
</samlp:LogoutRequest>
I don't know how to fix that or change the format from SAML2-JS
I tried different properties in SAML2 but nothing worked, I debugged the ruby gem and I didn't find anything that could help me
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 need to request a JWT Token via an HTTP request in my Spring Integration application.
I've configured a plain http outbound gatway but the server replies with a 301 Moved Permanently;
It requires the client to follow a redirect (and apparently it works this way doing some tests with SOAP-UI);
How could I make the http-outbound-gateway to follow redirects?
Tried everything I could find, but nothing worked so far.
Thanks!
You need consider to configure your HTTP Outbound Gateway with a HttpComponentsClientHttpRequestFactory. This one is based on the Apache HTTP Client 4.x and its default behavior is a DefaultRedirectStrategy which does a redirect on GET and HEAD methods and when 302, 301 or 307 status is returned for the call.
If you need to redirect POST, consider to configure an underlying HttpClient with a LaxRedirectStrategy.
See more info here: Handling HttpClient Redirects
UPDATE
To configure a LaxRedirectStrategy for the HttpClient used in the HttpComponentsClientHttpRequestFactory you need something like this:
<beans:bean id="httpClientBuilder" class="org.apache.http.impl.client.HttpClients" factory-method="custom">
<beans:property name="redirectStrategy" value="#{new org.apache.http.impl.client.LaxRedirectStrategy()}"/>
</beans:bean>
<beans:bean id="clientHttpRequestFactory"
class="org.springframework.http.client.HttpComponentsClientHttpRequestFactory">
<beans:constructor-arg>
<beans:bean factory-bean="httpClientBuilder" factory-method="build"/>
</beans:constructor-arg>
</beans:bean>
It is kinda pitta to do all that stuff in XML, so consider to move your project to Java & annotation configuration.
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>