Clear responsibility
for public-service access.

Make access ownership clear across public services

A public organisation can share infrastructure while keeping responsibilities distributed across departments and agencies. A central IT team may operate the directory, an HR team may maintain employment records and an application owner may decide who needs a particular service. Access governance connects those responsibilities so the decision can be understood later.

easyIGA helps people request, approve and review access to company and organisational applications. It uses midPoint as the underlying identity governance platform. Business participants work with readable requests and available evidence, while identity specialists maintain the configured sources, policies and integrations.

The first question for a public-sector implementation is ownership. Who is responsible for the identity record? Who can approve the requested access? Which system confirms that the approved change happened? A clear answer gives employees a usable process and gives the organisation a basis for oversight.

For a department manager, access governance becomes useful when a request names a service they recognise and makes their responsibility clear. They can assess the business need without administering midPoint. easyIGA supplies that request and review experience for workforce application access, while midPoint applies the configured changes. The illustrative scenarios below follow staff transfers, shared services and supplier access across the people who own those decisions.

Start with a service and its accountable owner

A department asking for better access management may begin with a long application list. A more useful starting point is one service with an identifiable owner and a recurring access decision. That could be a case-management application, an internal records system or a shared administrative service.

Write the access description in language that the service owner recognises. An employee should understand the difference between viewing a case and administering the application. A technical directory group can implement the permission, but its name alone rarely explains the responsibility to a business approver.

easyIGA's catalogue gives employees and managers a readable entry point. The underlying configuration determines the role and the decision path. The implementation must keep the description aligned with the real target permissions, especially when the application changes.

The service owner should also define who is allowed to request each role and who decides. An organisation chart may identify a line manager without identifying the person responsible for sensitive application access. Those authorities need an explicit relationship in the process.

Use one ordinary request in the first demonstration. Ask the employee to explain what they selected and the approver to explain the decision they are making. Then show the recorded outcome. This checks the full path from business meaning to a target-system result instead of judging the product only by the appearance of its catalogue.

Support staff moves without accumulating old permissions

A civil servant can move between teams or temporarily support another service. The new role may require additional access, while some previous permissions should end. A move is therefore a change in the access relationship, not merely an account update.

midPoint provides the configured identity lifecycle and provisioning foundation. The implementation team determines how authoritative source changes affect the roles in connected systems. easyIGA supplies the business-facing request and review experience around midPoint.

For a transfer, define the before-and-after position. List which permissions follow the new assignment, which remain for a justified reason and which require removal. Include temporary access where the person is completing a handover. The rule should be specific enough that a reviewer can explain an exception without relying on memory.

Demonstrate the process with synthetic identities. Show the source change, the configured decisions and the target results. A successful new grant does not establish that the old permissions have been removed. Inspect both sides of the move and identify any destination whose result remains pending or unknown.

The organisation also needs a process for correcting late or inaccurate source information. If the reporting line is wrong, a request can reach the wrong person. Decide which team corrects the source and how the access process handles the interval. A readable interface helps participants see the task; it does not replace data ownership.

Govern shared services without erasing agency boundaries

Shared infrastructure can reduce duplicated administration, but it does not make every access decision a central IT decision. A shared service may support several agencies with different owners and different reasons for granting access. The identity model should preserve those responsibilities.

Begin by identifying which facts are shared and which remain specific to the participating organisation. A person may have one identity record and several organisational relationships. The meaning of each relationship needs to be agreed before it is used in access policy.

For an evaluation, select a role that is appropriate in one department but not automatically appropriate in another. Ask the implementation team to demonstrate the intended request visibility and approval authority. Confirm the behaviour of the proposed easyIGA release rather than assuming a generic multi-organisation capability meets the requirement.

The specialist team should explain how the underlying midPoint roles and authorisations represent the agreed boundary. A business participant should be able to recognise the scope from the request description. Those are complementary tests: configuration accuracy and understandable use.

Also plan for organisational change. A department merger can alter ownership without changing the application itself. Record who updates the role descriptions and approval responsibilities, and how the revised configuration is tested. The identity programme needs a maintained representation of the organisation, not a one-time copy of a structure that later becomes obsolete.

