Symantec Siteminder Reviews

Primary use case is for authentication in Single Sign-On, that's the biggest that we have. But we use it for our internal employees.

It has performed well. We had some hiccups, but that's all.

We had some challenges through modernizing everything over the last two years. Now we are pretty good. We don't see any production challenges. I don't think we have had an incident for a year now.

I think Single Sign-On helps a lot. If you look at our organization, and really all financial institutions, we have a lot of legacy apps. So it really helps to get Single Sign-On.

We use it on the agent model, and we have a lot of capabilities which we leverage to do it on the different apps, so critical apps are protected better. And we do step up using this, but we are looking at other products now to do the advanced track.

We use it mostly out of the box, standard, no customization.

Ease of use is very good, for administrating it. It's very well known. The ease of use is good for our deployment and our applications.

I would like to see a move towards the newer technologies, which is what we are doing right now. I think that's in the roadmap that's coming, in the 12.8 and 14 releases, but we would like to have it sooner than later.

I think now, for over a year, we have had any issues. It has been really very stable for us.

We don't have, and have never had, any scalability challenges.

We use it for challenges we have. If there are any issues that apps are reporting, we use tech support.

I think we have been good for over a year. We always get to the same contact that we have in the support. It's not dedicated support that we have bought, but most of the time it goes to the same person. So it's very easy to traverse.

We had a predecessor to it which was near end of life. I knew this product because I was part of CA previously.

We went with CA because it met most of our requirements. We had a requirement list of what we definitely wanted, what was nice to have, and I could see most of what we wanted.

We actually used CA Professional Services. There were some challenges on some aspects of it, but on the base product, not at all.

We looked at a lot of vendors around it. We had looked at RSA, Ping, and a multitude of others, just on paper, so to speak.

Most important criteria when selecting a vendor: We definitely look at our engagement. We look at the support. That's always the critical factor. Otherwise, I would say most of the products, if you go by the 80/20 principle, they will technically fare well.

I would say invest a lot of time in designing it. Don't just run in without reading the guides and start deploying.

Primary case is to authenticate users and use banking online. It is performing well.

It has definitely made things easier. We do not have to do that development. It is an out-of-the-box product which does the thing it does best.

It has the ability to authenticate and authorize users. It is the main feature for our security.

Better monitoring. A better way to debug a problem. When there is a problem with it, it should log enough information for CA to know what is the problem, like a better debugging tool. 

It needs better debugging and support.

We have had some issues with it, but in general, it is good.

CA was there to help. There is some issues in general.

It is very scalable. We have a very large customer base: 75 million customers. We have about 40 million log in a day. So, the scalability is very good.

We are not very happy with the support, I am sorry to say.

The reason is mostly because we stayed on an older version and we are behind catching up on a newer version. It has become harder for CA to give us good support. 

The main thing is we do not have the traceability and good monitoring that CA can provide us to capture problems when they occur. That is the biggest thing.

It has been an issue. All the problems that we reported actually have never been resolved. We could not capture enough information for CA to be able to debug the problem. This problem does not happen often. But, when it happens, we do not know why, because we are not able to capture the data. I think that is the biggest drawback. The support and its combination between ability for them to support us on all the older versions and different infrastructure to what CA recommends us to do. We are trying to upgrade and all that. Maybe these things will help.

Technical support is always available and very responsive. I have a direct line to the engineers. They allow me to talk to them directly. They really are trying to help the best they can. It does not work out well. In terms of interaction, no problems there.

When I started two years, it was already setup. Now, I am reengineering it. I am doing a different setup to eliminate any customization for CA to support us better. The process is straightforward.

I would recommend this solution. I would recommend the newer version without any customization. That is where we have had a problem because we did our own customization of this product.

Most important criteria when selecting a vendor: It is the supportability right. J.P. Morgan costs more, but we want stability, resiliency, and we want the product to work. However, it has to be scalable and supportable. That is the main thing for any product which we pick.

We use single sign-on to provide a single login page for all of our client apps across the organization and it performs wonderfully. We almost never have outages nor see slowdowns, not from our stuff anyway. 

People do not have to remember 35 to 40 usernames and passwords. They have a link to go to their page that they need to work on, and it is there. It knows it is them. If we lose an employee, they no longer can sign in from anywhere in the world, they are immediately gone. 

Simplifying the user experience. We use a lot of integrated Windows authentication with it. All of our applications get a point, click, and you are in, while we increase security at the same time.

I would prefer to see their SAML integration be a more streamlined and easier interface, more like PingFederate's interface. Their product works just as well for that use case, but we do not use it, because it is a much larger learning curve to get it running.

It is one of the most stable products in the banking organization that I am in. It never goes down and if it does, it is usually because my partner or me did something to it. 

