Skip navigation
All Places > CA Security > CA Single Sign-On > Blog
1 2 3 Previous Next

CA Single Sign-On

207 posts

Many organizations are migrating elements of their IT infrastructure to the cloud and adopting a “cloud first” approach. It’s a significant step for CTOs/CIOs to take, as it requires a new mindset, new tooling and has an impact on people, processes and technology.

But the rewards can be significant – lower TCO while benefiting from the cloud provider’s capabilities like easier provisioning, scalability and high availability for maintaining the support for the critical applications the business requires. Most of the savings is a result of optimizing resources for what they actually need and consume. In many cases, their on-premises capacity is likely to be over provisioned. It is also possible to provision disaster recovery environment without any capital expense. There are also advantages which result in IT teams becoming more efficient and reducing operations costs. This is because public cloud providers offer wide capabilities and tools in these areas and continually invest in them.

And not only these, organizations can become more agile, due to the use of innovative platform technologies that enable IT teams to focus on delivering business applications.

AWS (Amazon Web Services) is a market leader in this infrastructure cloud platform space and has a vast global presence.

Lower the TCO and simplify infrastructure operations of your CA Single Sign-On deployment 

 

The above-mentioned benefits apply to deploying CA SSO onto a public cloud like AWS and also, to ensure that your applications on the cloud can be securely accessed comprehensively using CA SSO capabilities. There are no capital expenses needed and there will be savings in infrastructure investment, implementation and operations. There are customers who have already deployed CA SSO on AWS, running it in production and happily reaping these benefits.

 

Running CA SSO natively on AWS gives your end users the same access and security experience that they are accustomed to, regardless of where the application is hosted - on-prem, cloud, SaaS or mobile.

 

In fact, deploying CA SSO on AWS, can be a complimentary part of the migration of workloads to AWS, accelerating more applications to be deployed and enable faster cloud adoption, simply because, it provides the necessary security controls to address complex access control use cases for AWS based resources and enable secure access to the applications in the cloud.

 

 

Before you start planning the deployment of CA SSO on AWS, there are several things to consider for an effective deployment such as availability zones, security considerations, VPC (virtual private cloud configuration), placement and settings to reduce latencies between components, based on transaction load patterns etc.

 

The following link will help you with the preliminary guidelines to be considered for deploying CA SSO on AWS - Things to consider before deploying CA SSO on AWS.

It is highly recommended to get in touch with a Broadcom services partner, to help you plan the migration, in greater detail. 

 

To summarize, following are the generally accepted benefits of running workloads in AWS.

  • Optimize cost with pay per use pricing
  • Achieve higher level of availability
  • Provision disaster recovery environment without any capital expense
  • Faster provisioning
  • Leverage the latest and greatest security updates and stay compliant and secure, with reduced operations cost.

 

 

We are continuously innovating the product to leverage the best of the breed capabilities offered by modern technologies like Kubernetes for automating deployment, scaling, and upgrades.
In fact, we already have a container validation kit for CA SSO which can be deployed on AWS EKS (Elastic Kubernetes Service) 

. Image result for AWS EKS

If you need to trial it out, please sign up for our validation project on validate.ca.com, to access the build.

Session store is required to persist user session data, authentication context data and other contextual attributes in both federation and non-federation flows. This not only provides enhanced session security but can also be applied across applications for an improved personalized experience for the end user.

 

Let’s look at some of these flows where session store deployment is required, to understand the benefits in more detail.

                                                                                                    

 

       

  1. Accomplishing Single Logout flows in SAML 2.0 and Sign-Out flows in WS-Fed. If single logout is enabled, CA SSO stores information about the user session in the session store. When a single logout request is completed, the session information for the user is removed, invalidating the session. The SLO flows help mitigate the risk of orphaned SSO sessions and hence result in higher security.
  2. Accomplishing Single Logout (SLO) flows for non-federation flows as well, by configuring a realm to have persistent sessions and short session validation period. After a Logoff, the session is removed from the session store, so if a bad actor attempts to replay a SMSESSION cookie after the validation period, the web agent will contact the policy server and find that the session is invalid and will reject the user session. So, it helps mitigate the risk of session replay and orphaned SSO sessions.

 

3. All the OpenID Connect flows that are implemented in CA Single Sign-On as an OpenID Connect Provider require the use of session store, to store OIDC specific tokens and session information. OpenID Connect is a modern identity protocol built on top of OAuth 2. It is an emerging standard for Federation and is already in wide use in Internet SSO.

 

