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!