I have been using it for a year. The company has been using it for probably 20 years. It has always been a very stable product.

It is immensely scalable. We have 18,000 employees running on six servers right now. They are not even at 10% usage, but to spin up more just to add a server and plug it in, it is ready to go.

Technical support is fantastic. They provide quick answers. It is very rare that it takes more than two or three days to actually resolve a non-production problem. With a production problem, they are right there with you the whole time until it is fixed.

We have had large-scale issues, but it never really took them a long time to fix. Usually within a few hours, we would have a fix.

They also take use of their community.

I was not involved in the initial setup, but I am involved in building a parallel platform right now for an upgrade. 

The upgrade is a very straightforward setup, easy to install and run. A little bit complex to set up rules, but that is why you want engineers around.

We have a resource that we are paying for from CA, but we really do not need to use them, except for on the Identity Management side. 

I would absolutely recommend they go with SiteMinder SSO. I have worked a little bit with some of the other products out there and they are not as easy to use, and they are definitely not as stable. Shibboleth is a competing free product. It is horrible. A lot of companies use it, but it is not fun.

Because I am new to this area, the thing that surprised me about CA is how quick they are to respond to changing needs. If we tell them we need something or do not know how to do something, they make it happen for us. It seems crazy for such a large organization to make that kind of move. 

The tool is easy to integrate with old, archaic, existing infrastructures that may not have been built with security in mind in the first place. With very little modification, we can usually secure a platform that never really had it before.

Most important criteria when selecting a vendor: responsiveness. When everything is good, the vendors are always around. It is how they respond when you have a problem.

What we're doing with Single Sign-On, we're providing security to different applications, like protecting the URLs. The other thing is, we're using SAML. With SAML we are connecting to the external vendor, external partner, and providing the customer a single sign-on to at the second domain.

It's more efficient. We're providing immense security to the applications, to Chase. We're securing 70 million customers in Chase.

I find that SAML is the best thing we're using right now because there is no need for creating the external account. If you take a partner like Disney World, if a Chase customer wants to log in to Disney World, then it is easy for them to log in with the same credentials, whatever we have at Chase. There is no need to make a new account or enter in the same data.

So, the Chase user, if he wants to purchase something on Disney World, tickets for example, he doesn't need to give his details to Disney World. He can use the information with the details, whatever we have, in the Chase DB. We're just, as part of the transaction, sending the details to Disney World and he completes the transaction with the details. So in that case, we're providing security to the user data.

We're working on a mobile API gateway. I am really interested to learn more about that.

It's stable, but we are finding some compatibility issues. We're still working with CA people. We're trying to improve the enhancements.

Scalability is good so far. It is user friendly, so we are not experiencing many complications when using this application.

Good support. We work with CA technicians frequently, engineers very frequently. They're very helpful.

Whenever we go to them with an issue, they'll first look at the existing DB. If the same kind of issue happened previously, they'll try to pull that information and provide us the feedback right away. If it is a new issue, they will really work hard to get the issue done, as soon as possible.

It is basically for authenticating the users, whether it be privileged users or employees. Thus, we use that single sign-on (SSO) as an authentication mechanism.

It is a simple solution to implement, and it provides additional flexibility.

Right now, federation that comes out-of-the-box with single sign-on is the most valuable feature that we have, and also scalability.

Better documentation. I went through some sessions on single sign-on for version 12.7. Whatever features we are looking for from a REST API perspective, they will be there. So far, it is good. We have to implement it, and figure out what is good or bad about it.

There are a few other competitors which are taking up advantage over the segment being more agentless. SiteMinder is more driven with agent-based authentication, but the others are going with being more agentless. So, we have to go into the more next gen technology, where other vendors are going into, and that is where SiteMinder is lagging behind. The speed at which they are bringing up these features, it is very slow. 

It is stable, but certain features which are out in the market are not available to make it more robust.

We are able to scale well with the amount of users that we have and the users that we are supporting. So, it is quite scalable. However, it does not scale vertically. It is only scalable horizontally. Therefore, it increases the footprint.

Right now, we have hundreds of policy servers between two datacenters. If it was vertically scaling, the footprint would have been reduced, and we have been looking towards a solution. However, the SiteMinder platform as such, even the 64 bit, is built on a horizontal scaling architecture. I do not think it is built on vertical scaling. Even if it is, for most of the companies like us, where we invest in a lot of infrastructure, vertical scaling would not really help.

We had a legacy implementation, and their technical support has been acclimatized to the new partnership federation, so they could not help much in terms of the solution. Therefore, I had to do trial and error to figure out what to do with it, and get it working.