4. In HTTP-POST single use policy flows (SAML 2.0 and WS-Federation), the relying party stores time-based data about the assertion, which is known as expiry data, in its session store. Expiry data verifies that the assertion is only used one time and hence prevents assertions from being reused at the relying party to establish a second session, in case of stolen assertions. 

 

 

 

 

 

5. Enables implementation of HTTP-Artifact Binding in SAML flows. A SAML assertion and the associated artifact are generated at the Identity Provider (IDP) and stored in session store. The artifact identifies the generated assertion. The IDP returns the artifact to the relying party. The relying party uses the artifact to retrieve the assertion, which the IDP stores in the session store. HTTP-Artifact Binding flow is designed to avoid Man-In-The-Middle attacks.

.

6. CA Single Sign-On cookie provider can be configured to store the session in a centralized session store and then pass a one-time reference to the stored session on the query string. Then the application requesting the session will have the session provided by the policy server it is communicating with instead of, directly reading it from the query string. This results in higher security, as it helps mitigate any attacker from gaining access to session data from query string directly, which is where the session data is stored if there was no session store deployed.

 

7. CA SSO utilizes a patented technology called the “Enhanced session assurance with Device DNA™”, to help mitigate the risk of session replay attacks. This capability involves uniquely fingerprinting a device in a continuous fashion, and to compare the same with the fingerprint taken at the time of login, to identify compromised sessions. Session store is required to deploy this feature in a CA Single Sign-On deployment, for storing device context and other key session information.

 

 

8. Persisting authentication context in a session store is very useful to determine the level of confidence of the transactions whether it is federation (e.g. SAML 2.0) or non- federation flows (e.g. X.509 Certificate Authentication flow)

 

9. Persisting user and session attributes is an important building block of delivering personalized experiences to your end users. This is because persisting user context not only is important for making informed entitlement decisions but also important to understand the end users.  It is possible to apply fine grained policies on the stored user context and customize the flows to build the most personalized experience. 

 

 

CA Single Sign-On supports data stores from several vendors for use as a session store. CA Directory is a battle-tested directory server that provides the scalability and reliability, for use as session store with CA Single Sign-On. And the best part is…that CA Directory license is included to all CA Single Sign-On customers for use as session store, policy and key store, free of charge! 

For more details on session store deployment, please refer to technical documentation or get in touch with Support.

In the world of digital technology, with rapid transformation of technologies supporting various business functions, you deal with disparate applications posing a variety of challenges. One such challenge of paramount importance is "Providing seamless access to users with uncompromised security".

 

What you are finding as you introduce more SaaS applications and partner applications into your topology is that each application requires user attributes in a precise format, unfortunately, is not in the same format as they exist in your user store.   You feel an identity headache coming on. The last thing you want to do is start introducing application-specific attribute schemas into your user stores.  Where would that problem end?

 

To help you avoid this headache and the associated cost of application-specific attribute proliferation, this article provides details about how you can customize the claim (attribute) formats in OIDC ID tokens produced by CA SSO.  This capability has been available for SAML assertions issued by CA SSO, but with the 12.8.02 release of CA SSO this customization capability is extended to OIDC

 

CA SSO OIDC Provider generates user claims as part of an ID token and a User info response to OIDC client applications.  Your OIDC client applications use both of these claim sources in order to authorize the user to access specific resources. 

 

Let’s see how this works by looking at an example. One of your client applications is looking for a user attribute in this format:   firstname.lastname.DoJ@department.org.com’.  The client application requires this type of user attribute value to map the user to the desired resource in order to grant access to users.   Perhaps, this format does not exist in your user store.   Instead, your user store has separate attributes firstname, lastname, DoJ and department.   To address the application’s requirement, you would need to update the user store with a new attribute in a format combining of all of these attributes. Tomorrow, some other application would ask you to provide the claim in a different format like ‘lastname_firstname@dept.region.org.com

 

To address these types of scenarios, a custom plugin in the OIDC Provider provides a flexible mid-flight method to customize attributes to the specific format expected by your client applications.

 

In the below diagram, a user tries to access SaaS applications AWS and Salesforce. Both applications expect the DoB claim in a different format.  CA SSO builds the ID token claims from a single user store.  The plugin in the CA SSO OIDC Provider supports customization of the DOB claim to the specific format that is expected by AWS and Salesforce applications.

 

 

