IdM System Implementation Considerations

This article explores important considerations for implementing IdM systems such as implementation processes, role-based access management model, and existing IAM services for processing and managing user access.

Important considerations for identity management IdM system implementation

How to form the concept of the project

Let us start with the basic questions that arise at the initial stage of cooperation between the IdM vendor and the customer.

What is the scope of the IdM system implementation project? Should it be as extensive as possible, carry more value but assume a long implementation timeline, or should we focus on the most important tasks that involve rapid implementation?

The scope should demonstrate to the customer the future value of the IdM system implementation. We are talking not only about the top management of the company and employees of the department who are direct recipients of the final solution but also about other departments. Implementation costs are borne by the entire company, so the effect should be clearly visible to all people; otherwise, full personnel involvement can hardly be achieved.

To participate in the implementation, employees of the customer who are not related to IT and information security need to be interested and motivated. The vendor should show them the benefits that they will receive after the implementation of the project. For example, it is advised to include in the project’s automation opportunity of routine operations that are currently being performed in manual mode. This way, the effect of IdM implementation will be more noticeable.

Also, we must not forget that a user friendly web portal, the ability to build clear reports, and other visual aspects are important parts of the implementation. When defining the scope, it is impossible to consider only the technical parts of the project.

The first stage of implementation should include a small number of systems that provide maximum value for the customer. Initial small coverage of the core systems will bring enough benefits to users and administrators.

What IdM implementation approaches are the most promising

How much should the customer and the vendor formalize the implementation parameters? Do you need a strict technical assignment, or is a flexible approach acceptable? How to reconcile the need for changes discovered in the process of project implementation with the initially defined financial and technical parameters?

According to experts, a flexible approach to implementation requires a high level of trust between the vendor and the customer. It is very important to clearly define the project’s boundaries so that it does not turn into an uncontrollable and endless process. You need to clearly define and fix the final goal for the customer and labor costs for the vendor. One of the options is to conduct an agile session/meeting before finalizing a contract in order to determine all technical parameters more accurately.

The implementation process should not be vague for the customer, regular meetings are needed where the parties could discuss the status of the project. Such involvement of the customer representatives will allow them to influence the course of work and will allow the vendor to adjust to a certain extent the expectations of the other party.

When working on the technical requirements and specifications, the vendor must constantly keep the dialogue with the customer and be ready for changes. Usually, it is good to break the implementation process into stages to provide the project with the necessary flexibility without losing sight of the ultimate goal.

A clear technical assignment is needed at the first stage. It is needed to participate in the competitive bidding process and form an initial “scope” that will show the customer the key benefits of your solution. In the future, as trust between parties grows and customer engagement increases, you can try and use informal cooperation.

Method of work can also be determined through a pilot project, during which the customer and the vendor can get to know each other better.

Once again, it is important to emphasize the importance of customer involvement. The client’s team should not remain an outside observer of the implementation process, since they will have to manage the ongoing maintenance of the system.

Is it possible to implement an IdM system without a ready-made role model?

Are there any chances of successful IdM implementation if the customer does not have a developed role model? Is it possible to automate chaos? Is it possible to build the role model during implementation?

Some experts advise starting with a description of the main HR functions – hiring, firing, moving around. This will ensure a good and speedy start for IdM implementation. Further development of the role model and the description of all the business processes can be performed as the project progresses.

Creating a complete role model will require a lot of resources and can significantly increase the time and cost of a project. In addition, the role model often becomes outdated the day after it is agreed upon. There is little point in fixing it at the beginning of implementation. Sometimes it can be convenient to build the role model around the ready-made IdM toolkit, which will allow you to always keep the role model up to date.

How to build a role model

How should the process for defining roles be structured? Should this process be based on historical data and analysis (Role Mining) or business insights obtained through executive surveys, job descriptions, and other tools?

Actually, the best results are obtained by the symbiosis of several methods. Historical data provides insight into the current access matrix, while executive surveys provide insight into how it fits the company’s rights management goals and objectives. Existing permissions on the level of departments and individual employees should be discussed with the owners of business processes in order to cut off unnecessary privileges and, possibly, add new roles.

In order to avoid misunderstandings between the vendor and the customer, it is recommended to negotiate in advance at what stage, by whom, and at whose expense the role model will be created. Role Mining is not a magic button that will help eliminate all the problems, but only a starting point for building a role model.

It is also important to understand how deep the vendor can dive into role management and where the project boundaries lie. For example, should its scope include setting up roles in SAP or another system used by the customer?

The success of the project depends on how well the customer’s employees are trained to create a role model. It is also important to understand that there is no universal method for building a role model. What works for a bank will not work for a manufacturing company. The size of the organization also plays an important role – the smaller the business is, the easier it is to build a role model.