Keep outsourced work tied to an internal responsibility

A supplier can provide support or project staff without becoming the authority that decides its own access inside the public organisation. The organisation needs an internal sponsor who understands the work and can justify the requested permissions.

Create a clear identity source for external workers. Establish the relationship to the supplier, the internal sponsor and the information needed to distinguish each person. Avoid using a shared login as a substitute for a defined access relationship when individual accountability is required by the organisation's policy.

easyIGA gives the relevant participants a place to request and decide on application access. The configured policy still governs the route to approval. A contract reference can help explain the business context, but it should not automatically become permission to access every system associated with the supplier.

A useful test covers an extension and a sponsor change. An external worker may remain on the same project while the internal manager moves. The access record should remain attached to a current responsibility, and the organisation should know who examines it next.

At the end of the engagement, inspect the target result rather than relying on the supplier's departure notification alone. An approved removal may still be waiting for a connected application. Establish the follow-up responsibility and the records needed to demonstrate completion. This closes the gap between a procurement event and actual application access.

Give reviewers useful evidence without creating a fictional history

Public-sector oversight often requires an explanation of why a person had access at a particular time. A list of current permissions answers only part of that question. The decision and the available history are also relevant.

easyIGA presents access for review with the context supplied by the connected sources and captured approval records. Last use, granted by and approved by can help a reviewer, but these fields must retain their actual meaning. An account owner is not automatically the original grantor or approver.

easyIGA records the requester and captured approval steps for requests made through the product. Access granted outside easyIGA is identified separately, using the creation details recorded by midPoint. Historical records may lack an approver or grantor; missing information is shown explicitly.

Choose an evaluation sample with a complete record and another with incomplete history. Ask what conclusion the reviewer can support in each case. Some permissions may be needed only occasionally, so the absence of recent use should lead to a business assessment rather than an automatic conclusion that access is unnecessary.

Agree the next step for uncertainty. The application owner may need to investigate a permission or obtain a fresh business decision. After a decision to remove access, follow the change to its recorded outcome. This makes the review useful as an operational process rather than simply a completed administrative exercise.

Separate the access decision from its execution

A manager can authorise access while the target application is unavailable. A configuration error can stop a change after the business decision has been made. If the interface reports only approval, the requester and the control owner can both misunderstand the actual situation.

easyIGA distinguishes verified, pending, failed and unknown outcomes. This provides a common vocabulary for the business participant and the technical operator. The result that can be verified depends on the connected system and the evidence available from it.

In a public-service context, responsibility for follow-up should be explicit. The person waiting for access needs to know that an approved request is still in progress. The operator needs enough information to identify the affected integration. The service owner needs a route to escalate a case that affects the work.

Test an unavailable target during the pilot. Observe the status and the subsequent recovery path. The fact that a change can be retried does not remove the need to check the eventual result. Record which operation was completed and which remains unresolved.

Use the same distinction when preparing reports. A count of approvals should not be described as a count of verified target changes. A review of outstanding cases can then focus on the work that still requires action. This is a small but consequential difference in the meaning of an access record.

Retain technical control through the midPoint foundation

midPoint is an open source identity management and governance platform with public documentation. It provides the underlying mechanisms for configured identity data, roles and provisioning. easyIGA adds the business-facing experience used for requests, decisions and reviews.

This division can be assessed by organisations that already operate midPoint as well as those planning a new identity programme. Use the same application scope when comparing the options. The question is what changes for the people making decisions and what remains with the specialists operating midPoint.

A technical evaluation should examine the target operations, the source data and the role model. The midPoint connector catalogue is a starting point, but it does not establish compatibility with every version or permission structure of a public-sector application.

Long-lived systems deserve particular attention. An application may accept account changes through a different mechanism from the one it uses to expose permissions. Document the integration boundary and any manual work that remains. A known limitation can be managed; an assumed capability can become a failed acceptance test.