Various other use cases for customizing claims to be carried by an OIDC ID token can be addressed by CA SSO’s OIDC Provider. For example, if you don’t want to share some claims or if you want to add a specific claim that is not available in the user store, those cases also can be  achieved with CA SSO’s OIDC Provider.  Another common use case is the need to share the same ID token with multiple OIDC client applications.  In this case, the ID token can be adjusted to add the multiple audiences with the client names on top of the default client id.

 

The code snippet below shows how to add a new claim which does not exist in the user store. The default ID token is modified with the new claim, ‘amr’, which may be a requirement for a client application.

 

@Override
 public Map<String, Object> customizeClaims(APIContext apiContext, String params, Map<String, Object> origClaims) throws PluginException {
    Map<String, Object> customClaims = new HashMap<>();
    customClaims.put("amr", "pwd");
    return customClaims;
 }

 

 

The main message here is…without changing the attribute schema in your user repository for every OIDC client application let CA SSO execute the necessary transformation (the mid-flight adjustment) saving you time, money, and the above-mentioned headache.  Your application team can focus on building their business logic and let you to manage the user attributes using CA SSO OIDC Provider to address their requirement and give your users a smooth access experience!

 

CA SSO OIDC Provider is ready for your team to onboard applications quickly and cost effectively.

 

DevOps has become a widespread practice not just to continuously integrate software in a more automated way, but it has evolved towards more continuous delivery in production. REST APIs are key enablers of these workflows in DevOps by helping with the required automations to save cost and drive agility.

 

In 12.7, We introduced REST APIs for Policy Object administration which allows you to create, read, update, and delete objects including SAML 2.0 federation entities and partnerships, and certificate services in the policy store.

With the support of REST APIs provided in 12.7 onwards, it is possible to automate common administration tasks that are typically done using CA Single Sign-On Administrative UI interactively. You can script the entire operation, completely avoiding manual intervention and saving time.

For example, if you had to edit a partnership manually in the UI today, you would have to navigate to the required screen sequentially and then edit it. But the same with a REST API is very straightforward and simple. Basically, it accelerates the procedure and saves a lot of time.

 

The REST APIs and the REST API interactive reference documentation are available from any server hosting the CA Single Sign-On Administrative UI. The REST API interactive reference documentation provides an overview of the CA Single Sign-On REST APIs. For detailed information from which you can visualize and interact with the API resources, access the REST API interactive reference documentation in the following location:

 

https://<adminui_host>:8443/ca/api/sso/services/v1/api-doc/

 

You can also open the interactive reference documentation by clicking the REST APIs link at the bottom of the Administrative UI.

 

 

CA Single Sign-On provides the following REST APIs:

 

Administrative Token API (/ca/api/sso/services/login/v1/token)
This API needs to be used to retrieve a JWT token containing a session ticket.


Policy Data API (/ca/api/sso/services/policy/v1/...)
The Policy Data API allows you to create, read, update, and delete CA Single Sign-On objects in your policy store.
Each call to the Policy Data API requires a valid JWT Token obtained from the Administrative Token API as a Bearer

Token in the Authorization header.


Policy Migration API (/ca/api/sso/services/policy/v1/deployment/...)
The Policy Migration API allows you to export and import specified subsets of policy data in the policy store.

 

Highlighted below is the Policy Data API section for Federation Objects. Under this section, you will find all the APIs, you need to create, delete, update and manage SAML 2.0 federation partnerships. 

 

 

For instance, the below API lists operations for managing IDP partnership.

 

 

Further, clicking on each of these operations, will reveal the payloads and responses with an example. You can also execute the APIs here by clicking on “Try it out!”.

 

 

 

To reiterate, these Administrative REST APIs allow for tighter integration into existing DevOps processes in your enterprise and help in automation of common administrative operations.

 

For instance, you could use them in the following scenarios

 

Scenario 1: - Your enterprise may have internal federations, SaaS federations, 1 to 1 federation with partners. In all these cases, a great idea would be to create payloads which are “standard configurations” for each of these category of federation partnerships and save these payloads as templates.

The next time, you need to create a partnership, you could reuse these templates by changing only the minimum number of parameters and use the modified payloads via REST APIs to create new ones, thus saving a lot of time!

 

Scenario 2: - Migrating an SP/IDP partnership from a staging dev environment to production

These APIs also can be used when migrating an SP/IDP partnership from a staging dev environment into production, thus simplifying the migration process.  

 

Scenario 3: - Updating an existing partnership is also very easy with REST APIs.

For details on using all the APIs and payloads, refer to our technical publications or REST API interactive reference documentation.

 

