Back to: Design Patterns in C# With Real-Time Examples

Real-Time Examples of Firewall Proxy Design Pattern in C#

In this article, I will discuss Real-Time Examples of Firewall Proxy Design Patterns in C#. Please read our previous article, discussing Real-Time Examples of the Synchronization Proxy Design Pattern in C#. At the end of this article, you will understand the following pointers.

1. What is the Firewall Proxy Design Pattern in C#?
2. Multiple Real-Time Examples of the Firewall Proxy Design Pattern in C#
3. Advantages and Disadvantages of Firewall Proxy Design Pattern in C#
4. When to use Firewall Proxy Design Pattern in C#?

Firewall Proxy Design Pattern in C#

The Firewall Proxy Design Pattern provides an intermediary controlling resource access. This can be useful for various purposes, including access control, logging, or altering requests and responses. In software design, this can be analogous to a network firewall, which acts as a barrier between a trusted internal network and untrusted external networks. Let’s see a basic example of the Firewall Proxy Design Pattern in C#:

using System;
using System.Collections.Generic;

namespace FirewallProxyDesignPattern
{
    // Step 1: Define the Subject interface
    public interface ISubject
    {
        void Request();
    }

    // Step 2: RealSubject class
    public class RealSubject : ISubject
    {
        public void Request()
        {
            Console.WriteLine("RealSubject: Handling Request.");
        }
    }

    // Step 3: Proxy class
    public class FirewallProxy : ISubject
    {
        private RealSubject _realSubject;
        private List<string> _bannedSites;

        public FirewallProxy()
        {
            _bannedSites = new List<string> { "badsite.com", "malicious.com" };
        }

        public void Request()
        {
            if (IsRequestValid())
            {
                if (_realSubject == null)
                    _realSubject = new RealSubject();

                _realSubject.Request();
            }
            else
            {
                Console.WriteLine("FirewallProxy: Access Denied!");
            }
        }

        private bool IsRequestValid()
        {
            // Just for the sake of this example, let's imagine we are checking a website domain.
            string siteBeingAccessed = "badsite.com"; // Hardcoded for the sake of example. This can be dynamic.

            return !_bannedSites.Contains(siteBeingAccessed);
        }
    }
    
    //Client Code
    //Testing Firewall Proxy Design Pattern
    public class Program
    {
        public static void Main()
        {
            ISubject proxy = new FirewallProxy();
            proxy.Request(); // This will print "FirewallProxy: Access Denied!"
            Console.ReadKey();
        }
    }
}

In this example:

• ISubject is an interface representing both the RealSubject and Proxy.
• RealSubject is the real object that the proxy represents.
• FirewallProxy is our proxy, and in this example, it acts as a firewall by denying access if the request is for a banned site.
• In the client code, we only interact with the ISubject, not knowing if it’s the real object or its proxy.

This is a basic example to demonstrate the idea. In a real-world scenario, you would deal with more complex logic in the proxy and potentially other patterns like Lazy Initialization for creating the RealSubject.

Real-Time Example of Firewall Proxy Design Pattern in C#

One real-time example of the Firewall Proxy Design Pattern is controlling access to multimedia content based on the user’s subscription level or geographical region.

Imagine a streaming platform where users can stream music and videos. This platform offers different subscription levels: Free, Premium, and VIP. Each level grants access to different types of content. Also, some content might be geographically restricted. Let’s see how the Firewall Proxy Design Pattern can be implemented in such a scenario:

using System;
using System.Collections.Generic;

namespace FirewallProxyDesignPattern
{
    public interface IMediaService
    {
        void Play(string contentId);
    }

    public class MediaService : IMediaService
    {
        public void Play(string contentId)
        {
            // Logic to stream the actual content
            Console.WriteLine($"Streaming content with ID: {contentId}");
        }
    }

    public class MediaServiceProxy : IMediaService
    {
        private MediaService _mediaService;
        private string _subscriptionType;
        private string _userCountry;

        // Sample data for content restrictions
        private List<string> _premiumContent = new List<string> { "content2", "content3" };
        private List<string> _geoRestrictedContent = new List<string> { "content3" };

        public MediaServiceProxy(string subscriptionType, string userCountry)
        {
            _subscriptionType = subscriptionType;
            _userCountry = userCountry;
        }

