Skip navigation
All Places > CA Security > CA Identity Management > Blog > 2017 > May
2017

Four Steps that will help you to determine whether you should upgrade.

 

It’s a known fact: CA customers running the most recent version of CA Identity Manager (IM) log fewer support tickets and have less severity 1 issues than customers on older versions.  

 

That leads us to the question, “When is the right time to upgrade my CA IM solution?” I’m here to help you make that decision, and CA has several technical tools that help clients determine when to upgrade.

 

Step 1 in the process is to determine the current solution level by running a tool that CA provides. The tool, which extracts a lot of information about an organization’s IM solution, is called iminfo.bat (for MS Windows environments) or iminfo.sh (for UNIX environments). The top lines in the file named “…\CA\Identity Manager\Provisioning Server\bin\caim_iminfo.txt” show the current solution’s build level:

 

 

This tool should be run on every server that houses one or more CA IM components, as components on different servers are sometimes at different release levels.

 

Step 2 is to consult CA’s support matrix, which helps clients determine whether they’re on track with their IM solution, or if they’ve fallen behind and are therefore at risk of losing support. If that’s the case, they need to start planning an upgrade.

In fact, upgrade planning should be an ongoing activity, especially if your organization has a high level of solution acceptance and use. Just like every other agile product deployment these days, it makes sense to always have a backlog as well as a few sprints actively going on or coming up.

 

Which leads me to step 3, the IM capabilities roadmap. It behooves customers to have a roadmap in place, so that day-to-day operation of the solution don’t get in the way of adding value where it’s most needed. (When Services helps a client implement IM, we provide an initial set of capabilities and give them a roadmap for enhancements.) A best practice is to revisit the roadmap every 12 months to make sure it’s still relevant and valid. The answer depends on how long the solution has been in place and how long ago the roadmap was created.

 

Step 4, the final step in determining whether an upgrade is in your immediate future, is to gather feedback from your user community. In my experience over the last eight years, a lot of clients don’t take the time to get feedback from their users. Satisfaction surveys or other modes of getting feedback are invaluable in helping organizations determine the capabilities that most need to be upgraded or added. In a future post, I will discuss the kinds of questions that yield the most useful feedback in a satisfaction survey.

 

As for my next post, I’ll talk about how CA Services can help you create a comprehensive upgrade plan that will justify the (really very reasonable) expense of an upgrade and help you get leadership buy-in on the project. Stay tuned!

For millions of people who use applications for activities like managing photos, making travel reservations, conducting their daily banking business and/or managing retirement funds, CA Single Sign-On (SSO) is central to a successful user experience.

 

Effectively managing your Identity and Access Management (IAM) platform’s performance doesn’t start when you integrate an application into the solution; it starts the very day you begin evaluating requirements for IAM. Decisions large and small—product and platform selection, network and directory design, application integration patterns, even log settings—can affect IAM platform performance. Often, though, organizations make those decisions without considering downstream effects.

 

If you saw my CA World presentation “Who’s Minding Your SSO Store?” you’ll remember that we talked about SSO key performance indicators and how to monitor them. We also discussed how to estimate capacity and useful ideas on how to model the load on your IAM environment. Once you’ve done all that math, and you’re certain you have the capacity, it’s time to test SSO.

 

At that point, you have a whole new set of questions in front of you:

 

  • How do I test SSO?
  • What tools should I use?
  • Do we have a testing solution in house? Does our team understand how to test this?
  • Are there open source testing tools that I should consider?
  • How difficult is testing

 

Because most IT professionals don’t have a breadth of testing knowledge, capabilities and experience at their fingertips, let alone the tools for generating the necessary load for testing a solution, I’m going to walk you through the issues and best practices over the next few weeks.

 

We’ll explore tools and methodologies, starting with the foundation—directory instances. I’ll talk about strategies and walk you through each step for building a realistic test script, the tools we use to do it and how to execute it.

As you know, the user store is the most critical component of any CA SSO environment. If the user store can’t handle the load and starts to perform slowly, the negative effects cascade throughout the entire solution. Soon users get failed login attempts because the policy server has no free threads—they’re all busy waiting for the directory. Then users get server errors because there are no free connections because requests are held up waiting for threads—yep, they’re waiting for user directory requests.

 

That’s why we’ll start our journey at performance and capacity testing of your CA SSO user store. I’ll show you how to use Apache JMeter to build and execute a test plan for your user store, and with the power of CA BlazeMeter, throw as much load at the server as it can take.

 

Next we’ll move on to testing your Apache and IIS web servers to ensure that they’re tuned and ready for the load you’ll generate. Depending on how you have the webservers configured and tuned, your policy server configuration and host configuration objects should and will change—we’ll explore why and how.

 

Finally, we’ll put it all together and test your full CA SSO stack—web server, access gateway, policy server, user store, session store, and everything else. We’ll make sure you have monitoring in place to quickly troubleshoot bottlenecks and build a test program that can become a repeatable part of your process for every app protected by CA SSO.

 

Along the way, I’ll stop by for a webinar on May 17th  CA SSO Performance Testing with CA Blazemeter and host sessions on performance testing on the Communities site. I hope you’ll join us for everything!