Also, we will continue to expand these functionalities to cover OpenID Connect federations. I will update this post once the REST APIs for OpenID Connect makes it into validation builds. Stay tuned for more!

Deploying CA Single Sign-On (CA SSO) Web Agents in dynamically scaled and containerized environments, such as OpenShift or other PaaS platforms, has been a hot topic.

The good news is that CA SSO supports registration that allow web agents to run in containerized environments since the release of CA SSO 12.6.

 

What is a Container After All?

In basic terms, a container is a form of virtualization and a packaging format for a unit of software that ships together. A container image is a form factor that encapsulates a set of software and its dependencies, the minimal set of runtime libraries that the software needs to do its function.

Enterprises running containers will need container orchestration solutions such as Kubernetes and other components for container management, either running in their own or in a public cloud. 

 

The Role of Docker in Containers

The adoption of Docker in organizations deploying containers has fueled an active ecosystem, with thousands of “Dockerized" applications in the Docker Hub registry. Cloud service providers such as Amazon Web Services (AWS), Google and Azure have embraced Docker and rolled out offerings of their own related to the ecosystem.

Here are some key factors as to why our customers are starting to embrace Docker:

 

  • Docker gels well with DevOps practices at scale. They are easy to deploy and accelerate application delivery coupled with immutability.
  • Portability is another key benefit of Docker because all required application dependencies can be packaged within the container's layers. Vendors can ensure that the application payload will execute on any node with the same operating system (OS) kernel type (Windows or Linux), that the application was compiled for. This also enables easy migration of workloads to public cloud services and across public cloud services. Therefore, Docker enables cloud-agnostic based practices and can help in avoiding vendor lock-ins.
  • Container orchestration platforms enable auto-scaling of containers and coupled with rapid startup and shutdown times, makes it well-suited for architectures requiring on-demand scale up and down, which improves the total cost of ownership of deployments.
  • Containers result in efficient resource usage, as the packaging model eliminates redundancies with higher application density, also improving TCO. 

 

CA Single Sign-On Web Agents and Docker

When Web agents are used in Docker containers or other dynamically scaled environments like OpenShift, scenarios can occur where containers with Web Agents are frequently initiated or destroyed, as they are scaling up or down based on the load that is caused by incoming requests. These scenarios require a different approach when registering those Web Agent instances.

To handle the rapid registration and removal of containers that are running web servers with the Web Agents, the instances of the same Web Agent must use the same trusted host. To do this, you must assign a trusted host to each logical application (rather than to each agent instance) and use the shared secret of the trusted host whenever you are initializing a new Web Agent container of that application.

The below documentation link explains in greater detail the approach of running Web Agents in dynamically scaled environments:

https://docops.ca.com/ca-single-sign-on/12-6-01/en/configuring/policy-server-configuration/agents-and-agent-groups/use-web-agent-in-dynamically-scaled-environment/

The CA SSO product team is also continuing to improve and optimize this approach. Keep watching this space for hearing more about what we are working towards or let us know your thoughts. If there are any topics you’d like additional tech tips on, please let us know!

 

CA SSO Product Team

Continuing the theme of programmatic interaction with CA SSO that we began in my last post, today I’ll talk about another great new feature in CA SSO 12.8: the JWT authentication scheme. The feature enhances programmatic interaction with CA SSO and its protection mechanisms, thus helping to create a modern software environment where APIs, JSON format and ID tokens run the show.

 

Before I get into how this new feature can be implemented in CA SSO, let me describe what JWT is and how it can be used in the world of SPA (single-page application) and API-based applications.

 

Some folks think JWT (JSON Web Token) is the hottest topic when it comes to authorization and single sign-on, especially for API-based applications. In its most basic form, JWT does what SMSESSION has done for over 25 years. Where JWT really shines is when it contains additional claims or user attributes. Just as SMSESSION was “tossed around” between applications as a cookie, JWT is tossed around as a header and does not need a domain dependency.

 

A JWT can be generated when a user is authenticated. For example, CA API Gateway, Google and many other entities can authenticate a user and generate a JWT, with or without additional claims.

 

A JWT contains three sections:

base64urlencode(header) + "." + base64urlencode(payload) + "." + base64urlencode(digitalsignature(header + payload))

 

Here’s a sample JWT from https://jwt.io/:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

 

When this JWT is decoded, it shows the three JSON sections:

  • HEADER (JOSE header):

