Layer7 Access Management

Tech Tip : CA Single Sign-On :: CA Access Gateway::Introduction to the Redesigned Enhanced Session Assurance (12.6/12.7)

By Ujwol posted 03-23-2017 12:06 AM

  

Summary:

The Enhanced Session Assurance with DeviceDNA™ has been completely redesigned in r12.6.

In this blog we will discuss about this new redesigned architecture, compare it with old architecture and also review the steps required to configure it in the new design.

Environment:

  • Policy Server : R12.6
  • CA Access Gateway : R12.6 

So what has changed ?

 

To understand this, let's see what the earlier design was.

The existing design of session assurance implementation relied on following components :

Policy Server

  • CA RiskMinder Service (aka CA Advanced Authentication Server)

CA Access Gateway

  • Session Assurance Flow App - This App interacts with the Policy server using AgentAPI. This also interacts with CA RiskMinder services via JDBC-ODBC bridge.

 

 

Problems with the existing design

  • Heavy footprint of CA Advanced Authentication components on both Policy server and CA Access Gateway servers.
  • Difficult to maintain Resource.dat & Master Key file.
  • Complex PS/Access Gateway upgrade path

 

The New Design

  • Removed CA Advanced Authentication components on Policy server.
  • Simplified Session Assurance Flow App on CA Access Gateway by developing it using CA Advanced Authentication SDK.

 

 

What this now mean is:

  • Advanced Authentication Server is not installed on the Policy Server.
  • Default domain “AdvAuthDEFAULTORG” and host configuration objects those were created in previous releases for use of Advanced Auth Server are no more created.
  • No Master Key.
  • DSN for Advanced Authentication Server is not created on PS & CA Access Gateway
  • Resource.dat is not created in Policy server/bin directory.
  • Previously deployed web apps - uiapp, aaloginservice,authapp is now replaced with just one new "sessionassuranceapp" on CA Access Gateway. 

 

How do I configure Session Assurance  now?

Following are the steps required to configure session assurance now :

 

CA Access Gateway

  • Install CA Access Gateway 12.6
  • Configure CA Access Gateway to use SSL for front end Apache
  • Ensure SessAssurance Application is enabled in server.conf :
<Context name="SessionAssuarance Application">
docBase="sessionassuranceapp"
path="authapp"
enable="yes"
</Context>
  • Ensure SACExt ACO parameter value is .sac  

  • Ensure IgnoreExt ACO parameter contains .sac extension

 

 

CA SSO Policy Server

 

  • Install CA SSO Policy server to 12.6
  • Create Session Assurance End Point as below :

 

  • Enable Session Server on the Policy server. 

  • Add Session Assurance End Point to the realm for which you want to enable the session assurance functionality.

(It is optional to configure realm as persistent)

 

Configure Log Files for Troubleshooting

 

1. Enable Audit Logs and also configure Enable Enhanced Tracing on the Policy server.

Navigate to following in the registry editor :

HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\Reports

Add following dword :

"Enable Enhance Tracing"=1The Audit logs contains authentication and authorisation activity related to Session Assurance flow.

2. Enable debug logging for Session Assurance Flow app on CA Access Gateway

Navigate to CA\secure-proxy\Tomcat\webapps\sessionassuranceapp\WEB-INF\classes and set the log level to DEBUG in log4j.properties as below:

# Define the root logger with appender SAFileAppender
log4j.rootLogger = DEBUG, SAFileAppender
# Set the appender named SAFileAppender to be a File appender
log4j.appender.SAFileAppender=org.apache.log4j.FileAppender
log4j.appender.SAFileAppender.File=${catalina.base}/../proxy-engine/logs/SessionAssuranceApp.log
log4j.appender.SAFileAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.SAFileAppender.layout.conversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:- %m%n

 

Testing:

 

 

Additional Information:

Configure Enhanced Session Assurance with DeviceDNA™ - CA Single Sign-On - 12.6.01 - CA Technologies Documentation 