Over the past years, CA support has been only focused on problem areas. When there is a specific problem, they will focus on resolving that problem. They are more focused on closing tickets. They are more focused on getting the tickets closed than resolving them. If the solution is not resolved, and if I requesting, "Hey, I want a couple of weeks for that to be open." Sometimes, they do it. Sometimes, they say, "Hey, we will close the ticket, then you can reopen a new one."

Other instances, if it is a feature that we need answers on, support sometimes says you need to get professional services to get engaged. I do not know whether it is the right direction that CA wants to go, because support is something that support professionals are supposed to know about the product. I would go and open up a ticket to get answers based on the feature that is available or what we are planning to do. We cannot just go hire professional services for everything that we do.

All of the feedback within our team for CA Support is not good. It really is on a very low level, but then it is very specific for CA SSO. The CA support for other products, like CA Spectrum, has been good. However, for CA SSO, it is absolutely poor.

The initial setup was straightforward. Also, we have been doing upgrades, in place upgrades, as well as cloning infrastructure, which has been pretty straightforward. 

However, the documentation is very unclear. It is painful to go through the actual documentation and get the information which we need. 

I opened up a ticket a couple of weeks ago. It was on strong authentication where we wanted to upgrade from an older version to a newer version. I had to go through three documents and open up a ticket to understand how the upgrade process should happen. It was so confusing. In one document, they say something, and in another document, they say another thing. I actually had to open up a ticket for this. I wanted to delegate the work to somebody else, and when they asked me the question, I did not have the answer, because it was distributed across three documents.

Even during my initial deployment of strong authentication, this was the older six stack two version, if I would have gone through the document to build it, I would not have done it. We had professional services sitting with me, because I was doing a PoC. At that time, we went through the installation, and I was able to receive some help.

But for everything, I cannot go to professional services. If the documentation was straightforward, then I do not have to refer to professional services. That is one thing that I have noticed, the documentation is really unclear.

Ping and ForgeRock. In our company, because they are competitive and have an edge over SiteMinder, they are even considering going for ForgeRock or Ping. These companies are more flexible and are open source products, whereas SiteMinder is propriety. 

So unless we get into something, then we can't even go to open source and get the information. It is basically, we have to reach out to CA to get answers. 

That is what management is looking for. They want versatility, and when senior management looks for a product, they are looking at:

• Can we customize a product? 
• Can we add features? 

That is the thing that they're looking at, and they are finding Ping Identity, or Ping products, and ForgeRock products more appealing than SiteMinder.

I have been working with Site Minder for the past 10 years, maybe more. However, I know the product, therefore I am able to manage it. The people in my team, they are not really happy with it, mostly from the support perspective.

Validation of people's logins when they log in to their PCs. Everybody, when you turn on your PC, you go SiteMinder to login. Security.

It has performed very well, it does what we need it to do, it's reliable, and it doesn't impose any overhead on the user or on the platform.

• Ease of use for the user 
• Security, of course
• The ease of setup and installation

We can definitely control our user experience better on the PCs. People don't necessarily have to worry about losing something, like a PC, or a tablet, or a phone, because it's controlled by SiteMinder. We can remote wipe it, we can do all sorts of different things to secure it.

Answering this would require me to know what the current platform does or doesn't do, and I'm afraid I'm not a good enough judge to make that evaluation. I might say something and it's already there, and I just don't know about it.

I will say the user interface for login is kind of plain. They could make it a little prettier. The site is a big, blue screen, with "SiteMinder," and that's pretty much it.

It seems pretty stable so far. It's a mature product, it's been around for a long time.

We're using it on thousands and thousands of devices, thousands and thousands of users. So, it's very scalable.

Our customers use it to log on to our site.

It has performed very well, so far.

• Authentication
• Authorization 
• The user repository

Without, with the number of customers using our site, if that portion was down, our contact center wouldn't be able to handle the calls, if the authentication and authorization wasn't working.

It has streamlined a lot of the functions, and for all our applications they don't have to worry about the security part, they just ride the application and SSL handles the authentication, the security part of it.

The OpenID Connect piece, we would like to see the new technologies baked into the product, as opposed to going out and using a different product to accomplish the same thing. So OpenID Connects would be great, to have that kind of plug-in, into SSL without having to go in and install new products.

It's very stable. We have experienced occasional downtime, but once we work with support we find the problems and we solve them. Once everything is configured and working, it's stable.

In terms of scalability, so far we haven't really had issues with performance, we haven't faced any problems yet.

Technical support is good. Once we escalate, the proper channels get the tickets, then we have no issues with them.

When selecting a vendor, what is important for our company in that relationship is, obviously, the history that we have that we have with the different companies, and meeting the requirements.

I rate it a nine out of 10. Sometimes it's just a matter of figuring out the quirks and how it works. But once it works, it works really well.

I would definitely recommend it. It's a product that does what it does very well. Once it works, it just works and you don't have to mess with it.

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.

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.

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.

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.