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

CA Single Sign-On

211 posts

This blog helps you understand how JWT powers the Layer7 APIM-Layer7 SiteMinder integration. This blog does not emphasize the technical details of JWT or the configuration details of CA APIM and CA SSO. 

 

Why do you care about managing access of transactions based on APIs and Web Flows?

 

With the goal of delivering a smooth single sign-on experience to multiple applications, organisations want to shield users from the potential complexities of multiple authentication and authorization servers.

 

 

As organizations continue to embrace Digital Transformation, they are deploying more and more access flows where users are interacting with web applications or mobile applications to execute transactions (retrieve information, order a good or service, etc.) and those applications in turn are using api’s to make calls to other sources, on behalf of the original user.  Ideally organizations don’t want users challenged for authentication when the user’s transaction crosses boundaries between the standard web access and api access legs of a transaction.  Additionally, organizations need user attributes and entitlements to seamlessly cross these same boundaries.  The overall goal is enabling access to information needed with the simplest user experience, but at the same time ensuring the level of security that is critical.  Comprehensive and granular authentication and authorization capabilities are necessary to achieve this end result. 

 

In addition to the foundation of authentication and authorization, these types of flows also need to support session management both for the purpose of ensuring user experience is as simple as possible, but also for the purpose of achieving complete single log off when necessary (cookies invalidated, SAML assertions removed, OIDC tokens revoked, etc).

 

“Your ability to address these types of use cases will help your organization improve user experience”

 

Broadcom offers proven solutions for API Management and Access Management.  Comprehensive API Management requires a lot more than just authentication and authorization capabilities.  Developer tools, api transformation, injection protection and service level guarantees are critical.  Broadcom’s offering meets these needs.  To better enable this hybrid use case, the simple answer is integration of Layer7 API Management with Layer7 SiteMinder. This solution provides seamless login experience to your end-users when a user tries to access single page applications, and deep authorization can be governed by APIM.  Then when a user needs to access other SiteMinder protected resources within the existing session the experience is smooth and the security is trustworthy.  

 

What's new in the integration?

 

If you have already implemented this integration using versions prior to SiteMinder 12.8 and API Management 9.4, then the implementation is using a SiteMinder agent deployed in the API Gateway.  That integration worked for a number of use cases, but it created additional overhead because the API Gateway had to do more work to transform to and from the native SiteMinder SMSession as transactions between the two products were being executed. 

 

The 12.8 version of SiteMinder introduced support for a JSON Web Token authentication scheme.  This standard token type can be applied to the integration between SiteMinder and Layer7 API Management to simplify and improve the integration.

 

Why adopt JWT Authentication Scheme in CA SSO? 

 

The APIM-SiteMinder integration comes with shared benefits of JWT authentication with SiteMinder. JWT authentication augments your ability to handle sessions across APIM and SiteMinder enabling seamless user experience without compromising security or trust.

 

------------------------------------------------------------------------------------------------------------------------------------------------------

This new methodology is the best way of integrating two solutions. Spend a little time setting up the JWT authentication scheme for all required protected resources and manage public/private keys to establish trust between the two parties.

------------------------------------------------------------------------------------------------------------------------------------------------------

 

Key Benefits of JWT Authentication in Layer7 SiteMinder

  •  A JWT generated by Layer7 APIM can be used for user authentication and also to get access to multiple SiteMinder protected resources. Even if a SiteMinder defined SMSession is short lived (a typical configuration), APIM can use a long-lived JWT token to get access to SiteMinder protected resources without asking users to provide credentials again and again
  • Standard JWTs generated by APIM can be used across various authorization servers. This helps improve the administrative and transaction experience across authorization servers which are deployed in different data centers
  • No need to customize configurations in the API Gateway to achieve parity with SiteMinder ACO parameters. For example, a SiteMinder agent embedded in the API Gateway will accept session cookies from the SiteMinder SDK call using the AcceptTPCookie ACO. This configuration can be avoided when the integration is executed via JWT
  • APIM can manage user authentication and SiteMinder can perform policy decisions based on the JWT contract to achieve claims-based authorization.
  • If APIM is acting as an OIDC provider to authenticate users and to generate ID_tokens and Access Tokens for API flows, the same ID Token can be used with the SiteMinder JWT authentication scheme for web flows, making SiteMinder an OIDC Resource Server.

 