5 comments
0 views

Comments

06-30-2018 09:20 PM

Most likely no. There are multiple redirections back and forth to session assurance (AG) , only webagent/AG is aware of these.

06-30-2018 04:17 PM

Hello,

 

Would be possible to use session assurance with an application not integrated with webagent but using the webservices feature from Access Gateway (authazws)?

Something like the following flow:

Application (user enter credentials) -> webservice (authazws) -> return smsession to application -> application set smsession cookie on user's browser -> application call another session_assurance_flow.html -> session assurance validates user's session -> application allow access

 

Thanks!

02-15-2018 07:04 PM

Hi Makesh,

 

Please find my comments below.

 

1. In my customer environment, there are 100+ domains, 25+ fed partnerships. I understand that enabling session assurance feature does requires a session store. Are there any performance impact enabling this feature for all domains/fed ? 

 

Ujwol => Yes, enabling session assurance defintely has performance overhead as it involves extra steps :

  • Collecting machine fingerprint (deviceid)
  • Storing device and session information in Session store
  • Redirection back and forth between web agent and AG

 

2. . Few of our applications are using ACO "SSOTrustedZone", and few applications are AJAX based. I see that session assurance doesnt work with these settings. What will be the impact if i enable this feature for some of domains/fed partnership but not all, will there be any unexpected error/behavior during the login flow or during SSO flow (when switching between session assurance enabled realms VS non session assurance realms ? 

 

Ujwol => 

Tested this.

  • SS enabled to SS disabled - worked fine no issues.
  • SS disabled to SS enabled -

Tried two use cases :

1) SS disabled + non persistent realm --> SS Enabled

It reachallenged me with following error in agent trace log :

[02/16/2018][10:57:19][3360][2060][CSmLowLevelAgent.cpp:1010][AuthenticateUser][000080fe00000000ff040000cd6840fe-0d20-5a861e5f-080c-01d724f4][*155.35.245.67][][agent-shruj01-i3842][/ss/][shruj01@ca.com][Validating session 'd1XcvvTOiqF61KYDOTN/gqp1Wcw=' for user 'CN=Ujwol Shrestha,CN=Users,DC=ad12,DC=lab' in zone 'SM'.]
[02/16/2018][10:57:19][3360][2060][CSmLowLevelAgent.cpp:1089][AuthenticateUser][000080fe00000000ff040000cd6840fe-0d20-5a861e5f-080c-01d724f4][*155.35.245.67][][agent-shruj01-i3842][/ss/][shruj01@ca.com][Failed to validate session '' for user 'CN=Ujwol Shrestha,CN=Users,DC=ad12,DC=lab' in zone 'SM'.]
[02/16/2018][10:57:19][3360][2060][CSmLowLevelAgent.cpp:1346][AuthenticateUser][000080fe00000000ff040000cd6840fe-0d20-5a861e5f-080c-01d724f4][*155.35.245.67][][agent-shruj01-i3842][/ss/][shruj01@ca.com][User 'CN=Ujwol Shrestha,CN=Users,DC=ad12,DC=lab' is not authenticated by Policy Server.]

 

2) SS disabled + persistent realm --> SS enabled realm. 

This failed too, and rechallenged me.

agent trace log :

[02/16/2018][11:12:04][5412][1484][CSmLowLevelAgent.cpp:1010][AuthenticateUser][000080fe00000000ff040000cd6840fe-1524-5a8621d4-05cc-03cf54de][*155.35.245.67][][agent-shruj01-i3842][/ss/][shruj01@ca.com][Validating session 'VIofSUIpECp9allVbAWfu+DvlWA=' for user 'CN=Ujwol Shrestha,CN=Users,DC=ad12,DC=lab' in zone 'SM'.]
[02/16/2018][11:12:04][5412][1484][CSmLowLevelAgent.cpp:1089][AuthenticateUser][000080fe00000000ff040000cd6840fe-1524-5a8621d4-05cc-03cf54de][*155.35.245.67][][agent-shruj01-i3842][/ss/][shruj01@ca.com][Failed to validate session '' for user 'CN=Ujwol Shrestha,CN=Users,DC=ad12,DC=lab' in zone 'SM'.]
[02/16/2018][11:12:04][5412][1484][CSmLowLevelAgent.cpp:1346][AuthenticateUser][000080fe00000000ff040000cd6840fe-1524-5a8621d4-05cc-03cf54de][*155.35.245.67][][agent-shruj01-i3842][/ss/][shruj01@ca.com][User 'CN=Ujwol Shrestha,CN=Users,DC=ad12,DC=lab' is not authenticated by Policy Server.]

 

