I fill in all the details on the form and always get back the error of “e.find is not a function” (see attached screenshot). I’ve logged into the server trying to look at any other logs that were generated, but they were not helpful as the error logged was the same thing. Any insight would be appreciated.
-Dustin
Hi Dustin,
Can you validate if SAML XML metadata has md:SingleSignOnService or SingleSignOnService xml tag in it?
Yes, it does have that tag:
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="<URL>"/>
Hi Dustin,
There should be 2 XML tag for md:SingleSignOnService one for HTTP-Redirect and HTTP-POST. Mostly both of them point to same location url, If IdP is not providing you with HTTP-POST, you can add it manually by copy HTTP-Redirect and edit binding to HTTP-POST
<md:SingleSignOnService Binding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” Location=“”/>
<md:SingleSignOnService Binding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=“”/>
We will improve the error code in upcoming release to help understand the problem in better manner.
I would caution that slightly: if the IdP doesn’t include the HTTP-POST binding in their metadata, it’s possible that they actually don’t support that mechanism at all.
(Speaking as someone who has implemented a SAML IdP that doesn’t support HTTP-POST 
)
cnMaestro only supports communicating with IdP with HTTP-POST. Maybe we can add the support for HTTP-Redirect soon.
HTTP-Redirect have few problems that I see.
One, is the size of assertion that IdP will send to SP might cross browser URL size limits.
Other, is the response can be logged easily inside any http-proxy or any intermediary.
Quoting SAML security spec line 670. Though it will not harm our system because we have a mechanism against replay attack.
We can discuss more on it.
As I understand it, the <md:SingleSignOnService> metadata element only describes the way that the service provider initiates the login process. For HTTP-Redirect, it redirects the browser to the URL in the Location attribute. For HTTP-POST, it causes the browser to issue a POST to that URL. This authentication request doesn’t tend to contain much data, and it’s unlikely to be sensitive, so URL size limits and web server logs are not really a problem.
The mechanism for sending the assertion back to the service provider is defined in the service provider’s metadata, in the <md:AssertionConsumerService> element. The assertion can be large and does contain sensitive data, so HTTP-POST is more suitable.
@nabham and I investigated this in more detail, and we believe this solution should work, because cnMaestro actually follows the HTTP-Redirect flow, not the HTTP-POST flow, despite looking for the HTTP-POST binding in the metadata file. Please let us know either way.
The IDP I am trying to integrate with only supports HTTP-Redirect, but I tried changing the binding in the xml to use POST instead and now I am getting back an “Invalid IdP Metadata XML Format” message. To compare my metadata to a new one generated using the OneLogin Metadata Tool, there is no difference. I’m wondering if cnMaestro is looking for something in particular in the XML that my metadata is missing. Any insight?
I tried with the exact xml metadata that I got from you except that I added one more tag
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="<url>"/>
It seems to be working. Can you share with me the latest XML metadata you are trying ?
If possible can you also share logs ?
Interesting that adding that extra line to the metadata allowed it to save. Now it appears I get the following error when I get redirected back from the IDP:
{"error":{"code":"INVALID_CSRF","message":"Form tampered with BAD REQUEST"}}
We need to make sure IdP does HTTP-POST on Assertion Consumer Service URL, which means IdP should make a http post on callback url (https://<on-premises-host>/cn-srv/login/saml) with SAMLResponse.
The IDP is performing an HTTP-POST to the URL as you specified with a SAMLResponse in base64 as well as RelayState. I have run the response through the samltool.com response validation tool and it shows it to have a valid response as well. The error message “Invalid CSRF” makes me think the SAML endpoint for login is looking for a CSRF token to be passed in the HTTP-POST request, but that does not make sense. Any other suggestions or logs/things I should look at further on the cnMaestro side?
-Dustin
CSRF check is skipped for this /cn-srv/login/saml so we need to make sure whether IdP is sending post on exact route. Can you send me a screenshot of the browser url and request from browsers network tab when it says Form tampered with BAD REQUEST ?
Is it possible for you to share the technical support dump ?
Attached are 4 screenshots. First shows the URL and the error, second shows the network tab, third and fourth show the payload/request). The support dump should be in your messages.
Looks like the bad CSRF error was coming from the Query Param idp=<url>. After getting that removed, now I receive the message of “You are not authorized to access this application”. My guess is I’m missing something in the mapping, so I’m going to play around with that some more.
You need to make sure you have a role Attribute in SAML response, something like below
<saml:Attribute FriendlyName="Roles" Name={ROLE_KEY} NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" >
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string" >{ROLE_VALUE_1}</saml:AttributeValue>
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string" >{ROLE_VALUE_2}</saml:AttributeValue>
</saml:Attribute>
The value of the ROLE_KEY is whatever we set in cnMaestro
The value of ROLE_VALUE_1 or ROLE_VALUE_2 is whatever we set in cnMaestro role mapping like below
In addition to that the RelayState is one time token, we wont be able to replay the same response. Just in case you are trying from external tool i.e. postman, curl etc that might not work.
I checked the technical support dump but couldn’t find anything, if possible can you enable debug logs on the setup and do the above operation which gives you “You are not authorized to access this application” and then share the dump.
@nabham,
I was aware of the RelayState and have been going through the entire login cycle each time I have been testing this, but thanks for the heads up there. Also, I appreciate the sample Attribute you provided and what they map to in the cnmaestro config, that actually helped shed some light as to why certain things weren’t looking right when I would examine the generated SAML response.
Regarding debug logs, I have this setting enabled already, is there something else needing to set?
That it is. Can you share the dump again if you are still facing the issue?