Client side

How are the portals for processing requests organized? Which toolkit is better to use for this built-in IdM tool (like the IT Shop module) or an IT service management (ITSM) portal that the customer has already implemented to process user requests?

These questions can be approached from the point of view of user convenience. If the company has a well-developed service desk (toolkit for working with user requests), which receives requests from disparate systems, then it may be better to integrate the functions of the IdM portal there. When there is no such tool, it makes more sense to use a separate IdM web interface. The process of access granting in Identity Manager can go in two ways:

  • Built-in IdM system algorithms.
  • Built-in algorithms of the external system (not necessarily of the service desk level) with the transfer of the final result to IdM.

It often happens that it is more convenient for the vendor to use the IT Shop, which is part of the Identity Manager, since this way, the vendor can independently develop this portal and be confident in its functions. On the other hand, if the customer has already built an ecosystem of his business processes around a specific service desk, then it is hard to transfer it to the portal of the IdM system.

Of course, it is more convenient for users to have a single service for processing requests; therefore, implementing it through IdM, you may have to duplicate some of the ITSM functions.

The implementation of the portal for processing requests using the IdM system allows you to link the processes associated with access to the events of the HR system, for example, the reassignment of the responsible person in case of dismissal.

Publishing an IT Shop on the Internet makes sense only if business executives regularly need to access these coordination tools. Ordinary users do not need such an opportunity. The only thing that an employee may need from the outside is to reset the password; other access issues when working remotely are solved using a VPN. Another aspect of this problem is the external user registration portal. Make sure to protect it from attackers as phishing, web injects, redirects and other hacker tricks are on the rise. It makes sense to make it as a separate, protected replica of the general interface with limited functions.

Integration

What are the nuances of connecting IdM systems with other solutions used by the customer? Should synchronization with the HR system be event-driven or done with regular intervals or in real-time?

Often, regular synchronization is not much different from event-based synchronization, since events are also piled onto the stack, which is processed at a specified frequency. It is technically possible to implement event-based synchronization in real-time. Still, the use of a queue makes it more convenient to handle numerous user requests, which often happens in large organizations. The less often HR events are processed, the less the risk of transferring an unfinished operation to the IdM system.

Of course, there may be some urgent events (for example, an unplanned dismissal of an employee) that need to be communicated to IdM promptly. For this purpose, there is a specific user blocking option. Customers often want everything to be in real-time; it is possible to explain that they do not need it.

The frequency of contacting the HR system by the IdM system should be set for each organization separately. One of the factors is the load on the HR system. In practice, there are examples of using an intermediate database, which collects information from several systems, for later uploading to IdM.

Continuing the topic of linking IdM with other systems, it is necessary to touch upon the issue of implementing risk and compliance management functions. Such projects are rare. If the customer has already implemented a GRC system, he will most likely refuse to transfer its functions to IdM.

When it comes to integration with other solutions, such as SSO or PAM systems, a properly designed IdM can facilitate the implementation of such solutions. If the customer has not yet implemented SSO or PAM, then it is reasonable to build an architecture for two solutions together and implement them one at a time.

Conclusion

Here are three main advantages of implementing an IdM system. They can be used as a justification for the need for such a solution for the customer.

  1. Reducing the cost of administering access rights by automating routine operations.
  2. Quick employee onboarding, reduction of downtime associated with registration of a new employee.
  3. Increased security by reducing risks (unnecessary rights, access rights left after employee dismissal, etc.).

Identity Management Use Cases

Identity and access management architects can benefit from the following identity management use cases to improve Identity, Credential, and Access Management (ICAM) practices within their organizations.

The identity management use cases listed for ICAM best practices are approved by the US government as IAM guidelines for various government agencies. These cases involve several factors that contribute to the use and deployment of the use cases. They include the personnel who are part of the ICAM cycle and the systems involved, with a high-level summary of the possible actions. The listed identity management use cases tend to be interrelated, even with each specific ICAM business process. The technologies and activities are generalized in these cases, ensuring their application can be diversified across many organizations. It is important to note that the detailed processes in these identity management use cases are not specific to an organization or department. Every entity should analyze its own systems and processes for alignment with the use cases. Below is comprehensive information on what the use cases entail and how you can use them to your enterprise’s advantage.

Identity Creation and Maintenance

When organizations onboard an employee or a contractor, they collect identity related data from the person, and store pieces of the information as identity attributes which serve as a digital proxy to identify the person within the organization. The attributes will be aggregated into a single identity format to keep individual identities unified.

Federal Identity, Credential, and Access Management Architecture v3.1