2018 witnessed numerous breaches in large enterprises and government organizations, affecting billions of user records. 

The trend continues in 2019 and in short, there is no surprise in the statement that data breaches have become the norm across the world.  Enterprises that process and store large volumes of PII, payment data and healthcare data were the primary target for hackers and will continue to be so, for years to come. 

 

Looking at last year, web application attacks were the most frequent attack vector pattern, observed in confirmed breaches, according to the 2018 Verizon Data Breach Investigations Report. 

Defending and securing your most critical web applications, can be a consuming exercise. As you may already be aware, there is an online community nonprofit initiative called the Open Web Application Security Project (OWASP) that regularly compiles common web app security risks, being exploited in the wild. Setting policies in your organization, based on eliminating OWASP Top 10 risks is an excellent starting point – these potential vulnerabilities are widely accepted as the most likely to be exploited. Using security solutions to protect against these risks will greatly decrease the chance of a breach. It’s interesting to note that some of the OWASP risks are more prevalent in specific industries. So, you could consider focusing on the most pressing risks facing your sector, for further prioritization. Also, given the recent uptick in massive breaches the prevalence of credential stuffing attacks has largely increased, which means it's time to look at using MFA options like “push”, which is proven to be more secure than a SMS or email OTP, for most of your critical web applications. 

Now turning our attention to how to avoid these risks - while there are ways to mitigate these in applications by design and secure development practices, Layer7 SiteMinder (formerly CA Single Sign-On) has policies and settings to complement these development practices. This is a defense in depth strategy to help reduce risk.

I will give a few examples that touch some common attack vectors as well as provide some advice on settings to help mitigate those attack vectors.

When it comes to session security, it’s safe to say that SiteMinder makes your job easier. Broadly speaking, there are settings in SiteMinder that prevent attackers from exploiting certain key vulnerabilities in various scenarios in both federations and non-federation transactions, and even if a breach happens, there are settings that help narrow the window of exposure.

Cross-Site Scripting (XSS) is one of the top OWASP risks to be wary of. In Veracode’s most recent State of Software Security Report, you can see that Cross-Site Scripting flaws were present in nearly 50 percent of the applications. SiteMinder has various controls like BadCSSChars, BadQueryChars, BadURLChars in the SiteMinder enforcement points such as Web Agent to scan the full URL and escape untrusted request data based on the specification in these controls, preventing XSS attack. Another mitigation approach is to make the Web Agent  set the HTTP-Only attribute for any cookies it creates using the following parameter: UseHTTPOnlyCookies which instructs the Web Agent to set the HTTP-only attribute on the cookies it creates. When a Web Agent returns a cookie with this attribute to a user's browser, the contents of the cookie cannot be read by a script; even a script from the web site which originally set the cookie. This helps prevent any sensitive information in the cookie from being sent to an unauthorized third party via malicious script code. This setting also applies to contents of the cookies that Federation Web Services generates.

Malicious actors are looking for easy to use exploits to impersonate the victim. Therefore, session cookies are a highly valuable target for them to use and replay. If you are using a cookie provider in your SiteMinder deployment, it is recommended you turn on the configuration to persist the session cookies in a session store, which can prevent session tokens from being stolen. There are also other advantages of using a session store – more details can be found here. 

Another common security risk exploited in web attacks are unvalidated redirects where a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site that the attacker controls, an attacker may successfully launch a phishing scam and steal user session or credentials. Prevention of unvalidated redirects can be achieved by sanitizing input by using a list of trusted URLs, also known as white list. SiteMinder provides the following agent configuration parameter - ValidTargetDomain to specify the domains to which a credential collector can redirect users. If the domain in the URL does not match the domains set in this parameter, the redirect is denied. 

 In cases where the session cookie gets stolen and bad actors end up using them for a session replay, there are controls within SiteMinder that minimize the window of exposure and in some configurations completely mitigate the attack.

 

