Business Analyst

Technical Requirements:

• Microsoft Active Directory and Red Hat Identity Manager.
• Authentication, authorization, SSO and MFA.
• Identity federation and integration with multiple Identity Providers (IdPs).
• Roles, groups, permissions mapping and access management.
• Application onboarding and IAM integration.
• Access governance and user access lifecycle management.
• Functional specifications, user stories and acceptance criteria.
• User Acceptance Testing (UAT).
• Stakeholder management and coordination with technical teams.
• Functional documentation and knowledge transfer.

The candidate needs to be able to work on the following tasks on 6 phases/deliverables:

Business Needs Analysis and Current-State Assessment:

• Gather and analyse the business needs for authentication and access management through workshops and interviews with the business owners, registry staff and application owners identified by the Court.
• Review the existing IAM documentation, available incident information and user-reported issues (including SSO behaviour, logout/session handling and MFA) from a business and user-impact perspective, in liaison with the Court’s technical teams.
• Assess how well the current IAM service and the applications already integrated meet the business needs, and identify gaps, risks and dependencies; distinguish those that can be addressed through configuration from those requiring application changes or separate projects.
• Translate the business needs into prioritised business requirements with measurable acceptance criteria, and agree them with the Court.
• Establish a requirements traceability baseline to be used for the implementation follow-up and the acceptance testing.

Existing Permissions Models and Alignment with the New IAM Platform:

• Inventory and study the existing roles, groups and permissions models in Active Directory, Oracle WebCenter Content, the candidate applications in scope and the current IAM.
• Analyse with the business owners how access is granted in practice, including the authorisation hierarchies and the dynamic changes stemming from jurisdictions protocol order, as generated in sources such as Litige.
• Identify duplications, inconsistencies, obsolete permissions and gaps between the existing models and the business needs.
• Define how the existing permissions are aligned and can be mapped into the new IAM platform, identifying which information should be managed centrally in IAM and which should remain under application responsibility.
• Define the requirements for automating the dynamic creation of protocol order in IAM and populating it with Active Directory identities, for the authorization model to be implemented by the Court’s technical teams.
• Propose a functional migration approach for replacing the existing accesses and permissions in legacy solutions by IAM, and validate it with the business owners and the internal Curia Teams.

Application Onboarding and Implementation Follow-up:

• Assess each application’s identification and authorisation needs, user populations (internal and external) and dependencies, and define the business requirements and acceptance criteria for its integration with IAM.
• Define a consistent approach so that users authenticate once and access participating applications without unnecessary repeated authentication, subject to given permissions, security policy and session controls.
• Identify and catalogue use-cases requiring multiple identity providers or distinct authentication journeys, including internal and external users.
• Act as the link between the business owners, application teams, development teams and the Court’s technical teams: clarify the requirements, support the planning and follow up the implementation of the configurations and integrations against the agreed business requirements.
• Track progress, decisions, risks, requirement changes and open actions, and report on the status of each application to the Court.
• Document the application-specific business requirements and the changes to be implemented by the application teams.

Authorization, Roles, Groups and Permissions Model:

• Define, from the business point of view, the required level of access granularity and the operational implications of alternative group and role models.
• Define the target roles, groups and permissions principles so that access is governed coherently across the candidate applications, building on the results of ST02.
• Define the joiner, mover and leaver rules and the lifecycle requirements for creating, updating and revoking groups, group memberships and user permissions, including the API and synchronisation needs to be implemented by the Court’s technical teams.
• Consider dependencies with other architectural components (such as events management), in order to streamline permissions and groups changes across the candidate applications.
• Validate the target model with the business owners and application owners and obtain the Court’s approval before implementation.
• Follow up the implementation of the model and check that the permissions in place correspond to the approved model.

Delegated Access Management by Business Users and Governance:

• Review the current access-request, approval, modification and revocation processes with the business owners.
• Identify, with the business users, the permissions that authorised business users (including registry staff and team managers) should be able to manage themselves through IAM, its API or equivalent application integration, while preserving appropriate oversight.
• Define the functional requirements, use cases and user stories (request, approval, modification, revocation, delegation) for a portal or SSO integration

Business Acceptance Testing, Documentation and Knowledge Transfer:

• Prepare acceptance test scenarios derived from the business requirements aligned with Regulation (EU, Euratom) 2023/2841, covering authentication, MFA where applicable, logout, application access, authorization enforcement and delegated permission management.
• Coordinate and support the business acceptance tests with the Court, the business users and the application teams once each implementation is delivered, and record the results and defects.
• Verify, using the requirements traceability baseline, that each business need has been accomplished, and report any unmet or partially met requirement.
• Provide a prioritised backlog of remaining actions, dependencies and recommendations.
• Produce user and business-process documentation (e.g. procedures for requesting and managing permissions) and conduct knowledge-transfer sessions for the internal IAM and operational teams and the business users, providing the associated materials.