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

Like • Show 0 Likes0
Comment • 6

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>

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

Randy Galbraith Apr 16, 2020 9:21 AM

Correct Answer

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

See the reply in context

No one else had this question

Outcomes

6 Replies

Randy Galbraith Apr 15, 2020 9:27 AM
Mark Correct
Correct Answer
Good morning everyone,

Update 4/15/2020:

Based on comments in Article Number 000025552 I added /favicon.ico to this line:

cleartrust.agent.url_exclusion_list=/cleartrust/images/*,/cleartrust/styles/*,/favicon.ico

to webagent.conf

2020-04-15 06:16:55 -0700 - [970020992] - <Security> - User randy is not authorized for resource /foobar

Although still denied references to /favicon.ico denial appear to have stopped. This is progress.

Kind regards & stay safe,
-Randy
Like • Show 0 Likes0
Actions
Ian Staines Apr 15, 2020 11:08 AM
Mark Correct
Correct Answer
In reply to your first question, what are the basic steps to protect a WebLogic Application.

Configure an RSA Access Manager Web Agent on the Apache proxy server to protect all content.
Like • Show 0 Likes0
Actions
- Ian Staines @ Ian Staines on Apr 15, 2020 11:12 AM
  Mark Correct
  Correct Answer
  I am not sure there is a direct question in the rest of your post.
  
  The aserver output indicates your user is successfully authenticated but this user does not have any resources defined that they have access to.
  
  result_action=Authorization Failure,
  result_reason=Passive Deny
  
  RSA Access Manager both authenticates and authorizes. Authentication is of course a prerequisite for authorization but you must defined entitlements in the Entitlements Manger if you want to allow access to them.
  
  For testing you may want to look at the passive/active authorization settings. By default the product is configured in (passive) mode where all entitlements are assumed to be denied unless specifically allowed. You can also configure the system in active mode where all entitlements are assumed to be allowed unless specifically denied.
  Like • Show 0 Likes0
  Actions
  - Randy Galbraith @ Ian Staines on Apr 15, 2020 12:48 PM
    Mark Correct
    Correct Answer
    Hi Ian,
    
    As always I so much appreciate your feedback & answers! Sorry, yes, I should have asked a direct question at the end of my long post. The question would be:
    
    Q1. Given the log output above, why is "randy" unable to access "foobar"?
    
    As you note "randy" passes authentication. In terms of entitlements those have been setup. At least I think they have. When I setup entitlements for "randy" to another application (devguide) and url resource (/work/axm/dev_guide/*) it works as expected.
    
    Q2. Is there something specific I should be looking for in the logs that would shine a light on entitlements misconfiguration? Assuming that is the issue.
    
    Kind regards & stay safe,
    -Randy
    Like • Show 0 Likes0
    Actions
    - Ian Staines @ Randy Galbraith on Apr 15, 2020 1:01 PM
      Mark Correct
      Correct Answer
      According to the log output this user does not have a specific entitlement to the URL foobar.
      
      For testing, create entitlements for a full directory and then test access for URL's in the location. The entitlements server has a test feature that can be used to confirm you have your entitlements setup correctly.
      Like • Show 1 Like1
      Actions
Randy Galbraith Apr 16, 2020 9:21 AM
Unmark Correct
Correct Answer
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
Like • Show 0 Likes0
Actions

Basic setup to protect WebLogic application

Outcomes

Related Content

Recommended Content