Greetings. We are attempting to setup SAML integration with InsightVM using DUO Access Gateway and have been having nothing but issues with it. Has anyone else attempted this integration before? If so, were there any hurdles that you had to get through that weren’t outlined in the documentation? I am curious to know about your experiences.
Thank you!
I don’t have experience with this myself, but I’m going to check with a few other folks on the team to see if they’ve done SAML/Duo. We have docs here for SAML auth (I know you mentioned having read some docs, but just confirming) and it looks like Duo has some additional info here as well.
We use DUO with our Azure SSO. It was a complete pain but we got it to work. I’ll try to help if you can explain what isn’t working.
Greetings Randon. Could you elaborate on the issues you ran into? I feel like I am running into a few “gotchas” not mentioned in the documentation, or like it could be something simple I am overlooking. I was getting a “SAML Credentials are Invalid” error on the login screen, but after changing a few attributes with guidance from R7 support, I am now getting a “The session timed out. Log on again.” error with a 401 error showing in the background. Below that, there is a message that says “A cookie CSRF token with the name ‘nexposeCCSessionID’ was not provided”.
If you have any insight into this specific issue or if you just want to share the struggles you had, either would be appreciated.
Thank you!
We had one issue with case sensitivity. If you use the extension SAML-tracer, it should show you how the site is receiving the credentials. Also, you must use the full authentication URL provided by the SSO provider. The whole process is ugly and not very eloquent since you never really hit the authentication page if you are using SSO.
We are using SSO with InsightVM + Okta fine. The biggest challenge was making sure the Okta settings were right. From the InsightVM side, basically only the metadata + entity ID seemed to be needed.
I do agree with the lack of SP-initiated SAML support. From my side, if you time-out, you should be able to click a “sign-in with SSO” button and have auto-direct you back to your sign-in process. Not having this makes for some weird workflows (open SSO sign-in in new tab, then go to original tab and hit back button and then forward button to get it to recogniize new creds and not lose (too much) of where you were when it timed out.
We attempted getting DUO set up as well, we don’t tend to use the DUO App Launcher as it is, which looks to be a requirement for the Insight platform. I put this on the back burner for now but I plan to revisit it down the road. But I would like the option to not have to use the App Launcher.
Were you able to resolve this? I’m getting the same error when setting for Okta.
Anyone using Azure SSO for saml auth ?
When I create a test account for signing in via saml my credentials are invalid. Is it invalidating the credentials due to case sensitivity on how azure sso has it defined?
I can sign in to the insight platform fine with SSO, but the issue lies on pivoting over to the security console. Sometimes I will be pivoted over with no issues and I can probably attribute that to the session still being active. Otherwise I am redirected to the login screen.
Any advice or suggestions to what helped you resolve this would be greatly appreciated.
Also - when defining the saml source in the onprem console of nexpose. Do we need to provide the base identity ID then restart the console for the pivot to work ?
Cheers,
Jake
Im getting same issue, we had working but now is showing this error
I have been working with support for weeks on getting SAML to work with on prem insightVM with azure .
It has been a constant struggle of digging through logs, doing SAML traces to validate that the upn is being passed through the idp. I have created accounts with the saml authentication that cant login. We have verified that the base entity url is matching when we navigate with the saml SSO link. Still no dice getting any additional information other than the credentials are invalid or the session timed out.
One of my goals this year is to deploy vulnerability management as a service for all of my internal customers. Being able to pivot for SSO on the insight platform to the product (on prem ) is a crucial step in order for this to be embraced by our internal customers.
Support was unable to recreate the issue we are having. So at this point my last idea is to perform a packet capture between rapid7 console and the IDP to see what is being sent and received. We need to look for a token that is hopefully being passed. A token will need to be decrypted to validate that credentials are being sent to the idp.
I hope this brings us more clarity. I thought id share my experience with everyone.