we marked "Assertions Signed" in OpenAM configuration,
and if the SAML response coming from IDP is signed and the SAML assertion is not signed,
will OpenAM consider this SAML response as a valid SAMLResponse?
note : openam version 13.0.0
Ever since OPENAM-7055 has been implemented, AM will consider a signed SAML response as if the assertion itself was signed. The JIRA issue has fix version set to 13.0.0, so this behaviour should be already correct in that version.
if the SAML response coming from IDP is signed and the SAML assertion is not signed, will OpenAM consider this SAML response as a valid SAMLResponse?
No, as SAML response signing is different from Assertion signing.
Side note: Assertion signing can be negotiated via attributes in the SAML meta data. SAML response signing has to be negotiated out-of-band as the SAML meta data specification has not defined an attribute for it.
Related
Are the AssertionConsumerService in metadata and saml2 issuer same in SSO? I am trying to authenticate using SSO but getting error and 400 status.
In general: The AssertionConsumerService endpoint is the one used by the IdP to send the SAML Response to. The issuer of the assertion will be the entity ID of the IdP.
A SAML compliant ServiceProvider has to perform some checks when consuming the SAML Response, please see SAMLv2 core specification.
The logs of the product/framework you are using should tell you which of the validation checks fail.
We are acting as service provider (supporting SAML2.0) and we are working on a proposal to federate with a new federation whose IDP is ADFS2.0. We are currently supporting several other Federations that are currently using OKTA as their IDP.
We expect the IDP to post SAML assertion either through (SP initiated or IDP initiated). If ADFS2.0 is acting as IDP, will the SAML assertion will be similar to OKTA or will it be different? (I heard that the SAML assertion from ADFS2.0 will be compressed in addition to Base64 encoding while from OKTA it is only base64 encoded.)
You can expect both OKTA and ADFS to support the SAML2 standard.
If you are using the HTTP Redirect binding the xml is deflated+Base64-encoded. If you are using the HTTP POST binding the xml is only Base64-encoded. For receiving SAML2 assertions you shouldn't use the HTTP Redirect binding due to data length restrictions. So if you have a working implementation for OKTA it should work for ADFS too.
I am trying to implement SSO for a service and using ADFS and PingFederate as IDP.
SSO works when I avoid signing the AuthRequest (both with ADFS and PingFederate), but fails with following error "SAML Message has wrong signature. Issuer: 'My SP entityID' " when AuthRequest is signed.
I had updated corresponding Relying trust part with certificate of my SP. I think, i am doing something wrong in the IDP configuration. Any help is appreciated.
I had tried this answer without any luck: MSIS0038: SAML Message has wrong signature - ADFS error
This error on ADFS is received when the AuthnRequest is signed but the SP's certificate configured is incorrect. Make sure that you have provided the correct certificate, go to Relying Party Properties > Signature tab. You should see the certificate provided by you. Verify the thumbprint to be sure.
Also, if you are sending the SAMLRequest as a query parameter (HTTP-Redirect binding), make sure you are using the SHA1 certificate for signing the AuthnRequest. Signing using the SHA256 certificate is not supported in HTTP-Redirect binding by ADFS.
I am able to see the SAML Request and responses on the server log.
In an SP initiated SSO, I am able to see the saml authentication request at the SP server log. And the SAML Assertion response at the IDP Server log.
How do I know if the SAML Assertion generated by the ID is received by SP? Are there any ways to check that pon the SP side? If so, please let me know.
Thanks,
aswini J
There's a Request ID in the AuthnRequest that is logged in the PF server.log. If you receive a SAMLResponse at the SP (in this case PF) that is the result of your SP-Init SSO and it contains an InResponseTo attribute/ID, it must match the Request ID that was generated by the server per the SAML 2.0 specification.
PF will automatically enforce the SAML 2.0 processing rules so you don't have to worry about it. If the SAMLResponse is successfully validated, you can configure PF to map the user's identity attributes into a SP Adapter which will help you with your last-mile integration in your application.
I would suggest following up with your Ping Identity RSA who can help you answer some of these core functionality questions.
I have a working ADFS machine. I want to construct a passive request that will generate a saml 2.0 token.
the following request for saml 2.0 token:
https://adfstest.cld.sr/adfs/ls/?wa=wsignin1.0&wtrealm=https%3A%2F%2Flocalhost%2FPro%2FFederatedLogin.mvc&wauth=urn:oasis:names:tc:SAML:2.0:am:password
generates the error: "Microsoft.IdentityServer.Protocols.Saml.NoAuthenticationContextException: MSIS7040: None of the requested authentication types are supported by the server."
yet if I change the request to a request for saml 1.0:
https://adfstest.cld.sr/adfs/ls/?wa=wsignin1.0&wtrealm=https%3A%2F%2Flocalhost%2FPro%2FFederatedLogin.mvc&wauth=urn:oasis:names:tc:SAML:1.0:am:password
It works but the token generated by ADFS is SAML 1.0.
What is the correct form to construct a request for passive federation with SAML 2.0 tokens?
AD FS 2.0 does not support SAML 2.0-based IDP-initiated SSO to a WIF relying party application.
The url you used in a ws-federation request and as such only saml 1.1 will be returned by ADFS.