Showing posts with label apigateway. Show all posts
Showing posts with label apigateway. Show all posts

Monday, April 15, 2024

Barcode Printing Solution


In the labs, there will be different types of barcode label printers. When designing a solution for barcode systems, it is important to streamline the processes, protocols, and network connectivity to optimize operations and maintenance costs effectively.


1. Network Connectivity 
Transition USB Printers to Ethernet connections (TCP )
Printers that require USB connections and are currently connected to desktops in Zone 3 should gradually transition to Ethernet connections. 
Users can print from different locations with out physically connected printer 
- More secure (firewall protection)
- Queue Management
2. Printer Communications and Protocols
Implement IPP (Internet Printing Protocol) for networked printers, facilitating secure and standardized communication over IP networks. IPP is supported by most modern printers and provides features like encryption and authentication.
Ensure ZPL II-compatible label printers are used  and Print Management Microservice can generate and send ZPL II commands. 

3. Local Network Printing Solutions
To access printers on an  onpremise network
Establish VPN Connection to AWS to the network or via AWS direct Connect
Network Print server – Print server act as intermediary recovering print jobs from print microservice over VPN or Direct Connect and forwarding these jobs to isolated printers

4. Cloud printing Solution
Cloud Printing solution simplifies the architecture, it has direct IP printing/queue management, driver management. 
Reduces the need for on-premise print servers
Authentication, and authorization are integral parts to ensure that only authorized users can execute print jobs, and sensitive documents are handled securely.  Cloud printing provider will provide necessary API keys 

Cloud Printing Solution
With Cloud Printing service, on premise print servers may not be required.  Cloud   printing service typically manages queue management, job distribution and driver management



Options 
If Cloud  Services has to send print jobs directly to Printer behind firewall, then we need to open port 632 to allow incoming IPP traffic to onpremise printers and  VPN connection between cloud service abd Onpremise network 

Printers can be configured to make outbound connection to cloud provider over the network. In such case we just need to configure only the outbound rules


Local Network Printing Solution

API Gateway: Acts as the entry point for job submissions from the eLIMS UI.
Print Microservice: Processes the print jobs and interacts with SNS and SQS for messaging and queue management.
SNS/SQS Queue: Holds print jobs sent by the microservice. It manages the delivery of these jobs to the print servers in a scalable and fault-tolerant manner.
Local and Isolated Print Servers: Push print jobs from the SQS Queue and manage the actual printing process on their respective printers.




UI Printing
If there is no connectivity issues with the printers from the UI, then UI printing can also be used








Sunday, December 31, 2023

Securing Intranet Applications: Bypassing Public API Gateway Limitations

 

In the realm of secure intranet applications, protecting sensitive data while ensuring easy access for authorized users is paramount. Traditional setups often rely on public API gateways, which can expose internal services to unnecessary risks. Here, we explore an innovative approach: using OpenResty as an external load balancer within a DMZ, integrated with a custom authentication system (FAMS). This architecture not only enhances security but also offers greater control over internal traffic management.

Why Move Away from Public API Gateways?

Public API gateways are designed for wide accessibility, which can be a double-edged sword for intranet applications. They expose endpoints to the public internet, increasing the attack surface. Furthermore, their generic nature might not align well with specific internal security protocols.

The OpenResty Advantage in a DMZ

OpenResty, an enhanced version of the Nginx web server, offers a powerful platform for building a more controlled and secure network architecture. Deployed as an external load balancer in a DMZ, it acts as a gatekeeper, ensuring only authorized traffic reaches the internal network. This setup significantly reduces exposure to external threats.

Key Benefits:

  • Custom Traffic Management: Tailor traffic routing and load balancing to fit the unique needs of your intranet environment.
  • Enhanced Security: With OpenResty in the DMZ, exposure to external threats is minimized, as it handles all incoming traffic and requests.
  • Flexibility and Scalability: OpenResty's modular architecture allows for easy scalability and adaptability to changing security requirements.

Integrating FAMS for Authentication

FAMS, our custom authentication system, plays a critical role in this architecture. By integrating FAMS with OpenResty, we establish a robust authentication process for all incoming requests.

How it Works:

  • Authentication at the Entry Point: OpenResty intercepts all incoming requests. It then leverages FAMS to authenticate and authorize these requests before allowing access to internal services.
  • Seamless User Experience: Users interact with the intranet applications as usual, but with an added layer of security. The authentication process is transparent and efficient.

Overcoming Public API Gateway Limitations

This OpenResty and FAMS-based solution effectively addresses the limitations of public API gateways in several ways:

  • Reduced Public Exposure: By situating the load balancing and authentication mechanisms in a DMZ, the internal network remains isolated from direct public access.
  • Tailored Security: Unlike a one-size-fits-all public API gateway, this setup allows for customized security measures that align precisely with internal policies.
  • Control Over Traffic: Direct control over routing and load balancing ensures that only legitimate, authenticated requests are processed.

Conclusion

For organizations seeking to bolster the security of their intranet applications, transitioning from a public API gateway to an OpenResty and FAMS-based architecture offers a compelling solution. This approach not only enhances security but also provides greater control and flexibility, ensuring that internal applications remain both accessible and protected.

Claim Based Authorization

  1.      Claim Based Authorization ·         Token Validation: As requests come into the Ocelot API Gateway, the first step is to validat...