A SiteMinder session cookie, also known as “SMSESSION,” is usually  a transient cookie with an “Expires” attribute. A persistent cookie that uses the “Max-Age” attribute is not recommended. The session “Expires” attribute of the session token (SMSESSION) also known as automatic session expiration, is configurable within the policy itself and can be configured to minimize the exposure window, based on your application’s requirements.

 

In a federated environment, there are equivalent controls provided within SiteMinder that limit the exposure window (per the federation standards). For example, in OpenID Connect, access token lifetimes are recommended to be kept to short lifetimes. If ongoing access to the UserInfo Endpoint or other Protected Resources is required, a “refresh token” can be used. In some cases, an attacker may try to use the access token generated for one resource to obtain access to another resource, for which it was not intended. To mitigate such an attack, it is highly recommended to keep the audience and the scope restricted for the access token. Similarly, in SAML or WS-Fed, as much as possible, you should configure either onetime assertions or short-lived assertions, to prevent the reuse of assertions.

 

Finally, coming to  “Session Assurance” - one of the advanced capabilities within SiteMinder, which mitigates the risk of session hijacking. SiteMinder utilizes a patented technology called the “Enhanced session assurance with DeviceDNA™” that uses device fingerprinting to bind the session token to several device properties. This capability involves uniquely fingerprinting a device in a continuous fashion, and comparing each fingerprint sample with the fingerprint taken at the time of login to identify compromised sessions and invalidate them.

 

There are several additional session defense mechanisms not covered in this blog.  For more content specific to that topic, talk to your Broadcom field representative.  Additionally,  looking to the future, we will continue to evolve SiteMinder, to expand on our authentication, authorization, federation support and session management capabilities.

If you want to get early access to some of these capabilities, we expose them in our validation kits posted on validate.ca.com. If you are not on validate.ca.com, please enroll yourself and get access to the forums and the kits.

 

I hope this post has been useful.

Summary:

   JWT authentication is supported from CA SSO 12.8 release. It is supported with Access Gateway and SDK only, but not with web agents.  This document provides how to use custom FCC for JWT authentication.  Custom Web Forms (FCC) with JWT authentication gives the seamless integration login experience with web applications.

 

Pre-Requisite:

   CA SSO 12.8+ Policy Server which supports JWT authentication Scheme.

Any version of Web Agent or Access gateway, (This blog is prepared by testing the flow using 12.52 SP1 CR 09 Webagent GA Build)

Using the Custom Form Page(FCC login page).

 

Advantages:

  • JWT authentication scheme can be supported using custom FCC for browser-based application.
  • Leveraging custom FCC with JWT authentication scheme helps to continuing web agent
  • Since JWT token can be posted in FCC, redirects are possible with JWT authentication scheme. 

High-Level Flow description:

   User access a servlet page and provides his/her user credentials. Client application generates a JWT token and posts JWT token to FCC page with POST request.

Agent fetches JWT token and sends to JWT authentication scheme. After successful authentication, FCC page generates SMSession cookie. Client application sets the cookie in the  browser and redirects to the target page.

Instructions:

Below steps explains details in configuring JWT authentication and other perquisites in the product.

 

Below is Step by Step Implementation details:

 

  1. Create an Agent, ACO and UserDirectory, Domain.
  2. Create a JWT authentication Scheme.

JWT Authentication Scheme with HMAC Protection

3. Protect Endpoint with JWT auth Scheme

Sample resource protected with JWT authentication scheme

 

4. Web-Agent or Access Gateway configurations. 

Create a FCC File and place the file in \win64\samples\forms\jwtloginpage.fcc (attached sample FCC file)

 

Screenshot for fcc file :

FCC JWT sample pagejwt html field input

 

 

 

 

 

 

 

 

 

 

 

 

 

5. In the FCC file, add the below code snippet with SMAltCreds Field mapping an HTML input field.

@username=%USER%

@smretries=0

@smaltcreds=%JWTTOKEN%

                          <input type="text" name="JWTTOKEN" id="JWTTOKEN" >                

            Find sample FCC file in the attachment.

 

 

 

