Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > Authors Madhusudhan Yoganath

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.

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