I did SSO of OpenAM and SalesForce.com (SFDC)
I have installed OpenAM-Client SDK to retrieve SAML Assertion from OpenAM.
I used this assertion data to generate SAML response required for SalesForce. When I pass this data to SFDC. I got error message for SAML.
“Failed: Signature Invalid/Configured Certificate Mismatch”
I used same certificate and signature data which I got from OpenAM-client SDK public API assertion.
At time of SSO configuration with SDFC. I used default certificate (test cert) provided by OpenAM.
Is there any way to retrieve test certificate and its signature from OpenAM ?
Run one of the failing SAML assertions through the SAML Validation tool inside Single Sign-On Settings in SFDC; you should get a slightly more useful error. The most likely cause of this is that you have not uploaded the correct certificate to SFDC as part of your SSO setup. Make sure the "Identity Provider Certificate" section of "Single Sign-On Settings" matches the cert contained in the assertion.
Related
I have custom policies setup within our Azure AD B2C tenant to setup a SAML based signin SP initiated flow. On receipt of the response from the third party IDP I get the exception "The response has an invalid relay cookie".
I believe this is because the IDP's response is missing the InResponseTo property. Having spoken to said IDP, they are not able to send back the InResponseTo property in their response.
Is there a way to either remove the InResponseTo property from our initial request, OR is it possible to disable checking the InResponseTo attribute on receipt of the response?
I've successfully run a signin using the same custom policies in B2C, but using https://samltest.id/start-sp-test/ as the IDP instead, and can see the InResponseTo property returned in the response from here. So this is the only thing I have been able to identify as the a possible cause.
I know this is bad practice / a security flaw, but we are trying to prove we can get the identity flow working with this third party, with a view this will be fixed at a later date.
I have a basic question on setting up trust between a SP and IDP.
Usually a two way trust is required when we setup an IDP with SP by uploading certificates on either side.
Is signing certificate from SP mandatory to be configured in the IDP side ?
Best Regards,
Saurav
You only need a signing keypair on the SP side if you send the subject in the AuthnRequest, and your IdP utilizes the information when provided. If your SP isn't sending the subject attribute or your IdP won't consume it, you don't need it.
The defined SAML 2.0 specifications doesn't mandate that the request is signed.
4.1.3.3 <AuthnRequest> Is Issued by Service Provider to Identity Provider
...The <AuthnRequest> message MAY be signed, if authentication of the request issuer is required.
You can check with your Identity Provider documentation, but for example, Microsoft Azure AD does not validate signed requests, and there's no way to upload a request signing certificate.
We Use OpenAM version 13.0.0
and we faced the following error during using urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
ERROR: spAssertionConsumer.jsp: SSO failed. com.sun.identity.saml2.common.SAML2Exception: No local user being mapped. at com.sun.identity.saml2.profile.SPACSUtils.processResponse(SPACSUtils.java:1225) at org.apache.jsp.saml2.jsp.spAssertionConsumer_jsp._jspService(spAssertionConsumer_jsp.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
The hosted SP first uses the NameID map to extract the 'username' from the Subject (that holds the NameID) of the incoming SAML assertion and then use it to search the configured user data stores for an user identity subject (using the configured user search attribute). If this fails, it uses the configured account mapper to extract a 'username' attribute from the attribute statement. Here auto-federation configuration also matters.
--> It depends on the SAML response and OpenAM configuration why you run into this error. It's impossible to tell the root cause without seeing the SAML response and the OpenAM configuration. You may send it to me via (encrypted) email.
Using WSO2 5.1.0. Needs to send SAML assertion like firstName, lastName from WSO2 as IDP to SP. Refer Configuration. User profile do have first name and last name values.
Restarted WSO2, no error in logs. But I don't receive these values in SAML response sent from WSO2 to my Service porvider.
For this, in your Service Provider's SAML Configuration, you need to make sure following two checkboxes are selected.
Enable Attribute Profile
Include Attributes in the Response Always
Then, inside the Claim Configuration section of the Service Provider configuration, you need to add the particular claims you need to receive as Requested Claims. Then these claims will be included in SAML response.
If you want the claims to have a different key name, you can define a custom claim dialect there and provide your own key names for claims.
In WSO2IS v4.6.0, the AuthnContextClassRef value is hardcoded to urn:oasis:names:tc:SAML:2.0:ac:classes:Password. In fact, the SAML SSO endpoint actually authenticates users via HTTPS by default and the AuthnContextClassRef value in this case should be urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport.
What's the best way to correct this or get this issue on WSO2's radar?
I've created a JIRA ticket for this issue: https://wso2.org/jira/browse/IDENTITY-2585
While waiting for an offical fix, you can override their DefaultSAML2SSOManager by specifiing your own class in repository/conf/security/application-authentication.xml with:
Parameter name="SAML2SSOManager">my.version.of.SAML2SSOManager
I use a slightly modified version of their DefaultSAML2SSOManager and am able to connect to our IDP.