Onboarding Service Provider Application Implementation

[jjeroch]

Summary:

This feature involves creating a new product, the Onboarding Service Provider (OSP) Application, which will facilitate the registration services for OSPs. The implementation will require setting up a new repository that houses both the frontend and backend components of the application. Additionally, a Helm Chart will be created for deployment purposes.

Objectives:

• To set up a new repository for the OSP Application
• To develop a frontend application that utilizes the shared-component-library
• To create a backend service that supports registration functionalities
• To ensure the frontend has a standard integration with Keycloak for authentication
• To allow easy switching to alternative Identity Providers (IdPs) for consumers
• To provide a seeding file for data migration

Illustration (Architecture)

Acceptance Criteria:

1. Repository Setup:

   • A new Git repository is created with appropriate access controls.
   • The repository should include separate directories for frontend and backend code.

2. Frontend Application:

   • The frontend application must be developed using the shared-component-library for UI consistency.
   • It should have a standard configuration to integrate with Keycloak for user authentication.
   • The application must allow for easy configuration changes to connect to alternative IdPs.

3. Backend Service:

   • The backend service must provide APIs for registration services.
   • It should support CRUD operations for OSP data management.
   • The backend must be secure and scalable.

4. Helm Chart:

   • A Helm Chart must be created for the application deployment on Kubernetes.
   • The chart should include configurations for both frontend and backend services.

5. Authentication Flexibility:

   • The application's authentication mechanism must be designed to be flexible.
   • Documentation must be provided on how to switch between Keycloak and other IdPs.

6. Data Migration:

   • A seeding file must be created to facilitate initial data migration.
   • The seeding process must be documented and easily executable.

Non-Functional Requirements:

• The application should be scalable to handle a growing number of OSPs.
• Ensure high availability and fault tolerance of the service.
• The application must follow best security practices, especially in handling authentication and user data.

Dependencies:

• Access to the shared-component-library repository.
• Availability of a Keycloak instance for authentication integration.
• Availability of alternative IdP services for testing the flexibility of the authentication mechanism.

Risks:

• Delays in the availability of the shared-component-library may impact frontend development.
• Integration complexities with Keycloak or other IdPs may extend the timeline.

Documentation:

• A README file in the repository detailing the setup and local development instructions.
• An architectural diagram of the frontend and backend integration.
• Arc42 documentation
• A guide on how to switch the authentication services for the frontend.

Stakeholders:

• Onboarding Service Providers
• CSP-B's
• CSP-A's

---

[stephanbcbauer]

Was presented in the open planning ⇾ done internally within in the portal team, developer and committer are involved

[diegocaceresm]

As OSP, let us connect on this ticket.

[stephanbcbauer]

Hello @jjeroch , @evegufy

Since the feature is a 24.08 feature and the development phase is coming to an end, we need a status on the feature.

• [ ] Currently you are assigned (Responsible) → Is this correct? If not, please assign the correct contact person
• [ ] Please check whether the status (backlog, work in progress ...) is set correctly
• [ ] Please check whether there is an assignment to a committee or expert group (supported-by) to be found on the board
• [ ] Please comment on the current status of the feature
• [ ] Are all SubTasks (issues from other repositories that deal with the feature) linked? → The easiest way is to mention the feature here in the issue (via the ID) so we can see which teams/repositories are involved.

If you need any clarification, please get in touch, thank you very much. Stephan

[jjeroch]

Roadmap issue linked. Start with 24.12. Ownership does not change