{

  "alg": "HS256",

  "typ": "JWT"

}

  • PAYLOAD (Claims):

{

  "sub": "1234567890",

  "name": "John Doe",

  "iat": 1516239022

}

  • SIGNATURE

HMACSHA256(

  base64UrlEncode(header) + "." +

  base64UrlEncode(payload),

)

 

Essentially, the new authscheme in CA SSO version 12.8 accepts a JWT, authorizes the user to access a protected resource and issues an SMSESSION token so it can be used by other applications protected by CA SSO. Setting it up is pretty straightforward. But before we go through the setup, you should know that this authscheme requires use of CA Access Gateway and public certificates for signature verification, since CA Access Gateway has the main application to capture and decipher the JWT. CA Access Gateway is also used for all other federation types of single sign-on, such as SAML and WS-Fed. This new feature just extends the existing capabilities even further.

 

Below is my simplified setup with CA SSO 12.8:

 

 

You can get your JWT by logging into your Google account or CA API Gateway. (Don’t forget to get the public certificates while you’re there!) Then, add your JWT as a header to access a protected resource, say “/jwt/” on CA Access Gateway (as below, where I use SoapUI).

 

 

Now that we know what JWT is and how it is used, let’s look at how we can configure it in CA SSO in a few simple steps:

 

1. Set up the certificates. Pay attention to the aliases you give your certificates when you import them, as they will come in quite handy later.

 

2.   Set up the authscheme. Notice the list of certificate aliases. If an alias is in the JOSE header, make sure you click that button. The most important part is the user lookup claim in the JWT; in most cases it is “sub,” but it could be email or whatnot.

The additional configuration items at the bottom reflect how secure you want the communications to be and what you want to do with the information. If you disable SMSession cookie generation, calls to other apps protected by CA SSO will require use of the JWT authscheme, where the apps need to present JWT for every single call. Persisting session variables will help with SSO in other protected realms.

 

One last thing: Once you have the authscheme, attach it to the realm protected by the CA Access Gateway agent:

 

There you have it—JWT Authentication Scheme in CA SSO. Questions? Comments? Please post them below or contact me at Amin.PashapourAlamdary@ca.com.

As you may know, CA SSO has seen a lot of changes lately—the biggest being the move from a 32-bit to a 64-bit app, improving its performance across the board. Not only that: Many new features have been added to the 64-bit versions of SSO, starting with version 12.6, many of which let users more easily interact with CA SSO programmatically.

 

In my last blog post, I talked about using REST APIs to do migrations or upgrades programmatically. In this post, I’ll talk about one of the great new features in CA SSO 12.8: OpenID Connect. The feature enhances programmatic interaction with CA SSO, thus helping to create a modern software environment where APIs, JSON format and ID tokens run the show.

 

Here’s the simple setup for using this feature:

As you may know, the OpenID Connect provider feature was added in version 12.7; version 12.8 enhances this feature even more.

 

The first thing to do when using this feature is to define CA Access Gateway as your authorization provider, as shown below.

 

 

CA Access Gateway is the host for “Authorization Server Base URL.” When you create the azprovider, you can map your client’s chosen scopes to specific attributes from your user store.

 

Your next move is to establish the clients this server will work with. The most important elements in creating a client are the Client ID and Client Secret. These are auto-generated by CA SSO and need to be shared with the client. If you get errors when you try to generate IDs or secrets, make sure you have configured and enabled JCE.

 

Previous versions of CA SSO could do only Authorization Code Flow; version 12.8 can also do Implicit Flow and Refresh Token grant types. You can see all these features when you create an OpenID Connect client using the admin UI.

 

 

Additional scopes like email and givenName are visible, since azprovider defined them. In the above example, the client can ask for Authorization Code Flow with Refresh Token or Implicit Flow. For a good explanation of these flows, look at our documentation.

 

The main difference between Authorization Code Flows and Implicit Flows is that in Implicit, everything goes through the browser, so everything is visible to the world if you aren’t using HTTPS. That’s why you can’t configure Implicit Flow clients using http for the redirect URI.

 

When the client is set up with the right authorization provider, you can see all the good stuff for programming at the bottom:

 

 

 

These endpoints are what your applications/clients will use to interact with CA SSO for authorization, validation, revocation, etc.

 

Now that you have the OpenID Connect client set up with ID and Secret on the CA SSO side, you just need to set up the relying party with that information. The relying party can be any OpenID Connect clients, but since not all clients can handle various flows, great care should be taken when choosing such clients. In my lab, I used Apache OpenID Connect module. For example, my httpd.conf looked like this:

 

 

