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.
Related
In a project, I am using SAML authentication to connect AWS managed grafana to an Identity provider via keycloak as Identity broker.
While getting saml response back on https://<some-grafana-url>/saml/acs I am getting forbidden with error
{"message":"Failed to determine the state of the SSO redirect"}
I have checked NameIdPolicy Format in SAML Request is same as NameId Format under Subject in SAML response.
Certificate is also valid.
What else can lead to this error?
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.
I'm implementing an SSO authentication flow using SAML for a web server running tomcat. Everything is working ok when using POST or Redirect bindings, but from what I've read to support the SAML authentication in front of a REST API I need to also configure and use an ECP profile.
First correct me if I'm wrong but the ECP flow should be like this:
Client accesses the SP REST API
Client knows he needs to authenticate so he sets up the required ECP headers (Accept: application/vnd.paos+xml and PAOS: urn:liberty:paos:2003-08;urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp)
SP sees client is not authenticated and returns a SOAP Envelop containing PAOS Request.
The client is responsible to send this to the appropriate IdP on its ECP consumer service.
The IdP challenges the client for authentication
The IdP returns a response in the form of another SOAP Envelop, containing the saml Response in its body
The client must send this response to SP's ECP/SOAP assertion consumer service
The problem is all of this works until step 6. On this step I have the problem, that the Body of the response envelop contains a Destination attribute, which points to the POST assertion consumer service of the SP. This destination attribute is set by keycloak and mismatches the actual ECP service that I want to send the response to. The SAML library we are using is opensaml and it checks the request URI against this Destination attribute and if they do not match it throws an exception org.opensaml.xml.security.SecurityException: SAML message intended destination endpoint did not match recipient endpoint.
I understand why this exception is thrown, but cannot understand how I can configure Keycloak with the ECP/SOAP service of the SP. In Keycloak's admin console I can only configure the URLs for SSO POST/Redirect and SLO POST/Redirect, but nothing about ECP.
I'm currently in the process of configuring another IdP, but I would really like to make sure that Keycloak can also be a supported server for our solution.
Can't you just read the paos:Request responseConsumerURL and post the idp response to that url?
At least, that's how I managed to do it.
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 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.