The administrator is mainly involved in collecting and managing employee’s identity data throughout the IAM life cycle. The identity information collected doesn’t necessarily have to come directly from the individual. Identity information can also be collected from HR systems, or onboarding documents.

Creating an enterprise identity comes next, with the administrator adding the identity information into the pre-determined data repository. The process results in having an authoritative source for the enterprise identity of the individual. Maintaining the enterprise identity data is essential to keep up with any changes that may affect your organization. Identity maintenance should be performed as often as possible. It is preferable to treat identity maintenance as an ongoing process to avoid missing out on vital data that may negatively affect the IAM lifecycle. The process is imperative, mostly when the individual has updated their personal information. Changes need to be made to maintain an effective identity system. Your identity maintenance’s final process is making updates to your enterprise identity system. There are two ways in which you can make the updates. An administrator can directly update the set authoritative sources, or, allow the individual to use the system to update the information they are changing. The data will automatically update the system on the identity attributes based on the authoritative source.

Proof an Identity

The creation and assigning of a credential to an individual needs some proof of the person’s claimed identity. Also known as identity proofing, it is an essential process through which an organization is involved in collecting and verifying information of an individual so that it can be used to establish an enterprise identity. The Identity Assurance Level (IAL) platform is perfect for determining the critical factors you should consider when conducting identity proofing of the individual.

There are up to three IAL’s that you can use to get the process going. But for federal agencies, there is a minimum requirement of IAL2 for contractors or employees who have recurring access to the government’s resources. With these use cases, IAL1 is not included.

Such use cases mainly describe the steps for proving an identity both at IAL3 and IAL2, which are high-level steps into the process. Some IALs may require more information about the employee, even with other verification processes. Depending on your entity’s processes, you can’t quite know the required IALs until you begin the identity proof process.

Having sufficient information about the individual is important to avoid wasting time in the identity management process. The more information you have at hand, the better it is. The contractor or employee’s information can also be referred to as identity evidence. It may be physical; these are either a driver’s license, birth certificates, passports, or any other valid credential available and verified for use in the IALs.

For the IAL2, the following information may be required:

  • Last name
  • First name
  • Address of record
  • Email address

For this IAL2, all the information must be supported by valid identity documents, and the verification rate should be high. After collecting the identity information, which can be remote or in-person, the administrator will need to confirm the provided information is valid and latest data. Comparison of photo identification may be necessary and the address must match the same information provided in the documents presented.

For the IAL3, the following are some information you will need:

  • Fingerprints
  • Address of record
  • Email Address
  • First name
  • Last name

For the IAL3, all the information must be supported by valid identity documents, and the verification rate should be superior. The administrator has the freedom to make verifications with the issuing organization. This may result in the successful proof of the individual identity at either IAL2 or IAL3.

Entitlement Lifecycle Management

Lifecycle entitlements are assigned to individuals, their roles, and even groups. The entitlements are set to determine access to the agency services by the employed individuals or contractors. If the entitlements are not assigned, the employees don’t have authorized access to the entity’s services. The process is straightforward.

The first step is to initiate the request from the individual. The individual will have to request access to the entity’s services and wait for the administrators’ feedback. The individuals can also join specific groups with access to parts of the entity’s services and directly access what they need. The requestor may be anyone within the firm, such as the supervisor, employee, security personnel, or even a general contractor.

The next step involves a review of the request from the requestor. At this stage, the administrator’s work compares the individual’s request with his access requirements based on their working position. If the requestor qualifies for access to the entitlements and there is a relevant need, the administrator has a green light to approve it.

As soon as the administrator assigns the entitlements to the contractor, they can receive the necessary entitlements without any limitations. However, consider there may be a change in the contractor’s role in the organization. The administrator has the right to change the entitlements as necessary or even terminate the entitlements.

Create and Issue a Credential

Creating credentials for an individual is only possible after completing an individual’s identity proof cycle. Think of the certification as a physical card that gives access to the entity’s services. It is a form of authenticating the individual’s identity to gain access to the system. For contractors and employees, the preferred credential is the Personal Identity Verification (PIV) card.

Just in case the administrator cannot issue a PIV card to the employee, you can use a combination of factors to get to the credentials of the Authenticator Assurance Level 2, also known as (AAL2).

This use case is a three-step process. The first one is to initiate the request. The individual who needs the credentials for access has to provide an identification card issued by the government.

The review process verifies the issued government identification card. The final process is to generate authentication credentials for the employee or contractor. It can work for individuals who need access to buildings and even protected resources for specifically authorized work.

Issue a Derived Credential

A derived credential comes directly from an already existing credential but has a variation in its form factor. This form factor can be a mobile device or any other portable device that can show the credentials. Their derived credentials use the data initially used in the IAL verification process from the existing credentials.

