I am trying to send a SAML request to the public IDP SSOCircle. I imported its metadata and try to authenticate against this URL:
https://idp.ssocircle.com/sso/idpssoinit?metaAlias=%2Fpublicidp&spEntityID=sp.bogdan.test
But when I send this request from my app, the following error is displayed:
Error occurred Reason: The SAML Request is invalid.
this my request:
a link
and this is the SAML message in the request that I wrote:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_3b7f937b-073d-4289-b2d1-35e786ebb524" Version="2.0" IssueInstant="2017-04-03T12:42:06Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://localhost:61344/Account/AssertionConsumerService">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.ssocircle.com</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" AllowCreate="true"/>
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
It may be as simple as not having registered the right Assertion Consumer URL (http://localhost:61344/Account/AssertionConsumerService) with SSOCircle. But you should really look in to the SSOCircle debug logs to find out more.
In your example you are sending https://idp.ssocircle.com as the Issuer of the AuthnRequest. The Issuer of the request is not the IDP but the SP. In your case it should be sp.bogdan.test
Related
With reference to our previous post our customer asked us to change the SamlIdpSettings:logouturl setting to:
https://idpqa.csu.edu.au/idp/profile/SAML2/POST/SLO
but the following then occurred:
2022-10-17 09:51:12,555 - 137.166.20.125 - ERROR [org.opensaml.profile.action.impl.DecodeMessage:73] - Profile Action DecodeMessage: Unable to decode incoming request
org.opensaml.messaging.decoder.MessageDecodingException: This message decoder only supports the HTTP POST method
at org.opensaml.saml.saml2.binding.decoding.impl.HTTPPostDecoder.doDecode(HTTPPostDecoder.java:84)
2022-10-17 09:51:12,556 - 137.166.20.125 - WARN [org.opensaml.profile.action.impl.LogEvent:101] - A non-proceed event occurred while processing the request: UnableToDecode
How can we change our code to use a POST request instead of a GET when sending the logout request?
The TestWebAppCore sample do logout using POST with the Saml2PostBinding.
It can be change to use GET by using the Saml2RedirectBinding.
https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/blob/master/test/TestWebAppCore/Controllers/AuthController.cs#L68
https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/blob/master/test/TestWebAppCore/Controllers/AuthController.cs#L81
https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/blob/master/test/TestWebAppCore/Controllers/AuthController.cs#L90
OPTIONS http://localhost:9000/api/chat/ 404 (Not Found)
XMLHttpRequest cannot load http://localhost:9000/api/chat/. Response for preflight has invalid HTTP status code 404
https://www.playframework.com/documentation/2.5.x/CorsFilter has details on enabling CORS for Play (which is Lagom is built on). To handle the OPTIONS you may need to do something like:
.withAutoAcl(true)
.withServiceAcls(
ServiceAcl.methodAndPath(Method.OPTIONS, "/foo")
)
https://groups.google.com/forum/#!msg/lagom-framework/dtYN_1Ds4SQ/gT-BGPuCAQAJ is a lagom-framework list discussion thread with more details.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests has an explanation of why your browser is sending an OPTIONS request to begin with.
The metadata for the current exact maven artifact which provides CORS for Play is this:
<metadata>
<groupId>com.typesafe.play</groupId>
<artifactId>filters-helpers_2.12</artifactId>
<versioning>
<latest>2.6.0-M2</latest>
<release>2.6.0-M2</release>
<versions>
<version>2.6.0-M1</version>
<version>2.6.0-M2</version>
</versions>
<lastUpdated>20170310220437</lastUpdated>
</versioning>
</metadata>
I'm using TestShib and Python Social Auth SAML backend to implement a Service Provider on a Django app.
I've been able to configure my app, and build a metadata file.
TestShib allows for my metadata file to be uploaded here.
I have configured TestShib's metadata correctly on my end and built up a test button pointing to TestShib's endpoint.
When I click that button, I get redirected to TestShib, then provide test credentials, and then I get an error because the metadata does not match the redirect.
How does TestShib, or any other IDP for that matter, manage to find the right metadata (among several SPs) after an incoming auth request? Does the EntityID have to match the URL of the Service Provider?
EDIT: (added more info)
SP's metadata (uploaded previously to TestShib):
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" cacheDuration="P10D" entityID="https://www.example.com">
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor xmlns:ds="http://www.w3.org/2000/09/xmldsig#" use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDBDC .. QltX1icsr0=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor xmlns:ds="http://www.w3.org/2000/09/xmldsig#" use="encryption">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDBDC .. QltX1icsr0=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://staging.example.com/complete/xx-saml/" index="1" />
</md:SPSSODescriptor>
<md:Organization>
<md:OrganizationName xml:lang="en-US">example</md:OrganizationName>
<md:OrganizationDisplayName xml:lang="en-US">Example</md:OrganizationDisplayName>
<md:OrganizationURL xml:lang="en-US">https://www.example.com</md:OrganizationURL>
</md:Organization>
<md:ContactPerson contactType="technical">
<md:GivenName>John Doe</md:GivenName>
<md:EmailAddress>johndoe#example.com</md:EmailAddress>
</md:ContactPerson>
<md:ContactPerson contactType="support">
<md:GivenName>John Doe</md:GivenName>
<md:EmailAddress>johndoe#example.com</md:EmailAddress>
</md:ContactPerson>
</md:EntityDescriptor>
Request:
https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO?SAMLRequest=fVNN ...
<samlp:AuthnRequest
AssertionConsumerServiceURL="https://staging.example.com/complete/saml/"
Destination="https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO"
ID="ONELOGIN_973a7f348c282cc6dedd4410f900efcf9538dcda" IssueInstant="2016-08-22T14:12:11Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ProviderName="Example"
Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer>https://www.example.com</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
Error:
10:10:39.009 - WARN [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:206] - Relying party 'https://www.example.com' requested the response to be returned to endpoint with ACS URL 'https://staging.example.com/complete/saml/' and binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' however no endpoint, with that URL and using a supported binding, can be found in the relying party's metadata
10:10:39.009 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:447]
- No return endpoint available for relying party https://www.example.com
https://staging.example.com/complete/saml/ is available so the problem seems to be that the metadata info was not found by TestShib. Entity ID and Issuer seem to match ..
The Assertion Consumer Service URL in the AuthN Request (https://staging.example.com/complete/saml/) doesn't match the one in the metadata (https://staging.example.com/complete/xx-saml/), which is is also in line with the error thrown by the IdP.
The quickest fix would be to edit the metadata and correct the <md:AssertionConsumerService.../> element so that it reflects the actual ACS to be used.
I have a problem for POST request to cloudfront with signed cookies using custom policy.
Recently I changed domain. Before that both GET and POST requests worked well. Now POST request doesn't work.
I think I set up every thing same as before.
Detail situation is like this.
1.GET request to Cloudfront (domain: https://cdn.myexampledomain.com) from https://myexampledomain.com still works fine.
2.I use S3 as origin and GET/POST requests directly to S3 works fine. No CORS problem.
3.However, preflight request to Cloudfront fails.
and I got this error in console.
No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'https://myexampledomain.com is therefore not allowed
access. The response had HTTP status code 403.
Funnier thing is when I click "replay XHR" in Chrome developer tool, POST request WORKS fine with signed Cookies and gets 201 Created response. This makes me crazy.
I tried CURL and POSTMAN to test POST request and both worked successfully as expected. This is not Chrome browser problem. Same happens in Safari, Firefox.
I am using AngularJS for client app. I suspected angular but GET/POST requests to S3 directly are fine. (and GET request to Cloudfront)
POST request body and cookie is like this.
Amazon S3 CORS is like follows.
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>https://myexampledomain.com</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>PUT</AllowedMethod>
<AllowedMethod>POST</AllowedMethod>
<AllowedMethod>DELETE</AllowedMethod>
<AllowedMethod>HEAD</AllowedMethod>
<MaxAgeSeconds>3000</MaxAgeSeconds>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>
This is my custom policy. expireTime is set correctly.
{
"Statement": [
{
"Condition":{
"DateLessThan":{"AWS:EpochTime":expireTime}
}
}
]
}
and cloudfront behavior setting
I am spending two days for this problem. Any small help will be appreciated.
You can see in your OPTIONS response that CORS headers are not being set. That should be your first pointer.
Then look at your configurations of S3 and you can see that you are not setting CORS headers for OPTIONS request.
So add
<AllowedMethod>OPTIONS</AllowedMethod>
to your configurations, result:
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>https://myexampledomain.com</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>PUT</AllowedMethod>
<AllowedMethod>POST</AllowedMethod>
<AllowedMethod>DELETE</AllowedMethod>
<AllowedMethod>HEAD</AllowedMethod>
<AllowedMethod>OPTIONS</AllowedMethod>
<MaxAgeSeconds>3000</MaxAgeSeconds>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>
On your screenshot you can see that in cloudfront you have OPTIONS enabled already, so it should work now.
I am repalying to this because I have similar problem with ng-file-upload, not sending cookies with OPTIONS method and so my pre-flight is throwing error that it is unauthorized. When you fix your config, can you please post if you still get error so I know where the problem could be?
How would I be able to handle a soap fault in cxf out interceptor but changing the response from fault to success response, I am also using ws-addressing and WSS4J as part of the response.
I am struggling to return a
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
ws-address- ws-security
<soap:Body>
<Response>
Ok!
</Response>
</soap:Body>
</soap:Envelope>
rather I am currently getting
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Body>
<soap:Fault>
<soap:Code>
<soap:Value>soap:Receiver</soap:Value>
</soap:Code>
<soap:Reason>
<soap:Text xml:lang="en">Fault occurred while processing.</soap:Text>
</soap:Reason>
</soap:Fault>
</soap:Body>
</soap:Envelope>
The documentation(http://cxf.apache.org/docs/interceptors.html) says:
Additionally, in the case of SOAPFaults, a CXF web service will create a separate outbound error handling chain and the client will create an inbound error handling chain.
So I think you have to add a InFaultInterceptor/OutFaultInterceptor where you can handle your response message.