For a great example of how this setup can be extended for other partnerships, take a look at my colleague Mark O’Donohue’s post here.

 

There you have it—a primer on OpenID Connect. Questions? Comments? Contact me at Amin.PashapourAlamdary@ca.com.

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 


Richard Faust

Protect Your WAMUI

Posted by Richard Faust Employee Apr 2, 2018

The administrative interface to CA SSO provides a ripe target for malicious actors, both internal and external.  You would think administrators would take appropriate precautions to secure that interface, but I have seen many instances where the Web Access Manager User Interface (WAMUI, aka AdminUI) is published on a non-secure port.  That means administrator credentials are routinely on the wire in clear text.  To add further risk, the WAMUI is not protected by an agent, so many non-administrators have the ability to probe and attack the WAMUI in the "bad guys" unending quest to compromise the security of the single sign-on environment in particular and the enterprise at large.

 

I'm new to blogging and not yet familiar with the mechanics of this tool.  I envision this topic being a series of posts rather than one monolithic treatise, so please have patience while I figure out whether I can amend or append to this post or have to create a separate blog topic for each installment of the Saga of WAMUI Security.   

Picture this: the next time you open your mobile banking app, someone is already logged in and it isn’t you. Or, in your IT environment, multiple users are logged into an app and they’re all using the same credentials. One may be a bad guy, but with concurrent logins and no accountability or attribution it’s not easy to figure out which one. When a worst-case scenario erupts, suddenly your company becomes the next security breach headline. One simple way to avoid that nightmare is by limiting concurrent logins.

 

There are many good reasons to limit the number of times a user can be logged in, but finding a good solution isn’t always easy. Look for options that can be configured to record the session ID immediately after a user authenticates, or that can be configured to capture the sessions during the authentication process itself. This provides a crucial layer of security to protect both your environment and your users.

 

Also look for a solution that has minimal impact on users, limiting concurrent logins should not prevent an authorized access – just because I forgot to log out in the office should not prevent me from accessing from home.

 

With CA SSO, we have an option called “Limit Concurrent Login.” In addition to recording session IDs immediately after authentication, or capturing sessions during the authentication process, it is flexible enough to allow multiple active sessions – up to a limit. Once a user reaches that limit, it prompts the user that the oldest active session will be terminated. If you don’t have this capability now, we can deploy a packaged work product (PWP) add-on that also delivers extra peace of mind.

 

The next time you wake up in a cold sweat from that dream where your users are sharing credentials, or you envision failing a compliance audit because access isn’t attributable to an individual user, don’t worry – there’s an app for that. The CA SSO Limit Concurrent Login PWP

 

Senior Services Architect Gary Figg figga01 hosted a complimentary live webcast on February 23.  During the webcast, Gary provided an in-depth look at the CA SSO Limit Concurrent Login PWP. View the replay.

 

What nightmares have you had with concurrent logins? Share your experiences in the comments below.

 

Click here to connect with a Services expert.  

Introduction

 

If you are using custom login page, you may want to restrict the user from acccessing the OOTB login.fcc URL

http://<FQDN>/siteminderagent/forms/login.fcc 

This blog will guide you on how to achieve this.

 

Environment

  • Policy Server : ANY
  • Web Agent : 12.5 and above

Instructions

It is not possible to completely restrict the access to login.fcc as it needs to be unprotected resource and also needed as the custom login page needs to post to this.


However, what you can do is modify the login.fcc such that it will have only the bare minimum required content enough for the POST request but not not enough for GET requests (direct access)

 

If you are using login.fcc ONLY for POST request then it is sufficient to have just the following content in it. (The error message is optional off-course)

<!-- SiteMinder Encoding=UTF-8; -->
@username=%USER%
@smretries=0

<b><font size="5" color="red">DO NOT USE THIS PAGE DIRECTLY !</font></b>

 

Please note : 

  • If ACO parameter localization=no, the default login.fcc used is : 

<webagent_install_directory>\samples\forms\login.fcc

  • If ACO parameter localization=yes, the default login.fcc used is : 

<webagent_install_directory>\samples\forms_<locale>\login_<locale>.fcc

e.g. for en-US locale it would be :

<webagent_install_directory>\samples\forms_en-US\login_en-US.fcc

 

TESTING:

1. Direct access : 

2. Custom login page still works :

Attached : Fiddler

 

Addtional References :

Custom Login Page