SAML authentication against Azure Active Directory, ends up at the Microsoft error page.
Article ID: 4375
Updated On:
Products
Issue/Introduction
Often clients who want to enable SAML end up in Microsoft Error page. The only log entry from the Webview log tells me that we have a signed request sent to IDP. - 8/05/16 10:07:19.680 AM PDT [INFO] [WebView]
Sent signed SAML request from http://xxx.xxx.com:8080/ApmServer/ to IDP.
Environment
Cause
Environmental/Configuration issues. Typically the above issue prompts questions like:
1) Does Azure IDP as it's configured by customer supports SAML 2.0 ? - This needs to be verified
2) Does the customer IDP supports HTTP POST requests? Some providers ( older versions of CA SiteMinder) only support HTTP GET
3) Does IDP logs show any errors?
4) Customers might also request a method to turn of sending signed requests and send unsigned requests. Is this doable?
5) CA APM's certificate that is not trusted (basically self-signed) and therefore vendors might not permit it? If that is the case, what we need to import a trusted certificate?
Resolution
Some insights on this issue:
CA Technologies ships our product with our self signed certificate, but we do let customers the ability to import their own.
There is a way for customers to import their keys into our keystore and it is documented here - > https://cawiki.ca.com/pages/viewpage.action?pageId=718249398
Once the key is imported its name, needs to be configured in IntroscopeEnterpriseManager.properties using the hidden property:
introscope.saml.sp.privatekey.alias=spprivatekey
or, you could just replace the key named ‘spprivatekey’ in the keystore, then you don’t need to update IntroscopeEnterpriseManager.properties file.
There is a way to disable our signing and send the request. The parameter (hidden) that can be configured.
introscope.saml.sp.privatekey.alias=badname
sends our requests without signing.
Feedback