        public void Play(string contentId)
        {
            if (CanAccessContent(contentId))
            {
                if (_mediaService == null)
                {
                    _mediaService = new MediaService();
                }
                _mediaService.Play(contentId);
            }
            else
            {
                Console.WriteLine("Access denied to the requested content.");
            }
        }

        private bool CanAccessContent(string contentId)
        {
            if (_subscriptionType == "Free" && _premiumContent.Contains(contentId))
            {
                return false;
            }

            if (_geoRestrictedContent.Contains(contentId) && _userCountry != "US")
            {
                return false;
            }

            return true;
        }
    }
    
    //Client Code
    //Testing Firewall Proxy Design Pattern
    public class Program
    {
        public static void Main()
        {
            IMediaService user1 = new MediaServiceProxy("Free", "US");
            user1.Play("content1"); // This will stream the content
            user1.Play("content2"); // This will print "Access denied to the requested content."

            IMediaService user2 = new MediaServiceProxy("Premium", "UK");
            user2.Play("content3"); // This will print "Access denied to the requested content."
            Console.ReadKey();
        }
    }
}

In this example:

• The MediaService is the actual service that streams the content.
• The MediaServiceProxy acts as the firewall proxy, checking if the user has the right subscription type and if they’re accessing content from a permitted region.

In this case, the client could be a user’s application, which interacts with the IMediaService without knowing if it’s dealing directly with the MediaService or its proxy.

Real-Time Example of Firewall Proxy Design Pattern in C#

Let’s see another real-time example where we might use the Firewall Proxy Design Pattern: a basic document access system. In this example, consider a company that uses a document storage system. Documents can have different levels of sensitivity: Public, Confidential, and top secret. Employees also have access levels, and the system should ensure they can only access documents appropriate for their clearance level. Let’s implement this:

using System;
namespace FirewallProxyDesignPattern
{
    // Define the Subject interface
    public interface IDocument
    {
        string ReadContent();
    }

    // RealSubject class
    public class Document : IDocument
    {
        private string _content;
        private string _sensitivity;

        public Document(string content, string sensitivity)
        {
            _content = content;
            _sensitivity = sensitivity;
        }

        public string Sensitivity => _sensitivity;

        public string ReadContent()
        {
            return _content;
        }
    }

    // Proxy class
    public class DocumentProxy : IDocument
    {
        private Document _document;
        private string _employeeAccessLevel;

        public DocumentProxy(string content, string sensitivity, string employeeAccessLevel)
        {
            _document = new Document(content, sensitivity);
            _employeeAccessLevel = employeeAccessLevel;
        }

        public string ReadContent()
        {
            if (CanAccessDocument())
            {
                return _document.ReadContent();
            }
            else
            {
                return "Access Denied!";
            }
        }

        private bool CanAccessDocument()
        {
            switch (_document.Sensitivity)
            {
                case "Public":
                    return true;

                case "Confidential":
                    return (_employeeAccessLevel == "Manager" || _employeeAccessLevel == "Executive");

                case "Top-Secret":
                    return (_employeeAccessLevel == "Executive");

                default:
                    return false;
            }
        }
    }

    //Client Code
    //Testing Firewall Proxy Design Pattern
    public class Program
    {
        public static void Main()
        {
            IDocument publicDocument = new DocumentProxy("This is a public document.", "Public", "Employee");
            Console.WriteLine(publicDocument.ReadContent()); // This will print the content

            IDocument confidentialDocument = new DocumentProxy("This is a confidential document.", "Confidential", "Employee");
            Console.WriteLine(confidentialDocument.ReadContent()); // This will print "Access Denied!"

            IDocument topSecretDocument = new DocumentProxy("This is a top-secret document.", "Top-Secret", "Executive");
            Console.WriteLine(topSecretDocument.ReadContent()); // This will print the content
            Console.ReadKey();
        }
    }
}

In this example:

• IDocument is an interface representing both the Document (RealSubject) and its DocumentProxy.
• The Document class holds the content and sensitivity level.
• The DocumentProxy checks the employee’s access level against the document’s sensitivity before allowing the ReadContent operation.
• The client code only interacts with the IDocument, unaware if it’s directly accessing the Document or going through the proxy.

