Enable Logging.jsp, but protect it with Siteminder

[Legacy User]

Question:

 

Do any SSO community experts know the exact steps I should follow to properly secure logging.jsp in ca idm?

 

Background:

 

I've read this technical article TEC537308 on how to enable logging.jsp which I'm planning to implement within the bank's production environment, but this doesn't cover the siteminder configurations needed to securely make this change.

 

Please provide the siteminder steps needed to complete this procedure: https://support.ca.com/us/knowledge-base-articles.tec554335.html but steps 3 & 4 do NOT cover what needs to be completed within siteminder to ensure logging.jsp is secured from malicious intruders.

 

 

If this is a CA Identity Manager issue please redirect to the appropriate place, but clearly these steps should be published and referred to within this technical article or ca idm bookshelf since logging.jsp was removed due to security concerns.  Siteminder is used to ensure security which is far more robust than CA IdM's native auth and further guidance from CA on how to properly secure logging.jsp through siteminder is clearly needed to ensure it's properly protected.

 

 

Business Impact:

 

Logging JSP will enable the bank be more agile by rapidly addressing PROD issues, which are adversely affecting the external customer environment. Quickly enabling DEBUG (without getting approvals for RESTARTs) will greatly help the bank work with CA support. However, not effectively securing this feature will open the bank to unnecessary vulnerabilities, which is NOT acceptable and will block this from being rolled out, unnecessarily delaying resolutions to production issues requiring additional logging.

 

Additional Background:

 

something like this should be published for logging.jsp either in the bookshelf or in the technical document:

Here is a link to the documentation on how to secure the management console using Siteminder. https://support.ca.com/cadocs/0/CA%20Identity%20Manager%2012%206%204-ENU/Bookshelf_Files/HTML/idocs/index.htm?toc.htm?425934.html

 

The way the steps are written today in the technical document, they seem to encourage the use of native auth through ca idm, which wouldn't you agree is much less secure than using siteminder? Just imagine how many customer deployments have only secured their management console and logging.jsp with native auth rather than siteminder simply because these simple steps weren't publicized within the technical document.

[Ashok kumar Muthu]

Hi Chris,

 

I agree, steps should have been included as part the KB article and IDM product bookshelf.

 

However, steps for protecting logging.jsp should be similar to protecting IDMManage console, as it is not getting created automatically on enabling.

logging.jsp url: http://<FQDN>:<8080>/iam/im/logging.jsp

IME Protected url: http://<FQDN>:<8080>/iam/im/<IME Protected Alias>

IME Public url: http://<FQDN>:<8080>/iam/im/<IME Public Alias>

 

Here are the highlevel Steps:

1. You may create a new domain or modify the existing IDM domain which was created automatically to protect IME.

2.  Create a new realm with the below resource filter under domain and assign appropriate Authentication Scheme as needed(BASIC, FORM, IWA...etc)

               /iam/im/logging.jsp

3. Create a rule for the realm and specify an asterisk (*) as the filter and GET, POST & PUT as actions.

4. Create new a policy and associate users who are intended to access it (IDM admin's or specific Admin users/groups) and the rule created in the previous step.

5. Submit the config changes which you made and flush Siteminder Cache.

6. Try to access the url in a fresh browser session which should prompt you for credentials.

 

Hope this helps.

 

Regards

Ashok