What is our primary use case?
The primary use we have for this product is dividing access into streams. We have to provide the client organization with group and directory structures. The technical part, or provisioning, always seems to be more of a problem because the client companies have some semi-manual processes that depend on human interaction. This is often for something like disabling users, creating new users or changing roles.
Of course, provisioning takes a lot of time because it involves accurately defining and managing privileges. It includes accounting for all the access types from temporary access to agile access and also risk evaluation. All these things are often handled through a business process where a lot of the activity is done manually before a solution for automation — like CA Identity Manager — is in place. The agent for CA can handle criteria and rules and has templates for these activities. In short, it can handle these situations automatically starting from the HR Assistant included in the core suite to do recruitment or provisioning of users, and allowing basic access to things like email.
Leveraging access depends on which group a user is in and which business rules should be applied. There are often a lot of access attempts on what should be restricted resources. The client has to provide the rules to define which users have access. If there is no rule in place the issue has to first be identified and then to go through a process of approval in an appropriate department. This may lead to a need to change the access process and maybe go back again to think further about the business rules. When all the right rules are in place the processing can be handled automatically by CA IDM.
After you change something and test the process again, you can find that there are exceptions and we do not have all the rules in place to handle them. Then the identification and approval process needs to be adjusted on the system again. This, of course, is done with manager approval and the rules have to be examined. We need to repeat this process for the entire site. It is a business process improvement that takes time but will eventually save time by eliminating human intervention and errors.
So the main use case is provisioning and access and implementation for security reasons. For example, if you request the use of an application and it is approved, the identity manager learns this and the user is then able to access this application.
What is most valuable?
Out-of-the-box connectors have a lot of opportunities for configuration. The governance port and business rules are difficult. At a certain point, the product discovers dormant accounts because it monitors which accounts are active but which are not being used. So it will perform some service on these dormant accounts that are not active for six months or maybe never used before. This is a good feature. We also have a dynamic workflow, with approval stages which helps validate the ID.
They have a form designer, which is good because you can create exactly what you want as far as access controls. They have value-added modules like the one they have for asset management. This means that when you are in the role of a manager in CA IDM, you are able to restrict access to certain types of laptops — maybe by mobile provider, maybe by core type. So if a user tries to access the system with an asset of a certain type, we can allow it. It is a value-add, not necessarily related to the user distinctly. But if you take it from the point of view of asset management, it also helps in tracking the assets, which is another interesting outcome.
What needs improvement?
As far as improvements, the first thing I think CA needs to do is redesign the user interface. The functionality is good but the interface itself is not that user-friendly.
I think also that there are some issues with the privileges of service accounts. For working with Oracle, we need some kind of service account with administrative privileges. Access works when we give the user account administrative privilege. But in some cases, particular access needs to work for user roles that have less than administrative privileges and these users and rules need to be stored in the database. I need the ability to directly configure users and rules store on databases.
Maybe it is more complicated and related to Oracle services — I do not know the database side as well. But we need to read and write on the rules table and the users tables and store that data in the database.
Otherwise, the product has good performance and it is a very capable solution. I can automate a lot of processes related to provisioning users and identity management, but the controls can be even more flexible with these few changes.
The deployment cannot be pushed through the management console when you define the credentials for a user that can connect to the endpoint. It would be easier for deployment if the service could look at the endpoint or data center and detect what is needed to push this deployment based on the application version or based on whatever the operating system is. Things like that can make a difference at times.
If they can customize by the customer, it means that if someone upgraded their environment, the client does not have to go back and request the version of an executable for a new OS. The result is that the correct executable will be deployed by the agent.
For how long have I used the solution?
The last time I used CA Identity Manager was in May of 2019. Actually I was not using the product, but I was working with it in implementation. My job sometimes gravitates to implementation in the form of policy implementation and technology implementation. In order to do implementation, I had to have a good knowledge of CA IDM technologies as far as the connectors, the components, and integration ports, et cetera.
I was dealing with CA IDM for seven months. In the process, we had to go through the basic procurement, the deployment, the provisioning of the users, the integration of the second phase for the government and business rules, as well as other configurations. I have had to think through all of this with the available capabilities of the product and made sure everything would work. The last component that involved analytics was not something I was involved in. I did not work on that part, but I know the analytic features are good.
What do I think about the stability of the solution?
My impression of the stability of CA IDM is that the product is very dependable. They have a good HA (High Availability) design and good DR (Disaster Recovery) for data transmission and security in all situations.
The deployment is very good. After you set up a new component you just go to the console and access the component you need to make adjustments to it at the console. The high availability works on active-active so it does not require a switch automatically to the other component because they act simultaneously. And, of course, we can also work with active-passive mode if you make that choice.
I am not sure that this type of node management is an advantage to most users or not because in IT management you may not need this type of high availability design depending on the industry. But the capability is there and it can add stability to the infrastructure.
What do I think about the scalability of the solution?
I did not specifically examine scalability during the implementation because I did not have the chance or the necessity. We were in the process of considering all that we needed and not what would happen if we needed to scale to expand the system. From what I remember, we also had plugins that we could have installed so maybe the availability of plugins is an example that it is scalable in the sense of functionality.
But I think, with CA, that the scalability is fine and it is exactly what an organization will need as they grow. We are not involved in really scaling the product when we are deploying it.
For availability, I think you can definitely scale up as much as you want because you deploy the clients and the endpoint or the console. So in this way scalability works from an availability standpoint.
For scaling the functionality of the product itself, I think it will need some other kind of intervention or maybe new development. It depends on what you need and what they already have in the form of plugins. I know they have an API but we did not need to work with it for our purposes. With the API's you can extend the functionality outside the original identity.
During the process with a particular client that I have in mind, we argued about the starting point for the verification and whether it should be the HR system or the identity. This is a business decision that has to comply with the rules and business processes as defined by the organization and any regulations that apply. The question has to be answered before a solution can be put in place. With this client, we agreed that the starting point was the HR system, and one of the proposed solutions was that the HR system would call an API to perform the provisioning for identity. That was one possible approach. The second approach to working with identity was to install an agent on the HR system that could be run on a schedule. This solution is what we settled on and we agreed that this would be scheduled to run once a day, which is more than enough for what they needed to accomplish.
Because we chose the second approach we did not go for working with the APIs. The approach would be to run the process once a day on schedules like when most of the system resources would be in minimal demand — for example at the end of the workday. This would be done to check each employee for those that were added, transferred or changed privileges. And then an automated adjustment would be done for functionality and organization based on the established rules.
This is the kind of flexibility you have in deciding processes for an enterprise business — even a very complex business with demanding requirements. It shows another type of scalability.
How are customer service and technical support?
I did not have a chance to contact support personally, so I can not talk about how my experience with them was from a personal point of view. However, the people on the team right now working on projects who have called support said they were helpful. They have a good understanding of the product and seemed to have a lot of experience. I do not know what kind of resolution the members of our team were looking for from the support people. It might have just been for more information or troubleshooting or some type of issue resolution. But our company has had experience with the CA technical support team and from what I know the experiences were good.
How was the initial setup?
The initial setup is not that difficult. We deployed the components and deployed the agents. This is just the basic framework.
Our deployment took seven months because the design phase is very complicated. We need to collect information for the access matrix, we need to validate, and we need to do some kind of cleansing. So, it is a very intensive task. Mainly it is the design which takes most of the time, not the basic deployment. The difficulty is in the business logic, the business rules, and the cleansing of users.
Working with the system is an ongoing process. When users request a type of access, there are only two paths. One of them is to grant access and the other is to deny access. For the denial, we may have to go through a long approval process which requires some justification for the requested access.
The implementation team that we use is divided between different roles. It is not a very big team but it represents different functions in the operation. There are the technical people, the people responsible for identity management, those responsible for manual processes, the people responsible for revision to the business logic, the people responsible for validating the access matrix, the risk evaluation people, the IT people, the operations group, the compliance people, and, of course, HR. So we are talking about a sustainable team of maybe 12 people involved in the implementation activity, but up to as many as 20 may be needed for approvals or other consultation. A lot of parts of the company are involved with the implementation process and defining business rules, all for different reasons and functions.
What about the implementation team?
We are the ones who do the implementations, so we are the ones that others contact to perform this service.
What other advice do I have?
The advice I would give to others who are looking to implementing this product would be to define exactly what you need before the implementation of the solution. This is a key factor. If you need to change the deployment after it is deployed — such as the policies or structure — it is not a matter of just changing the configuration. It is more like you are starting from the beginning. If you have questions related to what needs to be addressed they need to be answered first. The way we deploy this is as a black box appliance. So it would be defined once. Even the IP cannot be changed. To make this type of change, it would have to be deployed again.
The biggest lesson I have learned from working with Identity Manager is that despite the product you use, the implementation is a process. You have to understand the process to see what activities do not give you value and also what activities serve to complicate the process. If you take the easier route and work with the standard deployment as much as possible, it will be more secure and faster. You need to see everything as an activity. So despite the impact that the product has on working with identity management, it is a process because the result is not to be blamed on the product at the end.
On a scale from one to ten where one is the worst and ten is the best, I would rate CA Identity Manager as an eight. To make this product closer to something like a ten they have to pay more attention to integrating with other solutions. Currently, CA is integrating is with CA products only. In some cases, there are categories that CA does not compete in, like Service Manager, so they should pay attention to out-of-the-box integrations with non-competing services.
They definitely have a problem integrating with solutions that compete and this is really another problem. Really, this type of integration would allow users of their product to have more flexibility. They could choose their own solutions which may better fit their needs. In one instance, we had to end up using different solutions for managing internal personnel accounts and managing normal users. This is not convenient and can be expensive. So I think they have to be more open to broader integration and simplifying those processes.
Which deployment model are you using for this solution?