Hi Everyone,
What are the basic steps to setup RSA Access Manager to protect an application running within WebLogic? A simple overview of the steps will help me the most. In other words, no need to read beyond this point ;).
Okay, you're still reading so I must warn that you're about to enter into my fog and confused state of being.
On this adventure your character has the following equipment:
$ cat /etc/system-release
Red Hat Enterprise Linux Server release 7.7 (Maipo)
$ ./dispatcher.sh -version
Version 6.2.SP4 (Build ID: 20160603073001-0400-1383273)
$ ./aserver.sh -version
Version 6.2.SP4 (Build ID: 20160603073001-0400-1383273)
$ ./eserver.sh -version
Version 6.2.SP4 (Build ID: 20160603073001-0400-1383273)
WebLogic...
/usr/java/jdk1.8.0_131/bin/java -server...
WebLogic Server 12.2.1.2.0
The Data Adapter is an Oracle 12.2.0.1.0 database.
The RSA AxM Agent...
$ cat version.txt
RSA Access Manager Agent 5.0 for Apache 2.x-based HTTP Server[root@myhost agent-50-apache]
Apache Web Server...
$ rpm -qf /usr/sbin/httpd
httpd-2.4.6-90.el7.x86_64
The story so far (some details sanitized for public posting)... Everything starts up and runs. One can login to the Admin Console and update data as expected. If one were to comment out this line...
Include "/opt/rsa-axm/agent-50-apache/webservers/Apache_2.4.6/conf/ct-httpd.conf"
in httpd.conf, the test URL http://myhost.subdom.com/foobar works as expected. That is, Apache loads up /var/www/html/foobar/index.html and FireFox 75.0 responds as one would expect given this content...
<html>
<head>
<title>Title of Foobar Here</title>
</head>
<body onLoad="javascript:document.forms[0].submit();">
<form name="IndexPage" method="post"
action="http://myhost.subdom.com:12345/FOOBAR/login.jsp">
<input type="hidden" name="WebPubIndex" value="ToLoginJSP" />
</form>
</body>
</html>
In short, the uppercase FOOBAR application in WebLogic processes as per the content of login.jsp file.
When Include "...ct-httpd.conf" is put back in play our setup failure comes into focus. The setup in the Admin Console looks thus...
* Server Name [myhost]
Server Type [Web Server]
* Product [Apache]
* Hostname [myhost.subdom.com]
* Port [80]
Description [My Host described here]
Administrative Group [Default Administrative Group]
Visibility (*) Public
View Resources on Server
Resource Application Description
/foobar/* FOOBAR Description of FOOBAR
Application Basics
* Application Name [FOOBAR]
Description [Descripiton of FOOBAR]
Policy Conflict Resolution [Deny access when policy conflict occur
Administrative Group [zooFlinny]
Visibility (*) Public
User Basics
* User ID [randy]
First Name [Randy]
* Last Name [Galbraith]
E-mail [person@subdom.com]
Certificate DN []
Administrative Group [zooXZBarterMember]
Visibility (*) Public
We are ready to test. So start up httpd, aserver, eserver, dispatcher and weblogic. From a freshly restarted FireFox access http://myhost.subdom.com/foobar. Now we see BASIC Login dialog:
User ID: [randy]
Password: [xxx]
Pressing [ Go ] results in...
Access Denied
You are not authorized to access this resource
Contact your administrator...
What does our logs say? We ran date to track start and stop time...
$ date
Tue Apr 14 14:45:35 MST 2020
$ date
Tue Apr 14 14:48:39 MST 2020
Somewhere in those three minutes must be the story. First note there is no indication login.jsp within WebLogic was ever reached. Second note all logging has been turned up to debug levels. So not much should escape our notice.
Starting with Apache. The error_log gives positive indication from RSA Agent that things look good...
[Tue Apr 14 14:46:10.144827 2020] [suexec:notice] [pid 12345] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
ct_debug.c:1126 - Opened the log lock file: /opt/rsa-axm/agent-50-apache/webservers/Apache_2.4.6/logs/ctagent.log.lock
It concludes with a note about mpm_prefork...
[Tue Apr 14 14:48:06.738064 2020] [mpm_prefork:notice] [pid 39239] AH00170: caught SIGWINCH, shutting down gracefully
The access_log is more interesting...
10.x.x.x - "" [14/Apr/2020:14:46:53 -0700] "GET /foobar HTTP/1.1" 302 230...
This 302 redirect brings up the login dialog...
10.x.x.x - "" [14/Apr/2020:14:46:53 -0700] "GET /cleartrust/ct_logon_en.html HTTP/1.1" 200 2230...
A series of 200 responses show axmStyles.css, AxM-logo.png and other artifacts being sent to FireFox...
The second 302 redirect shows favicon.ico...
10.x.x.x - "" [14/Apr/2020:14:46:53 -0700] "GET /favicon.ico HTTP/1.1" 302 230...
finally access_log concludes with the denied reference...
10.x.x.x - randy... "GET /cleartrust/ct_access_denied_en.html HTTP/1.1" 200...
Lets move over to RSA Agent...
ctagent.20200414144610.log has lot of detail. It begins with...
2020-04-14 14:46:10 -0700 - [4269250688] - <Info> - tracing initialized, level = 2
2020-04-14 14:46:10 -0700 - [4269250688] - <Info> - proxy tracing initialized
2020-04-14 14:46:10 -0700 - [4269250688] - <Debug> - Initializing request data tables
the first reference to /foobar is on line 666 (hmmm, that's ominous)
2020-04-14 14:46:53 -0700 - [4269250688] - <Info> - Incoming request: /foobar
by line 738 the Agent appears to report /foobar as a protected resource...
2020-04-14 14:46:53 -0700 - [4269250688] - <Info> - Result map: RETURN_CODE\nPROTECTED_RESOURCE
After some log comments about CT_AUTH_BAD_USERNAME (which one would assume means the user is not yet known) we see this...
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - ... returning: CT_AUTH_BAD_USERNAME, request handled: TRUE
2020-04-14 14:46:53 -0700 - [4269250688] - <Info> - return 302
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - [ct_post_process]
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - Status: 302 Unknown Reason
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - Contents of table: "request output headers"
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - WWW-Authenticate ==> Basic realm="CT"
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - Set-Cookie ==> ACTSESSION=[base64 for http://myhost.subdom.com:80/foobar]%3D%3D; domain=.myhost.subdom.com; path=/
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - Location ==> /cleartrust/ct_logon_en.html
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - Content-Length ==> 230
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - Keep-Alive ==> timeout=5, max=100
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - Connection ==> Keep-Alive
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - Content-Type ==> text/html; charset=iso-8859-1
Now the log continues to show artifacts for login dialog being tested and accepted. Artifacts like /cleartrust/images/button/bg_buttomrow.png
By line 1706 we see our favicon.ico reference...
2020-04-14 14:46:53 -0700 - [4269250688] - <Info> - Incoming request: /favicon.ico
For this test favicon.ico was deleted from the server.
This seems interesting...
2020-04-14 14:46:53 -0700 - [4269250688] - <Debug> - Looking for CTSESSION in ACTSESSION=aHR(more-base64-data)
2020-04-14 14:46:53 -0700 - [4269250688] - <Info> - Could not find CTSESSION in cookies header
Is the lack of a shared secret the problem? Here is what the log says...
2020-04-14 14:47:31 -0700 - [4269250688] - <Debug> - Previous user: (null), current user: randy
2020-04-14 14:47:31 -0700 - [4269250688] - <Debug> - First authentication mode: basic
2020-04-14 14:47:31 -0700 - [4269250688] - <Debug> - Next authentication mode: basic
2020-04-14 14:47:31 -0700 - [4269250688] - <Debug> - Checking whether this is enroll page
2020-04-14 14:47:31 -0700 - [4269250688] - <Debug> - Attempting authentication: basic
2020-04-14 14:47:31 -0700 - [4269250688] - <Debug> - Checking authentication with mode: basic
2020-04-14 14:47:31 -0700 - [4269250688] - <Info> - No share secret specified, User password will not be set in the token.
2020-04-14 14:47:31 -0700 - [4269250688] - <Debug> - Session is NULL
2020-04-14 14:47:31 -0700 - [4269250688] - <Debug> - User: randy
2020-04-14 14:47:31 -0700 - [4269250688] - <Debug> - Previous user: (null)
2020-04-14 14:47:31 -0700 - [4269250688] - <Info> - User: randy
2020-04-14 14:47:31 -0700 - [4269250688] - <Info> - Authentication type: 1
By line 2266 we see the failure report...
2020-04-14 14:47:32 -0700 - [4269250688] - <Security> - User randy is not authorized for resource /favicon.ico
There is lots of detail above this, but none clearly indicates to me why this is the case.
Turning to aserver.log we have a much smaller report. It ends with (we'll add line breaks for readability)...
sequence_number=7,
date=2020-04-14 14:46:53:500 MST,
messageID=2006,
webserver=myhost,
URI=/foobar,
client_ip_address=10.x.x.x,
client_port=12345,
result_code=20,
result_action=Check Resource,
result_reason=Protected Resource
sequence_number=8,
date=2020-04-14 14:46:53:882 MST,
messageID=2006,
webserver=myhost,
URI=/favicon.ico,
client_ip_address=10.x.x.x,
client_port=12345,
result_code=20,
result_action=Check Resource,
result_reason=Protected Resource
sequence_number=9,
date=2020-04-14 14:47:32:125 MST,
messageID=2010,
user=randy,
client_ip_address=10.x.x.x,
client_port=12345,
browser_ip_address=10.x.x.x,
result_code=0,
result_action=Authentication Success,
result_reason=Valid User
sequence_number=10,
date=2020-04-14 14:47:32:160 MST,
messageID=1012,
user=randy,
webserver=myhost,
URI=/favicon.ico,
client_ip_address=10.x.x.x,
client_port=12345,
browser_ip_address=10.x.x.x,
result_code=11,
result_action=Authorization Failure,
result_reason=Passive Deny
Despite the best efforts of the Hobbits, Smaug has retained his secrets. He will not let "randy" pass!
Thanks for any who respond. It is much appreciated.
Kind regards & stay safe,
-Randy
Good morning Ian,
Good news -- I found my issue. I had been in the habit of testing /foobar without the RSA Agent in play, then with. This resulted in success then failure. Of all dumb things... it finally dawned on me to test /foobar/ (note the trailing slash). That was the key. Given the URL resource was defined as /foobar/* it should been obvious.
I will investigate the entitlements server test feature you mention. I assume how to use this is documented in PDFs. My next tasks are to invoke our custom login screen and ensure ct_remote_user winds up in the HTTP headers. When all this works I'll have captured in a sandbox the entire production working state but with all components of the stack upgraded.
Kind regards & stay safe,
-Randy