Evolveum's public-sector page describes use cases for midPoint. An easyIGA walkthrough can focus on the people working with a particular public-service application. Let the department owner assess the request, the shared-service team inspect the technical outcome and the control owner examine the available evidence. This makes the discussion relevant to the actual division of responsibility between the agency and its service provider.

Decide where identity data belongs

Self-hosting is the default easyIGA deployment model. The organisation can operate the solution on its infrastructure and in its chosen jurisdiction. An EU-hosted deployment operated by our team is available on request for organisations without suitable infrastructure.

Deployment location alone does not answer every data-governance question. Determine which identity attributes the workflow needs, who can view them and how records are retained. Access to personnel data should follow an understood purpose rather than the assumption that every available field should be copied into the identity platform.

The procurement and security review should also examine operational access. Identify who administers the service, how updates are handled and what support arrangements apply. Request the actual terms for an operated option rather than inferring a service level or data-processing arrangement from its location.

For self-hosting, assign an operating owner and include internal effort in the plan. Backups, recovery tests and connector maintenance are part of a functioning service. The implementation should establish how configuration changes are reviewed before they affect access.

These questions do not require a complex public promise. They require a concrete deployment proposal with responsibilities attached. Use the deployment page and security information to prepare that discussion, then record the evidence required by your own organisation's approval process.

Make procurement compare equivalent scopes

midPoint has no software licence fee. Some midPoint capabilities, such as simulations, high availability clustering or a database other than PostgreSQL, need an Evolveum subscription, which we arrange and include in your quote. easyIGA is a commercial layer with a published annual subscription model per governed identity and deployment included in an agreed scope. Current prices and the contracted feature set must be confirmed in writing.

For a public procurement exercise, define the populations and applications consistently across the options being evaluated. Employees, external workers and service accounts can create different governance requirements. The definition of a governed identity should be explicit enough that future growth does not create an unexpected interpretation.

State the integration and migration responsibilities. A quote should identify the systems and operations in scope, the data cleanup expected from the organisation and the acceptance evidence. An included deployment does not imply an unlimited migration or a fixed completion date regardless of source quality.

Compare support and operation as well as software. An organisation with an established midPoint team may allocate work differently from one commissioning a new service. Include that difference in the cost model rather than assuming that each option requires the same internal effort.

The pricing page provides the current model, and the midPoint comparison explains the responsibility split. Use actual written offers and your own workload figures. This produces a procurement discussion that can be checked without relying on unmeasured savings or a claim that one option is universally cheaper.

Keep workforce access separate from citizen services

A public portal may authenticate residents while an internal application determines what an employee can do with a case. Those are separate identity relationships. The workforce governance scope should identify the staff and supplier permissions it controls without implying that easyIGA provides a national electronic identity service.

For a case-management example, ask the service owner to describe the internal role and the information it permits the employee to access. The identity team can then assess how that role is represented in the target application. A citizen's ability to submit a form does not establish any authority for an employee to administer the service.

This distinction also improves procurement. Describe the actual population and operations in scope so a workforce IGA offer is not compared with an unrelated customer-identity or authentication service. Where the systems interact, document the approved boundary and test it explicitly.

Test a public-service workflow before expanding it

A practical pilot should answer one clear question about a service. Select the access role, the people responsible for it and a representative target system. Use synthetic records initially so the demonstration does not require sharing live personnel or case data.

Include a transfer between teams and a supplier case. Add a request with a missing business owner and an operation whose target result cannot be immediately confirmed. These examples reveal where the organisation needs a policy decision, a source-data correction or an operational handover.

Ask business users to explain what the screen tells them. Ask specialists to show the configuration and the exception path. Record both results. A technical success that the approver cannot understand and a readable request that cannot be executed are different problems; the evaluation should be able to identify either.

At acceptance, record the release and the precise scope demonstrated. Keep planned functionality separate from current capability. Preserve any unresolved evidence gaps and assign them a next step. That record makes later expansion more deliberate because the team knows what the first phase actually established.

Request a 30-minute walkthrough with our team to examine the current easyIGA workflow. Bring one access decision that your organisation wants to make clearer, and use it to define the technical and business questions that a scoped evaluation should answer.