Primary Use Case
We use Single Sign On to provide, of course, single sign-on to a variety of web applications. We use it to federate identity for remote web applications as well.
It's performed well. We're on an older version, so there's the occasional stability issue, but overall, that's what you're going to see in any enterprise environment.
As our identity model continues to mature, probably the Federation is most valueable.
In IT, you're seeing a large shift to the cloud, and to using software as a service applications and, because of that, you still need to be able to securely assert identity. The Federation components of CA Single Sign On allow us to do that effectively and with minimal resource investment, to realize functionality.
Improvements to My Organization
It allows us to get, again, both externally hosted and internally hosted web applications up and running using centralized credentials in short order. It makes it easy.
Room for Improvement
I've talked to them about this: I'd like to see a rework of the user directory configuration. In Single Sign On, whenever you set up a new user directory, there is a pretty specific number of hoops that you have to jump through in order to maximize throughput between Single Sign On and a user directory. A lot of those aren't documented, so the only way you typically get that information is by engaging CA support, which, if you don't think you need to do that beforehand, you're going to have an unpleasant surprise when you cut over.
So, either reworking the user directory configuration would be great, to make some of those hoops that you have to jump through unnecessary, or redundant. Or, failing that, reworking the documentation for setting up the user directory, explaining the rationale behind why you have to do the things you do. Because, if it were documented, at least then you'd be able to set it up effectively without incurring downtime, as you find out how to do it the right way.
In terms of the stability issues, what we do see is frequent Policy Server service restarts. What will happen is SM Policy Server will die and be restarted by the SM executive. That happens relatively frequently. But again, we're on an older version, and we've been told by CA that that's the reason why, and that it has been patched in later releases of the product.
But the executive restarts the service as fast as we can log in and look to see, is there any service impact? The environment is once again processing authentication and authorizations. Not only that, but, we do have a relatively large environment as well, so we have policy servers running and multiple datacenters. It's not just one in each datacenter, it's several in each datacenter. So we don't see any large, sweeping impacts to our enterprise authentication traffic; when one goes down, it gets restarted. Although, it is a pain because you do have to allocate resources to go and verify that yes, indeed, it did come up.
The scalability? I think it does well. We've been able to scale horizontally at various times throughout the lifecycle of the product, within our environment, with minimal fuss. It's been good.
Customer Service and Technical Support
It's good, actually. Very good. The product knowledge that they have on hand with that staff is more than adequate. They've sent people on site on several occasions. We've engaged them not only through the phone, but through the web submission portal, and in person. At every opportunity, CA staff has been professional, knowledgeable, easy to work with.
We were using something previously but I don't recall what it was. In terms of switching, it's a similar decision chain to what you think about when you need to invest in an upgrade. Is there a problem with stability? Is there a problem with scalability? Does the solution meet the evolving needs of your enterprise?
From what I've heard, the solution that was in place in the past was very unstable. In terms of comparison, Single Sign On is much more stable from what we've seen, than the previous candidate. That's why we decided to make a change. We evaluated the options at hand, and selected Single Sign On to move forward.
I wasn't involved in the initial setup for our current environment, but I'm involved with a project that is setting up the upgrade environment. It's pretty straightforward.
When we are looking for a new vendor, what's important to us is the relationship between us as a customer and the vendor. That has to be strong. They need to be available and supportive of our vision.
Also, we're looking for somebody who also can help us define that vision in places where we might not have it all the way fleshed out. You could go through the list of things that you're looking for in a vendor, and build out a wish list, but, realistically, somebody that supports us when we need it, helps us to figure out where we're going when we don't quite know, and, provides technological solutions that support our long term vision. CA does that, and that's why we're with them.
I gave it an eight out of 10 because it's a really good solution. No solution is perfect, so that's why I picked eight.
I would say to give CA Single Sign On a good hard look. There are a lot of other competitors out there folks like, Okta, PingFederate, I think IBM has a product that does something similar.
I would tell them that CA Single Sign On is a worthwhile option. If they're doing their research, take a look at it, and see whether or not it meets their use case. It does for us, and it does it well, so I would certainly recommend it.
Disclosure: I am a real user, and this review is based on my own experience and opinions.