Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > 2018 > May
2018

As a senior architect with CA Services, I collaborate with a lot of customers on their security environments. Lately, I’ve noticed that CA Access Gateway (formerly CA Secure Proxy Server), which is a component of CA Single Sign-On (CA SSO), is quickly becoming the mechanism of choice for enforcing CA SSO policies. Not only does it allow our customers to consolidate agents, which makes it easier for them to manage their environments, but it’s also their platform of choice for extending CA SSO’s functionality.

 

While our traditional CA SSO Web Agents continue to receive updates to support new platforms and ensure the security of customer environments, CA Access Gateway has seen enhancements like authentication and authorization web services, integration with Office 365, a purpose-built STS, enhanced session assurance, and most recently, services that support OAuth- and OIDC-based applications.

 

CA Access Gateway’s growing value makes it more and more important to monitor it, ensure that its performance meets SLAs, and see that it delivers the optimal customer experience. For years, CA Application Performance Management (CA APM) customers have had the benefit of an APM product that can be integrated with and is specifically dedicated to CA SSO. What has been a well-kept secret (one I’m determined to spread the word about) is that all the way back to version 12.5, CA Access Gateway could natively integrate with CA APM.

 

While CA SSO Policy Server and agents need a plug-in, CA Access Gateway needs to point to an EP agent application to report base web agent statistics, including:

  • User and resource caching
  • Bad and expired cookie hits
  • Bad URL and cross-site scripting hits
  • Standard web agent operations (Is Protected, Authorize, Validate, Logon)

 

These statistics are great for understanding the web agent side of Access Gateway, but we also need to understand the proxy’s other operations. So with this integration, CA APM can also report on:

  • The number of proxy rules files
  • SPS wait time
  • Average HTTP client time
  • Average Java web agent time
  • Average post-agent session write
  • Average proxy rule filter time
  • Average session discovery time
  • Average response time from back-end servers

 

It’s Even Simpler Than 1-2-3

Enabling the built-in monitor is as simple as a two-line change in the server.conf, where you will find the configuration fragment:

<metric-reporter name="WilyMetricReporter">

                class="com.ca.proxy.monitor.wily.WilyMetricReporter"

                enabled="no"

                endpoint="http://localhost:8886"

</metric-reporter>

1.   Change enabled="no" to enabled="yes"

2.   Change endpoint="http://localhost:8886" to endpoint="http://<EPAgent Endpoint>"

 

The endpoint can be any EP agent, although pointing it to a local EP agent would give you the rest of the local machine data. Upon restart, your enterprise manager will give performance and health data from CA Access Gateway. This enables you to baseline your performance, build alerts, and integrate the data into your performance management plans.

 

Inquiring minds want to know: Do you use APM for monitoring your CA Single Sign-On environment? If not, does it sound like a clever idea, or do you have a better idea? Let us know your thoughts!

USE CASE

How can we save custom data into session store during user authentication and access it later during authorization

The custom data could be an additional user input captured during user login or via some external web service call during custom authentication.

CHALLENGE:

Data couldn’t be saved into a session store during the authentication process (say inside a custom authentication class ) because at this stage even if the Session ID is created for the user session an entry is not created in the session store.

Otherwise a simplistic solution would have been to invoke  com.netegrity.policyserver.smapi.SmSessionServer.setVariable() API from within the custom authentication class.

SOLUTION :
  • Temporarily save the custom data into the AppSpecificContext element of the APIContext from the custom authentication scheme.
  • Create an ActiveResponse to read the custom data from the AppSpecificContext.
  • Create a Response attribute of type “WebAgent-OnAuthAccept-Session-Variable”  and assign the value returned from an ActiveResponse above.
  • Create an OnAuthAccept rule and attach the Response attribute created above.
  • Create a Response to read the data from Session Store and attach it to OnAccessAccept rule to set it as HTTP header variable.
INSTRUCTION :
  • Modify the attached custom authentication scheme class (CustomAuthSetAppSpecificContextData.java) as required to the save the desired custom data into the AppSpecificContext element as below.
1
2
3
4
5
6
7
//Set AppSpecific Context Data here. This could be a data read from external web service call or user provided input variable
try
{
APIContext apiContext = context.getAPIContext();
AppSpecificContext appContext = apiContext.getAppSpecificContext();
appContext.setData(new String("Test App Sepcific Context Data").getBytes());
}
  • (Optional ) Modify the attached custom ActiveResponse class (ReadAppSpecificContextVar.java) for any additional logic (if needed). Here is the code snippet where it reads the data from AppSpecificContext and return to the caller :
1
2
3
4
5
6
7
8
9
10
11
12
// Check if the app specific data is set
try
{
APIContext apiContext = context.getAPIContext();
AppSpecificContext appContext = apiContext.getAppSpecificContext();
byte[] data = appContext.getData();
if (data != null)
{
logInPSTrace(apiContext, "Context Data : " + new String(data));
return new String(data);
}
}
  • Create a custom authentication scheme as below :
    • Library : smjavaapi
    • Secret : Any string value
    • Confirm secret : Any string value
    • Parameter : <Custom auth classname> <custom login page>