PS trace log :

[02/16/2018][05:42:04][2124][000080fe00000000ff040000cd6840fe-1524-5a8621d4-05cc-03cf54de][Sm_Auth_Message.cpp:2674][CSm_Auth_Message::ValidateUser][][][VIofSUIpECp9allVbAWfu+DvlWA=][][][][][2][/ss/][][IIS_shruj01-i3842][Validate session and session type for the user.][1712][05:42:04.749][][][SessionAssurance][][][agent-shruj01-i3842][][][][][][][][][][HTML_OOTB_LOGINFCC][][][][G7UT4D+RDrgZ+ZUkC2ZnNU9N4XLoak/qCop8pgBvwBz/3ahuBDSKLx4DssAbMzOiXvMTToafK73xYtPG7oFFqGfcZBPWbqKVKRlgEnFeY/3qQiEmMa9TjUubiXZTxVVOEPkzHL988tNyvlilixiG6jKjuxt5M4AT4c0UOnoscFEjs9iskt+SWpdAPEDb4OPr/xpHSRcKvXij0H2rjpYGH0xueNywsqN5KUekAKa8ek/ETa/5dFXpbvD1ujR44fXqSU7ci/TxfB2niYfiUMTiOlcyRvtzH7b00Jm8x69RCUG3bP3ScqywtHIM8++dJVqGw5e147uHxrrl9SDBI0SgG+0LV8l1H3mQYPKTMc9Btfx57kIt/imYjV4iUQlA+gdhediiK4Iv/H55SJZPsw3S3hkQr4DxpSMWiAYZaf/fNgMU9ehmkuiL2ng8j7F6r4qX7zU2mgBHmz1xls+KYqpZ4w==][][06-d441cce3-1beb-416f-8ee2-1f66caefc30e][][][][][][][][][][][][][][][][][][][][][][][][]
[02/16/2018][05:42:04][2124][][Sm_Auth_Message.cpp:4425][CSm_Auth_Message::SendReply][][][][][][][][][][][][Enter function CSm_Auth_Message::SendReply][1712][05:42:04.749][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
[02/16/2018][05:42:04][2124][][SmAuthHtml.cpp:114][SmAuthQuery][][][][][][][][][][][][Enter function SmAuthQuery][1712][05:42:04.749][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
[02/16/2018][05:42:04][2124][][SmAuthHtml.cpp:157][SmAuthQuery][][][][][][][][][][][][Use Relative Target enabled for HTML form Scheme][1712][05:42:04.749][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
[02/16/2018][05:42:04][2124][][SmAuthHtml.cpp:241][SmAuthQuery][][][][][][][][][][][][Leave function SmAuthQuery][1712][05:42:04.749][0][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][00:00:00.000000][]
[02/16/2018][05:42:04][2124][s42/r16][Sm_Auth_Message.cpp:5262][CSm_Auth_Message::FormatAttribute][][][][][][][][....][][][IIS_shruj01-i3842][Send response attribute 212, data size is 4][1712][05:42:04.749][][][SessionAssurance][][][agent-shruj01-i3842][][][][][][][][][][HTML_OOTB_LOGINFCC][][][][][][06-d441cce3-1beb-416f-8ee2-1f66caefc30e][][][][][][][][][][][Login][00 00 00 02 ][][][][][][][][][][][][]
[02/16/2018][05:42:04][2124][s42/r16][Sm_Auth_Message.cpp:5262][CSm_Auth_Message::FormatAttribute][][][][][][][][Invalid session type][][][IIS_shruj01-i3842][Send response attribute 158, data size is 20][1712][05:42:04.749][][][SessionAssurance][][][agent-shruj01-i3842][][][][][][][][][][HTML_OOTB_LOGINFCC][][][][][][06-d441cce3-1beb-416f-8ee2-1f66caefc30e][][][][][][][][][][][Login][49 6e 76 61 6c 69 64 20 73 65 73 73 69 6f 6e 20 74 79 70 65 ][][][][][][][][][][][][]
[02/16/2018][05:42:04][2124][s42/r16][Sm_Auth_Message.cpp:4759][CSm_Auth_Message::SendReply][][][][][Invalid session type][][][][][][IIS_shruj01-i3842][** Status: Not Validated. Invalid session type][1712][05:42:04.749][][][SessionAssurance][][][agent-shruj01-i3842][][][][][][][][][][HTML_OOTB_LOGINFCC][][][][][][06-d441cce3-1beb-416f-8ee2-1f66caefc30e][][][][][][][][][][][][][][][][][][][][][][][][]

 

So in conclusion, navigation from SS disabled to SS enabled wouldnt' work.

 

3. For how long the policy server maintains this device information on session store ? Does it clean up the entries from session store periodically or do i have to run additional scripts to clean up the entries from the session store ?

 

Ujwol => Policy server maintains the device infromation in the session store as long as the session is valid. It doesn't need any extra manual cleanup. The clean up is taken care by the Policy server session server maintenance thread which deletes expired session periodically.

 

4. I see this feature is enabled by default in Access Gateway. How do i ensure that this app is working. Is there a URL to validate that this app is up and listening ?

 

Ujwol => This need trobuleshooting. Please open support ticket.

02-08-2018 07:42 PM

Thanks Ujwol for the tip.

 

I have couple of questions.

 

1. In my customer environment, there are 100+ domains, 25+ fed partnerships. I understand that enabling session assurance feature does requires a session store. Are there any performance impact enabling this feature for all domains/fed ? 

 

2. . Few of our applications are using ACO "SSOTrustedZone", and few applications are AJAX based. I see that session assurance doesnt work with these settings. What will be the impact if i enable this feature for some of domains/fed partnership but not all, will there be any unexpected error/behavior during the login flow or during SSO flow (when switching between session assurance enabled realms VS non session assurance realms ? 

 

3. For how long the policy server maintains this device information on session store ? Does it clean up the entries from session store periodically or do i have to run additional scripts to clean up the entries from the session store ?

 

4. I see this feature is enabled by default in Access Gateway. How do i ensure that this app is working. Is there a URL to validate that this app is up and listening ?

 

Is this correct URL to check if the app is running ?

https://wag1.domain.com:8443/authapp/

 

Upon accessing the above URL, it redirect to below URL with error 500 :

https://wag1.domain.com:8443/authapp/sasignaturereceive

 

Feb 08, 2018 6:02:30 PM org.apache.catalina.core.StandardWrapperValve invoke

SEVERE: Servlet.service() for servlet [SASignatureReceiver] in context with path [/authapp/] threw exception

java.lang.RuntimeException: Error during Session Assurance

        at com.ca.sa.ui.UIUtils.createRequestContext(Unknown Source)

        at com.ca.sa.ui.SASignatureReceiver.doPost(Unknown Source)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:650)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)

        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)

        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)

        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)

        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:106)

        at com.netegrity.proxy.ProxyValve.processRequest(Unknown Source)

        at com.netegrity.proxy.ProxyValve.invoke(Unknown Source)

        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)

        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)

        at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)

        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)

        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

        at java.lang.Thread.run(Thread.java:748)

03-24-2017 12:16 PM