AnsweredAssumed Answered

Cause of basic login dialog

Question asked by Randy Galbraith on May 6, 2020
Latest reply on May 11, 2020 by Ian Staines

Like • Show 0 Likes0
Comment • 5

Hi Everyone,

I have configured RSA Access Manager to protect two URLs. The first one works the second one does not. I have tried to configure both in exactly the same way.

My authentication flows through a custom login dialog. When I go to the first URL I am prompted for a user name and password by my custom login dialog. If I provide correct credentials I can see the content. That is, the Apache access_log shows http code 200 for all the artifacts needed to display the page.

When I go to the second URL it begins well. I'm prompted for user id and password in my custom login dialog. When I provide the correct credentials, alas, I see a basic login from Firefox:

Authentication Required - Mozilla Firefox

http://mywebsite.com is requesting your user name and password. The site says: "CT"

The access_log shows a 401 code. The headers sent to Firefox show WWW-Authenticate: Basic realm="CT"

The URL that works is a simple website (actually the content of the RSA developer's guide). The URL that does not work is hosted in WebLogic. Apache is running the WebLogic proxy that makes these resources appear to local to Apache.

How can I configure Access Manager to suppress this basic dialog (i.e. stop sending WWW-Authenticate: Basic header)? Please note: If I answer the basic dialog I get another one with a realm reference of "weblogic". If I answer that, Firefox displays: Error 401--Unauthorized

Kind regards. Please stay safe.

-Randy

Ian Staines

May 11, 2020 2:57 PM

Correct Answer

The header "CT_REMOTE_USER" (or the deprecated version "CT-REMOTE-USER" Note1) is a custom user header that is not used directly by RSA Access Manager in any way. It is used by legacy applications for SSO.

This fits with your description of the problem. It sounds like your custom application was looking for a specific header to pass the SSO user. Without this header your custom application was not identifying this as an authenticated user and the application (Weblogic) was prompting for additional authentication. RSA Access Manager was not directly configured to cause the authentication challenge.

This is not a problem with the RSA Access Manger agent, but a configuration requirement specific for your custom application.

Note1 The naming of this header is completely arbitrary but historically (for no real good reason) the name used by legacy third party integrations was originally CT_REMOTE_USER. There are problems with this name for some web servers as the underscore character is converted or not preserved in some use cases. You can use any name and we recommend avoiding underscore.

See the reply in context

No one else had this question

Outcomes

Ian Staines

May 7, 2020 11:00 AM

RSA Access Manager of course cannot "suppress" the authentication dialog of any product including WebLogic. If you have WebLogic configured to require authentication then it will require authentication. RSA Access Manager is an additional authentication source on top of whatever native authentication method you have enabled on the underlying application server. In your deployment, RSA Access Manager is not even installed on Weblogic. RSA Access Manager has no knowledge that WebLogic even exists.

You have two potential paths, you can disable all authentication on WebLogic and allow all content to be served without authentication and defer to RSA Access Manager to protect your content.

Or you an enable SSO between RSA Access Manager and WebLogic.

So there is no answer to your question. You cannot configure RSA Access Manger to suppress the authentication of another product

Actions

Randy Galbraith @ Ian Staines on May 7, 2020 12:07 PM

Good morning Ian,

Fair enough. However, it does not appear WebLogic is the one inserting this requirement. When I remove RSA Agent from Apache (i.e. comment out ct-httpd.conf) and re-run the test these resources are available without prompting. That is, neither the dev_guide resources or the WebLogic jsp item is inserting a WWW-Authenticate: Basic header.

Perhaps a better question would be:

Assuming Access Manager is responsible for inserting a WWW-Authenticate: Basic header, that in turn result in a browser-based login dialog, that the user cannot satisfy, how can this be avoided?

Since posting my question I have read this RSA Link item:

000016231 - Access Manager Basic Authentication fails for SunOne reverse proxy failover.

The resolution there suggested this setting:

cleartrust.agent.set_basic_auth_header=False

When I did that the basic login dialog did indeed go away. Alas, credentials needed by the application were not available so I am still in a failed state[1]. I am also unsure if this =False really fixes the issue or is masking a more fundamental configuration issue.

Kind regards. Please stay safe.

-Randy

[1] I will be researching this next.

Actions

Ian Staines

@ Randy Galbraith on May 8, 2020 11:33 AM

I think it is masking more fundamental configuration issues.

I don't think it is practicable to troubleshoot this kind of issue in a forum. I suggest you open a support ticket if you need general assistance.

I can try to answer specific questions here.

Actions

Randy Galbraith @ Ian Staines on May 8, 2020 7:35 PM

Hi Ian,

Good news! The flow that I've been trying to make work finally came together this afternoon. The =False change does seem to be required. None of my testing shows it to be a problem. So I will assume it is okay. This was the code change that allow the flow to work:

- String userID = request.getHeader("ct_remote_user");
+ String userID = request.getHeader("ct-remote-user");

I had noticed for sometime that our code used underscores whereas the default configuration shows dashes. But it was only with the =False change in place that I could clearly see the user id was not being found due to the underscore issue. I have no idea why our source code had this issue. After many months of work it was wonderful to see the flow finally work as expected. Thank you for all the many times you responded.

Kind regards. Please keep safe.

-Randy

Actions

Ian Staines

@ Randy Galbraith on May 11, 2020 2:57 PM

This is not a problem with the RSA Access Manger agent, but a configuration requirement specific for your custom application.

1 person found this helpful

Actions

5 Replies

Ian Staines May 7, 2020 11:00 AM
Mark Correct
Correct Answer
RSA Access Manager of course cannot "suppress" the authentication dialog of any product including WebLogic. If you have WebLogic configured to require authentication then it will require authentication. RSA Access Manager is an additional authentication source on top of whatever native authentication method you have enabled on the underlying application server. In your deployment, RSA Access Manager is not even installed on Weblogic. RSA Access Manager has no knowledge that WebLogic even exists.

You have two potential paths, you can disable all authentication on WebLogic and allow all content to be served without authentication and defer to RSA Access Manager to protect your content.

Or you an enable SSO between RSA Access Manager and WebLogic.

So there is no answer to your question. You cannot configure RSA Access Manger to suppress the authentication of another product
Like • Show 1 Like1
Actions
- Randy Galbraith @ Ian Staines on May 7, 2020 12:07 PM
  Mark Correct
  Correct Answer
  Good morning Ian,
  
  Fair enough. However, it does not appear WebLogic is the one inserting this requirement. When I remove RSA Agent from Apache (i.e. comment out ct-httpd.conf) and re-run the test these resources are available without prompting. That is, neither the dev_guide resources or the WebLogic jsp item is inserting a WWW-Authenticate: Basic header.
  
  Perhaps a better question would be:
  
  Assuming Access Manager is responsible for inserting a WWW-Authenticate: Basic header, that in turn result in a browser-based login dialog, that the user cannot satisfy, how can this be avoided?
  
  Since posting my question I have read this RSA Link item:
  
  000016231 - Access Manager Basic Authentication fails for SunOne reverse proxy failover.
  
  The resolution there suggested this setting:
  
  cleartrust.agent.set_basic_auth_header=False
  
  When I did that the basic login dialog did indeed go away. Alas, credentials needed by the application were not available so I am still in a failed state[1]. I am also unsure if this =False really fixes the issue or is masking a more fundamental configuration issue.
  
  Kind regards. Please stay safe.
  -Randy
  [1] I will be researching this next.
  Like • Show 0 Likes0
  Actions
  - Ian Staines @ Randy Galbraith on May 8, 2020 11:33 AM
    Mark Correct
    Correct Answer
    I think it is masking more fundamental configuration issues.
    
    I don't think it is practicable to troubleshoot this kind of issue in a forum. I suggest you open a support ticket if you need general assistance.
    
    I can try to answer specific questions here.
    Like • Show 1 Like1
    Actions
    - Randy Galbraith @ Ian Staines on May 8, 2020 7:35 PM
      Mark Correct
      Correct Answer
      Hi Ian,
      
      Good news! The flow that I've been trying to make work finally came together this afternoon. The =False change does seem to be required. None of my testing shows it to be a problem. So I will assume it is okay. This was the code change that allow the flow to work:
      
      - String userID = request.getHeader("ct_remote_user");
      + String userID = request.getHeader("ct-remote-user");
      
      I had noticed for sometime that our code used underscores whereas the default configuration shows dashes. But it was only with the =False change in place that I could clearly see the user id was not being found due to the underscore issue. I have no idea why our source code had this issue. After many months of work it was wonderful to see the flow finally work as expected. Thank you for all the many times you responded.
      
      Kind regards. Please keep safe.
      -Randy
      Like • Show 0 Likes0
      Actions
      - Ian Staines @ Randy Galbraith on May 11, 2020 2:57 PM
        Unmark Correct
        Correct Answer
        The header "CT_REMOTE_USER" (or the deprecated version "CT-REMOTE-USER" Note1) is a custom user header that is not used directly by RSA Access Manager in any way. It is used by legacy applications for SSO.
        
        This fits with your description of the problem. It sounds like your custom application was looking for a specific header to pass the SSO user. Without this header your custom application was not identifying this as an authenticated user and the application (Weblogic) was prompting for additional authentication. RSA Access Manager was not directly configured to cause the authentication challenge.
        
        This is not a problem with the RSA Access Manger agent, but a configuration requirement specific for your custom application.
        
        Note1 The naming of this header is completely arbitrary but historically (for no real good reason) the name used by legacy third party integrations was originally CT_REMOTE_USER. There are problems with this name for some web servers as the underscore character is converted or not preserved in some use cases. You can use any name and we recommend avoiding underscore.
        1 person found this helpful
        Like • Show 1 Like1
        Actions

Cause of basic login dialog

Outcomes

Related Content

Recommended Content