UX Switching

Proposal for addressing Screen level switching between Govstack applications/building blocks

Ramkumar 23/6/2023

Govstack architecture enables an application to call services of another application within Govstack and get responses containing information from the called application. If the calling and called applications are co-located, then one may organize secure calls directly between such applications. However, if are not co-located then such service calls and associated data exchange between called and calling parties goes through a secure mechanism for information exchange over internet. In such cases, there are two possible scenarios:

1. The calling application backend requests the service through an API of the called application. In Govstack, this scenario is addressed by using information mediator, where in the request and results pass through security servers (in IM) attached to applications on either side.

2. The call requires that the user is switched from UI screen of the calling application to the UI screen of the called application for consuming the service and when the service is done it has to return back to the calling application UI to continue further. This may be needed because of multiple reasons:

   1. The called service may collect inputs from the user through its own UI as it is not preferred to exposed collected data collection to the calling application for security reasons.

   2. It may be unreasonable to expect that the calling application designs screens of other BBs it calls, considering diverse requirements, standards, policies, etc., in respective domains.

   3. Building blocks may be developed by different entities and evolve independently. Hence tight integration is not preferred, loosely coupled but secure interoperability is needed.

In such cases, it is preferrable to have an architecture that allows switching from UI of calling application to the ui of called application securely and return back to the ui of calling application after the job over. A few mechanisms to address this requirement are discussed below:

As an example, considering a registration process wherein the registration application may call a payments building block application. In such cases the payment building block ui may interact with the user to collect details such as banking info of the registered candidate or to collect payment of registration charges from the candidate and once that task is completed it may switch back to the UI of the registration application. This may also happen in case registration process calls an ID building block (application) to verify credentials of a person before registering into a program.

In the context of such use cases, for switching UIs between the registration and the called building block UI, following mechanisms are discussed:

1. OpenID connect based Single Sign on (SSO) mechanism

2. IFRAME bases Secure Proxy mechanism (not recommended)

3. Token based decentralized authentication mechanism

1. OpenID Connect based Single Sign-On (SSO): SSO allows users to authenticate once and access multiple applications without the need for repeated login prompts. Popular SSO protocols include OAuth authorization and OpenID connect. OAuth framework allows users to grant access to their resources without sharing their credentials with the requesting application. It enables a user to authenticate with one application (called the "identity provider" or "authorization server") and obtain an access token. This access token can then be used to access protected resources in other applications (called "resource servers") without requiring the user to authenticate again. OpenID Connect facilitates SSO by allowing users to authenticate once with the identity provider and then access multiple applications without repeated login prompts. This improves user experience and reduces the need for managing multiple sets of credentials. The OpenID Connect builds upon OAuth 2.0 to provide user authentication as well as authorization. It allows for identity information to be exchanged between the identity provider and relying applications. When a user authenticates with the identity provider, the relying application (service provider) receives an ID token containing information about the user. This ID token can be used to authenticate the user in the relying application by cross verification with the identity server.

SSO based on OpenID connect has some inherent advantages such as:

Enhanced User Authentication: OpenID Connect provides a standardized and robust mechanism for user authentication. It allows for the exchange of identity information between the identity provider and relying applications, enabling stronger authentication and verification of user identities.

Standardized Protocol: OpenID Connect is widely adopted and standardized, making it easier to implement and integrate with various applications and platforms. It provides clear guidelines and specifications, reducing the complexity of authentication implementation.

User Profile and Attributes: OpenID Connect allows for the retrieval of user profile information and additional attributes from the identity provider. This can provide valuable user data to relying applications for personalization, authorization, and user-specific functionality.

There are some inherent disadvantages of OpenID Connect as well:

Increased Complexity: Implementing OpenID Connect can be more complex compared to token-based authentication or secure proxy methods. It requires understanding the underlying OAuth 2.0 framework and configuring the identity provider and relying applications accordingly.

External Dependency: OpenID Connect relies on an external identity provider for user authentication. This introduces a dependency on the availability and reliability of the identity provider. If the identity provider experiences issues, it can affect the authentication process for the relying applications.

Single point of failure: Centralized Identity server may lead to single point of failure, but leads to consistency and focus on managing security concerns at one place in the architecture.