custom authentication scheme

  • Create a Response attribute of type “WebAgent-OnAuthAccept-Session-Variable”  and assign the value returned from an ActiveResponse as below. This will be triggered during OnAuthAccept event to set the custom data into the session store.

Set Session Var Response

  • Create a Response attribute of type “WebAgent-HTTP-Header-Variable”  and assign the value read from Session Store (set earlier) as below. This will be triggered during OnAcccess event.

Response to read session var

  • Change realm to persistent, change the Authentication scheme to custom & create OnAuthAccept, OnAccessAccept rules as below :

Realm

  • Link OnAuthAccept rule and the corresponding Response to create to set custom data in session store.OnAuthAccept_policy
  • Link OnAccessAccept  rule and the corresponding Response to read the data from session store and set it as HTTP header variable OnAccessAccept_Policy
  • Compile both the custom class and deploy them to <PS_Install_directory>siteminder\config\properties
  • Restart Policy server
TEST :

PrintHeaders

ATTACHMENT :
  • Custom Auth scheme.
  • Custom Active Response.
  • Sample index.asp to print all HTTP headers.
  • SetSessionVar
INSTRUCTIONS:
  • Create a Variable of type ResourceContext as below. This stores the last accessed resource URL.Variable-ResourceContext
  • Create Response with the following two attribute :

WebAgent-OnReject-Redirect = URL where you would like the user to be redirected after Authorization Reject.

WebAgent-OnReject-Text = Configure this to read the value of the Variable created earlier. This will create a SMTEXTcookie response which will have the value of the Resource URL.

OnAccesRejectRedirect_Response

OnRejectText

OnRejectRedirect_ResponseAttribute

  • Create OnAccessReject rule for the root resource.OnAccessReject_Rule
  • Associate the OnAccessReject rule with the Response created above. OnAccessRejectPolicy_UsersOnAccessRejectPolicy_Rule
  • Configure the AZ redirect page to read the value from SMTEXT cookie :

(Below sample use class ASP )

1
2
3
4
5
6
7
8
9
10
11
12
<table border="1">
<h1 style="color:red;"> You are not authorized to access resource : <%=Request.Cookies("SMTEXT")%> </h1>
 
<%
for each x in Request.ServerVariables
response.write(x & " = " & Request.ServerVariables(x) & "<br />")
next
%>
 
</table>
</body></p>
<p style="padding-left: 30px;">

TESTING:

  1. Access resource which the user is not authroized for.AzReject
  2. Sample fiddler : 
  3. Sample fiddler + accessdenied.asp : 
USE CASE :
  • If the value of the userattribute “businessCategory” is YES, redirect the user to “/home/manager.html ” after authentication.
  • If the value of the userattribute “buesinessCategory” is not YES, redirect the user to “/home/engineer.html” after authentication.
INSTRUCTIONS :
  • Create Realm for /home/ with the following three Rules :
    • OnAuthAccept_Manager
    • OnAuthAccept_Engineer
    • GetPostRealm_Home
  • Create a Variable “IsManager” of type UserContext and configure to read the user property “businessCategory”

Variable_IsManager

  • Create a Response  “ManagerHome” and add Response Attribute of type “WebAgent-OnAccept-Redirect” to redirect to static URL  “/home/manager.html”Response_ManagerHome
  • Create a Response  “EngineerHome” and add Response Attribute of type “WebAgent-OnAccept-Redirect” to redirect to static URL  “/home/engineer.html”Response_EngineerHome
  • Create a GetPost Policy to authorize all users access to “/home/*” GetPost_Home
  • Create an OnAuthAccept_Manager Policy which compares the value of the variable “IsManager” to be “Yes” and then redirects to the ManagerHome Response.OnAuthAccept_Manager_1OnAuthAccept_Manager_2
  • Create an OnAuthAccept_Engineer Policy which compares the value of the variable “IsManager” to be not equal to “Yes” and then redirects to the EngineerHome Response.OnAuthAccept_Engineer_1OnAuthAccept_Engineer_2

 

TESTING :
  • Login as a user with value of the userattribute businessCategory=YESManager_Fiddler
  • Login as a user with value of the userattribute businessCategory=NOEngineer_Fiddler

ISSUE:

 

Policy server crashes at startup after integrating with APM 13.1

ENVIRONMENT : 

  • CA SSO 12.7 SP2
  • CA AP SSO 13.1
  • OS : Linux

 

CAUSE:

The issue was due to incorrect order of static objects were allocated and released.

 

RESOLUTION:

This is a known defect. A hot fix is available for this . Please contact CA support.

CA Internal reference : DE353289