This is a simplified representation. Additional features, such as logging access or caching documents, might be incorporated in a real-world scenario.

Advantages and Disadvantages of Firewall Proxy Design Pattern in C#

The Firewall Proxy Design Pattern provides an intermediary to control access to an object or resource. Like all design patterns, the Firewall Proxy has its own advantages and disadvantages.

Advantages of Firewall Proxy Design Pattern in C#:

• Separation of Concerns: The system design becomes more modular by separating the access control mechanism from the actual object. The real object doesn’t need to concern itself with access control.
• Security: A firewall proxy can add an additional layer of security, ensuring that unauthorized or malicious requests are not passed through to the actual resource.
• Extensibility: In the future, if there’s a need to change the access control mechanism or add more features like logging or caching, it’s easier to modify the proxy without touching the real object.
• Lazy Initialization: With a proxy in place, you can delay the creation of the real object until it is needed. This can be particularly useful when the instantiation of the real object is resource-intensive.
• Centralized Control: All access to the resource passes through the proxy, allowing centralized control and management. This can simplify monitoring, logging, and even throttling requests if necessary.

Disadvantages of Firewall Proxy Design Pattern in C#:

• Added Complexity: Introducing a proxy means an additional layer must be managed, which can increase the system’s complexity.
• Performance Overhead: Every request to the real object has to go through the proxy, which can introduce a slight delay, especially if the access control mechanism is resource-intensive.
• Maintenance: If not carefully managed, proxies can become a maintenance burden. If both the proxy and the real subject implement the same interface, any change to that interface must be reflected in both places.
• Potential for Bugs: As with any additional layer or component, there’s potential for bugs or misconfigurations in the proxy, which could result in incorrect access control decisions.
• Tight Coupling: There might be a tight coupling between the proxy and the real subject, which can make changes harder in the future.

While the Firewall Proxy Design Pattern offers many advantages, especially concerning security and access control, it’s essential to consider the trade-offs. When using this pattern, ensure that the benefits outweigh the disadvantages for your specific use case.

When to use Firewall Proxy Design Pattern in C#?

The Firewall Proxy Design Pattern controls access to an object, serving as an intermediary between the client and the actual object. It’s beneficial in various scenarios, especially when you need to protect, control, or augment access to a particular resource. Here are some situations when you might want to use the Firewall Proxy Design Pattern in C#:

• Access Control: When you must control which operations a user or system can perform based on certain conditions or rules. For example, you may want to restrict certain functionalities based on user roles or subscription levels.
• Security Concerns: When working with sensitive data or operations, you may want to introduce an additional layer of security to validate requests or prevent certain types of operations.
• Lazy Initialization: If creating an actual object is resource-intensive and you only want to create it when it’s absolutely necessary, a proxy can help defer its creation until it’s needed.
• Auditing and Logging: If you want to keep a record of operations on a specific object, you can introduce a proxy to log every action taken.
• Costly Operations: When operations are expensive in computation or resources (e.g., a request to an external service), you might want to use a proxy to cache results and reduce redundant operations.
• Networking Concerns: If your object communicates over a network, especially in distributed systems or client-server architectures, you can use a proxy to hide the complexity of remote communications, error handling, and reconnections.
• Third-party Integrations: When integrating with third-party libraries or services, you can use a proxy to handle the specifics of that integration while exposing a consistent or simplified interface to the rest of your application.
• Feature Toggle: If you want to dynamically turn features on and off, a proxy can decide whether to route a request to the actual object or return an alternative response based on feature flags.

However, while the Firewall Proxy Design Pattern can be immensely useful, evaluating if its introduction is warranted is essential. Remember:

• Avoid Overengineering: Don’t introduce a proxy if the main reason is a potential future need. Ensure that the current requirements justify its introduction.
• Performance Concerns: Introducing a proxy can add overhead, especially if the operations on the proxy are resource-intensive. Always be aware of the potential performance implications.

In the next article, I will discuss the Real-Time Examples of Smart Reference Proxy Design Patterns in C#. Here, in this article, I try to explain the Real-Time Examples of Firewall Proxy Design Patterns in C#. I hope you enjoy this Firewall Proxy Design Pattern in Real-time Examples using the C# article.