2. IFRAME based Secure Proxy Authentication: In this case the calling application UI has an embedded screen component (iframe) that internally points to the called application’s webserver URL. Information within the iframe can be isolated from the main application or may exchange select information through triggered “events” exposed between them. An iframe (inline frame) is a HTML element that allows one to embed one HTML document within another. In the context of authentication and secure redirection between UIs of different web applications, iframes are typically used as a part of the secure proxy mechanism. Specifically, iframes can be used within the secure proxy to load and display content from a different web application or domain while maintaining the security boundaries between the two applications. The iframe can serve as a container for displaying the UI of the target application within the UI of the calling application. The use of iframes in this context is often employed to achieve seamless integration and user experience between different web applications, allowing for the rendering of UI components from multiple sources within a single interface.

Open

Assuming the user has already logged into the parent (calling) application, then some action in the main application screen may invoke the iframe, and the following steps transfer control to the screen of application called in the iframe: The secure proxy mechanism provides several advantages:

Centralized Security: By intercepting and controlling client requests, one can enforce security policies consistently across multiple applications and services. The calling application owns the responsibility to use the secure proxy as a central point for authentication and authorization, while the called applications need not handle these concerns and rely on the calling application as source of truth.

Simplified Logic: With a secure proxy handling authentication and authorization in the parent application, called applications can focus on their core functionalities rather than implementing these security mechanisms independently. This simplifies application development and maintenance.

However, it's important to note that the secure proxy mechanism introduces an additional component to the architecture, which requires proper configuration, maintenance, and monitoring. It also adds an extra network hop and potential performance overhead, so it's crucial to ensure that the proxy infrastructure is appropriately scaled and optimized to handle the expected traffic. The specific implementation of the secure proxy mechanism can vary based on the chosen proxy software or infrastructure components.

3. Token-based, decentralized Authentication: This method involves generating and exchanging tokens between the applications. When a user authenticates with one application a token is issued, the user starts transaction in that application. When the user clicks a relevant button on the screen of that application, it calls a UI of another application at a predefined URL endpoint and passes the token along with any other information it should. The same token is also passed to a secure backend API of the called application through the information mediator by the calling application backend. The called application compares matches the tokens from front end call to that received at backend and validated before publishing its transactional UI to the user. JSON Web Tokens (JWT) is a commonly used token format. This mechanism has some advantages:

Simplicity and Flexibility: Token-based authentication, such as JWT, is generally simpler to implement and understand compared to OIDC. It provides flexibility in how tokens are generated, validated, and managed, allowing for customization based on specific requirements.

Decoupled Architecture: Token-based authentication enables a decoupled architecture where the authentication process is separate from the identity provider. This provides more control and autonomy over the authentication mechanism without dependency on an external identity provider. There is freedom to manage user authentication within your application without relying on a third-party service. It is the responsibility of the calling application to have authenticated the user and the calling application can pass any unique token of its own choice to the called application, and irrespective of token content it only matters that token is unique and tallies between front end and backend channels.

Scalability: Token-based authentication can be more scalable since it does not require constant communication with an identity provider for authentication. The server can verify the token locally, reducing external dependencies and potential bottlenecks.

Dynamic provisioning: Since what is contained in a token is decided by the calling application, it is possible to generate unique tokens for each service call (instead of session wide tokens) enabling higher level of security.

There are some inherent disadvantages of Token-Based Authentication as well:

Lack of Standardization: Although JSON Web Tokens (JWT) signed by JSON Web keys (JWK) are standard formats for encapsulating unique authentication information, the actual payload of a token is not a standardized specification for authentication. This can result in varied implementations and interoperability challenges when integrating with different systems and applications.

Additional Development Effort: Implementing token-based authentication may require more development effort to handle aspects such as token generation, validation, and session management. Customization and maintenance of these components can be time-consuming.

Open

Note: It is possible to combine the first and third approaches - validating both the application and the user.

The first approach validates the user (OIDC) - but using IM, we can also validate the application.

4. Hybrid Model:

This is a combination of openID connect and Token based connect models and hence advantages of both user and application authentication. Obviously it has more infra requirements but much more robust model. The Backends token passing to called BB through IM ensures a valid registered application is sending the request. In addition, the called BB authenticates a valid user with the identity server.