• Rough draft

    • Sandbox portal

    Owned by jarkkohyoty
    Last updated: Dec 28, 2023
    2 min read

    Conceptual view of the sandbox portal

    Exposing applications and building blocks through a simplified portal

     

    In this version, the portal is reduced to a method of exposing selected user interfaces from the Sandbox

    • Demo applications (e.g. USCT)

    • Selected building block admin interfaces (restricted)

     

    • The “portal” is not considered to be part of the (reproducible) Sandbox, it is a layer around the Sandbox and exists so that the GovStack organization can showcase the building blocks.

    • Applications (and building blocks) running inside the Sandbox should not expose any user interfaces on their own.

    • All interfaces are exposed “from the outside”. Technically

      • Sandbox (Sandbox team) owns and manages the AWS resources (load balancers, listener rules, and target groups) that are needed for routing HTTP traffic to applications running inside the sandbox cluster.

      • Building block providers identify the services that can be exposed.

      • Inside the cluster, a target group binding (AWS load balancer controller custom resource) is used to bind a exposed interface to a pre-defined target group. This ensures that the target group is automatically updated if e.g. the building block is redeployed.

        • Identity BB (Mosip) is an exception, and the relevant user interfaces are exposed via a network load balancer.

      • For restricted interfaces (e.g. building block admin interfaces), a pre-authentication step is implemented: Before being able to access some interface, a user needs to authenticate using personal credentials. These credentials are given to a limited user group for the purposes for showcasing the applications.

        • The pre-authentication step leverages ALB functionality and AWS Cognito, thus custom development and maintenance of the authentication components is avoided.

    Shortcomings of this approach

    There are some shortcomings that can be addressed in some future iteration of this setup:

    • It is difficult to fully automate the setup (e.g. the target groups need to be pre-defined). In some sense this is also a feature since we want to control what is exposed.

    • ALB and Cognito have limits which limit the scalability of this approach (e.g. ALB has a limit of 100 listener rules which limits how many interfaces can be exposed using one ALB).

    • There are some UX issues in the protected user interfaces

      • e.g. implementing proper SSO and global logout is challenging and not done

      • Single-page applications using CORS might not fully work (or require e.g. refreshing the page in browser or other workarounds).