6.Create sample files and servlet that posts JWT token to form page (attached JWTDemo.zip)

7. Demo application:   Demo  "Webapplication" that sends JWT token to form page

  1. JWT Demo Code zip file is attached 
  2. Attached application is a very simplified version of implementation which accepts FCC URL, JWT Protected URL and JWT token in properties file "config.properties" present under "jwtdemo\WEB-INF\classes\config.properties"
  3. For simplicity of servlet code, JWT token is also read from the property file. 

8. Access home page of  “webapplication”    

 

DEMO application screenshot.

Access home page of "webapplication". say(jwtdemo). User gets redirected to login page which takes username.

First Page

Login page which takes dummy user. Posts a username to servlet.

 

 

Servlet posts a JWT token to FCC page, once its successful. Servlet redirects the  user to target page. Target page can be seen having SM related Headers.

 

 

Attached is source code for servlet, it would need HttpClient library which posts the JWT token,

User Authentication in SAML and OIDC federation

 

 

Federation was designed to enable trustworthy access across separately managed domains of users and information.  Described simply, in federation one domain (or organization) maintains a population of users and the methods available for those users to authenticate.  The second, separate domain maintains the application or information the users want to access, and, accepts and validates the minted access pass issued by the first domain.  By not having to manage the users’ account lifecycle and the user authentication process, this process enables the second domain to simplify their management tasks and lower their management costs.  All the second domain requires to grant access is the access pass, minted in a standard form (SAML or OIDC) and digitally signed with a private key that is bound to the originating organization.  This arms-length scenario seems simple enough, but things get more complicated when organizations want to truly embrace digital transformation.   The digital transformation journey drives organizations to open access to all possible relevant information for all constituents from any location.  A great target to aim for, but security practitioners and, more broadly, anyone that pays attention to news broadcasts knows pursuing that goal potentially exposes an organization to potentially painful, public, and highly expensive problems when sensitive information falls into the wrong hands.  Risk of exposure increases when just a username and password unlock access to all information across a federated partnership.

 

For a long time, CA SSO has provided access control to information in some of the largest most security-sensitive organizations in the world.  The product continues to evolve to support use cases these organizations are implementing in the digital transformation journey.  A quiet, useful capability not in the marquee limelight but highly useful in arms-length federation transactions that are part of the digital transformation is Dynamic Authentication.   CA SSO offers support for this capability in both SAML and OIDC use cases.   In a nutshell, the business value intent behind Dynamic Authentication is to lower the cost of federation management and increase the flexibility to support different forms of user authentication to enable access to varying levels of sensitive information across the federation bridge.  Quite a trick if both of those values can be accomplished in parallel. 

 

Here is a high-level description of how it works in one use case. 

For the deeper description search for “Dynamic Authentication” in the online technical guides (use the quotation marks when you execute your search).

An administrator at an organization using CA SSO as a SAML Identity Provider (IdP) will create an authentication context template in CA SSO.  This is just a fancy name for a template that maps user authentication strength levels to the location where a user will authenticate to achieve those strength levels.  Then, the administrator at the IdP configures a federation partnership with a Service Provider in CA SSO and, for “Authentication mode”, they select “Dynamic” and then they select the specific “Authentication Context Template” they want to apply.  How does this help lower administrative overhead?  Well, rather than setting up multiple configurations to accommodate different applications at the Service Provider that need different levels of user authentication strength, with just a single federation configuration using Dynamic Authentication your users (remember you are the IdP in this use case) will be prompted to authenticate with a dynamically determined authentication method based on the real time signal provided by the Service Provider during the transaction.  It is likely, over time, that any single Service Provider you have a federated partnership with will want to expose different information requiring different levels of user identity proof (i.e. different levels of user authentication) to your users.  So…if, as an IdP you can accommodate that with a single configuration…that saves time and increases the level of security of your federated interaction.  Trick Accomplished!

 

While this blog focused on a single example, I encourage you to dust off the on-line CA SSO technical guide and see how this works when you use CA SSO in a SAML Service Provider capacity or implementing OIDC. 

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