AnsweredAssumed Answered

Basic setup to protect WebLogic application

Question asked by Randy Galbraith on Apr 14, 2020
Latest reply on Apr 16, 2020 by Randy Galbraith

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

Outcomes