It can have a lower AAL or the same one depending on the individual’s access needs. The derived credential is mainly applicable in areas where the individual needs authentication to have access, but they cannot seem to get it. Leveraging on the derived credential is the best way to gain the same access without the strict authentication requirements.

The individual only needs to have Authenticator Assurance Level 3 or two to use the derived credential when the situation arrives. Obtaining the derived credential is also relatively easy as long as all parties are involved. Initiation of the request is the first step. The individual’s request on the identity data is sent directly to the identity manager for processing.

The identity manager could be a system or a person depending on how a specific organization operates and its resources. After the request, the identity manager needs to authenticate and verify the credential that already exists. The sources for authentication of data retrieved can change from one to another, including personal databases, HR systems, and security data.

The final stage is generating the derived credential for the individual to use. There is a notable change in the enterprise identity record of the user. The derived credential can be applied in different scenarios. It includes the need to authenticate an enterprise’s application by an employee who already has an enterprise credential.

Accessing secure websites through VPN from a remote location is also an example where a derived credential may be necessary.

Managing the Credential Lifecycle in Identity Management Use Cases

Like any other identity management use case, all active credentials need regular maintenance to keep them functioning to their optimum levels. This use case shows the most popular activities for credential maintenance. These are:

  • Resetting a credential – Resetting a credential is applicable when a contractor forgets his identification number or password needed for authentication. The individual will have to request a reset to continue using their credentials.
  • Renewal of credentials – It is necessary to renew an individual’s credentials if expiring and still need to use them. It is also applicable to renew the credentials if the individual’s identity information has changed. In this situation, it is possible to request a replacement credential. It is best to renew the credentials before they expire to avoid the wait time for creating another one.
  • Revoking a credential – When an individual is no longer working with the entity, the administrator needs to request revocation of the individual’s credentials and any other enterprise accounts they may still have access to. The administrator, in this case, can be the supervisor, sponsor, or any other personnel to high-level access.

All administrators should review their employees’ or contractors’ credentials and eligibility to identify data that may be orphaned in the system.

Granting Access in Identity Management Use Cases

The grant access use case mainly entails individuals’ authentication to authorize their agency services access. The agency services can range from files, physical facilities, specific applications, and just about any special resource that needs access.

It involves an Access Control System administrator, also known as (ACS). This administrator’s main function is granting access to the employee as long as they have both an active credential and an enterprise identity. The individual will also have to have a specific reason to access the enterprise’s resources. The following are some of the steps that the individual must undergo to get full access to what they need.

• Authentication – Authentication is the first step to getting through the Access Control System to get your access granted. The individual’s identity needs to be verified to validate the person who needs to access the entity’s service. • Authorization – Through authorization, any employee or contractor that meets the criteria can be granted access. This limits access to a specific number of people. The process is not complicated but has a couple of steps to get through the verification process.

The first step is the access attempt. An employee or any contractor needs to access the entity’s services. Then at the second step, the authentication process begins to determine who the individual is. The individual has to ensure the minimum assurance requirements are met. The authenticator uses the AAL2 and the AAL3 for the process.

The AAL2 uses a two-factor process, while the AAL3 uses the two-factor process and the authentication hardware. As soon as the authentication is successful, the ACS identifies the individual’s access entitlements and the protected resource. The ACS then compares the employee’s access entitlements and decides to either authorize or reject the request.

If all the details match up the requirements, the ACS grants access to the agency’s resources. The ACS keeps the information for auditing needs.

Accepting Federation Assertions

Using federation to accept authentication assertions and identification is important to ensure access is limited and only used for the right purposes. Reports can be generated by inter-connected agencies or business units for sharing individual or contractor attributes for easier access and functionality.

Government Identity Management Use Cases

For government identity, complex identity governance use cases are essential for identifying management systems for some sections of the government’s special needs. These can be sections such as national security and law enforcement. Every service-oriented part of the government is directly proportional to its role in every citizen’s life. The identity governance use cases in government identity cases can facilitate many responsibilities and accountabilities in the country’s agencies.

Access Management Use Cases

Through access management use cases, avoiding strict bureaucracy makes it more efficient to access and use resources making it beneficial to citizens and improving their overall living standards. Authentication of enterprises’ identities and access to protected services is vital to keep the government systems functionating. With supporting elements such as federation and governance, there’s so much that ICAM technologies can facilitate ensuring systems are running as smoothly as possible in a secure mode.

Conclusion

Supporting business objectives is essential for moving towards success. Applying identity management use cases in business processes is the best path forward for government agencies and organizations to offer uninterrupted services while ensuring system security and data protection.