Hi out there
We are running a RSA AM 8.1 appliance and need to publish the selfservice portal of it trough a F5 LB to the internet. This should be a trivial task but I have not succeded yet in getting it working. Has anyone out there succeded in this - and if so - is there a irule they could share or explain how they did?
Has anyone spotted where the log-file for the webserver servicing the SelfService portal is located?
br /thomas iwang
Hi Thomas,
You would be better to use the Webtier behind the F5, rather than having the F5 going directly to the SSC on the RSA, since the ports are the same for the Security Console and Self Service Console. Unless you are blocking access to the URI /sc (console-ims) on the F5.. Otherwise you would be publishing your security console on the internet!
If that is not an option you can use an F5 policy (Depending on the version of F5 you are running) to perform a redirect based on the URI and omit the port from the client side.
The F5 would need to have a certificate in order to see inside the SSL traffic.
This could be a public cert on the ClientSSL profile and the default cert on the ServerSSL profile assigned to the virtual server.
To get more info as to what is going on it would also be an idea to run tcpdump on the F5 for both the client side and server side traffic.
Regards
Steve
hi steve & jay
I have a irule which solely permits access to selfservice - it is to awoid more servers to maintain that we try to avoid the webtier for a extra webserver.
I had a setup running in a test env where it looks as if everything works but when I then try to implement the same rule on the prod env it looks to me as if the AM tear's down the session from the F5 as soon as the user tries to log in. The difference there could be that on my test env we are running AM 8.0 and the F5 is at ver 11.6 whereas in the prod env we have AM8.1 and the F5 running at 11.4.
There has been other which have had issues with the cipher strings they exchange but it looks to me as if these should be supported on both sides (at least when I test with OpenSSL)
I have faced a small problem in decrypting the communication between the F5 and AM (hmmm - tls - not that simple as ssl)
Right now I am upgrading the RSA server to version 8.2 (because of problems with FF and Chrome) so I see if I am so lucky that it also solved my problem with the Selfservice console.
But - the webserver used by the AM for all these consoles - and espcially the self service console - hasn't some found where it logs the activity? there might be a simple reason which is logged there why my little irule breaks down when trying to publish the server and it might be logged there in cleartext....
br /ti
Depending on version of AM 8.1 this could be an SSL protocol or Cipher disagreement.
There's a blog entry explaining some of this,
https://community.rsa.com/community/products/securid/blog/2017/02/27/ssl-protocols-rc4-ciphers-and-authentication-manager
and the attached PowerPoint goes into some detail
Basically AM 8.1 SP1 base (no patches) does not support TLSv1.2, which later versions of browsers might require. You need at least AM 8.1 SP1 Patch 3.
At AM 8.1 SP1 P13 and later there is also a command to limit any protocol less than TLSv1.2, with a strict_TLS script.
Pre-AM 8.2 supports several RC4 Ciphers, while AM 8.2 no longer supports those, so it might be something like that.
hi again
In the meanwhile I have located the logfiles for the console-selfservice part - I thnk - which logs these errors:
@@@2017-03-08 14:01:32,542 WARN [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] GUILog.traceMessage(770) | <class:CSRFFilter> Both nonce and CSRF token (from request) are missing from URL: /console-selfservice/error.jsphttps://rsa.local:7004/console-selfservice/error.jsp, referrer: https://rsaselfservice.external.com/
@@@2017-03-08 14:05:46,682 FATAL [[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] GUILog.traceMessage(794) | There is an exception during CSRF validationhttps://rsa.local:7004/console-selfservice/Home.do, referrer: https://rsaselfservice.external.com/console-selfservice/TokenError.jsp
@@@2017-03-08 14:05:46,682 ERROR [[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] GUILog.traceException(587) | exception:
javax.servlet.ServletException: Failed to validate request.
at com.rsa.ims.sso.filter.SSOFilter.checkAccess(SSOFilter.java:996)
at com.rsa.ims.sso.filter.SSOFilter.doFilter(SSOFilter.java:574)
at com.rsa.ucm.web.selfservice.common.SelfserviceSSOFilter.doFilter(SelfserviceSSOFilter.java:99)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
at com.rsa.ui.common.filter.I18NFilter.doFilter(I18NFilter.java:96)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
at com.rsa.ui.common.security.csrf.CSRFFilter.doFilterInternal(CSRFFilter.java:199)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3431)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3397)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2280)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2196)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2174)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1575)
at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:255)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)
Caused by: com.rsa.command.AuditedLocalizableSystemException: COMMAND_EXECUTION_UNEXPECTED_ERROR
Caused by: com.rsa.common.SystemException: Access denied. The authentication request was routed through a load balancer/Proxy server that is not recognized by the system.
at com.rsa.ims.sso.service.CheckAccessCommand.performExecute(CheckAccessCommand.java:180)
at com.rsa.command.LocalTarget.executeCommand(LocalTarget.java:119)
tell me - do I need to add the F5's inside as a LB to the system since it trows this error:
The authentication request was routed through a load balancer/Proxy server that is not recognized by the system.
br /thomas iwang
Hi Thomas,
From the message:
Access denied. The authentication request was routed through a load balancer/Proxy server that is not recognized by the system.This means the address of your load-balancer is not recognized by Authentication Manager. In the Operations Console, you need to provide the address(es) of you load-balancers through the "Deployment Configuration -> Virtual Host & Load Balancing" interface...
This is required to have Authentication Manager accept the IP address of the source system from the HTTP header of the incoming request. The load-balancer should be configured to be adding to the "X-Forwarded-For" HTTP header.
Hi Thomas,
We're also trying to achieve something similar. Were you successful with this configuration?
Regards,
Lochan.
Hi there
Well - my biggest problem is/was probably that I didn't knew the rsa appliance deeply enough to see what went wrong
I go for a webtier in a dmz but in fact I would expect it to work simply by adding the f5 as load balacer - this was my primary problem - and then use some simple irules to rewrite the port - that should also work (had it working in a small lab on my labtop)
Br /ti
I think Chris Salvati here in Support has done this once, an F5 directly in front of the Self Service Console, but I do not the details.
I've worked with a customer who had an AM Web Tier in front of the AM Self Service Console, SSC & for CTKIP, who then had an F5 in front of the Web Tier. We figured out how to export the private key for the Web Tier, so that the F5 could terminate the SSL connections before talking to Web Tier, which uses an Admin connection to AM to do things like the SSC or CTKIP.
If you search on RSA Link at the top for "How to export Private" the second choice was this KB, link here
https://community.rsa.com/docs/DOC-45500