Issue with IP Blocking and Allowing in global configuration

[CavidH]

I configured IP blocking and allowing in Ocelot using SecurityOptions, but it's not working.

{
  "GlobalConfiguration": {
    "BaseUrl": "http://localhost:5000",
    "SecurityOptions": {
      "IPBlockedList": ["192.168.0.23"]
    }
  }
}

The IP blocking configuration is not working as expected.

[raman-m]

Hello, Cavid!
It seems we lack support for global settings.
The potential solutions could be:

1. Solely using ocelot.json. Define the options for each route individually.
2. Utilizing C# coding. Replace the ISecurityOptionsCreator service in the DI container by redeveloping the SecurityOptionsCreator class to consider only the global settings.
   

   Ocelot/src/Ocelot/DependencyInjection/OcelotBuilder.cs

   Line 141 in 6088515

   Services.TryAddSingleton<ISecurityOptionsCreator, SecurityOptionsCreator>();

Which solution would be more convenient for you?

[raman-m]

Hello @Fabman08,
The absence of global settings support is a significant issue. Here's the current usage of SecurityOptionsCreator:

Ocelot/src/Ocelot/Configuration/Creator/RoutesCreator.cs

Line 111 in 6088515

var securityOptions = _securityOptionsCreator.Create(fileRoute.SecurityOptions);

Consequently, the method should accept two arguments, including global settings:

Ocelot/src/Ocelot/Configuration/Creator/SecurityOptionsCreator.cs

Line 8 in 6088515

public SecurityOptions Create(FileSecurityOptions securityOptions)

Would you be able to allocate some time to address this?

[Fabman08]

Hi @raman-m!
Sure, I'll be able to fix the issue this or next week. ☺️

@CavidH thank you for reporting this issue! 👍

[CavidH]

Thank you very much for your help. We will eagerly await the new version.

[CavidH]

Hello, Cavid! It seems we lack support for global settings. The potential solutions could be:

1. Solely using ocelot.json. Define the options for each route individually.
2. Utilizing C# coding. Replace the ISecurityOptionsCreator service in the DI container by redeveloping the SecurityOptionsCreator class to consider only the global settings.
   

   Ocelot/src/Ocelot/DependencyInjection/OcelotBuilder.cs

   Line 141 in 6088515

   Services.TryAddSingleton<ISecurityOptionsCreator, SecurityOptionsCreator>();

Which solution would be more convenient for you?

I had thought of the first option, but since I have too many services, it will be difficult to control this

[Fabman08]

@raman-m just a little question about Global Settings behaviours.

I've found three ways to fix the issue:

1. Every properties in Route FileSecurityOptions overrides their Global Settings values
   eg.

• Global:
  Allowed: B,C
  Blocked: E
  ExcludeAllowedFromBlocked: true
• Route:
  Allowed: A,B,C
  Blocked: D,E,F
  ExcludeAllowedFromBlocked: false
• Final:
  Allowed: A,B,C
  Blocked: D,E,F
  ExcludeAllowedFromBlocked: false

2. Only the existing properties in Route FileSecurityOptions overrides their Global Settings values
   eg.

• Global:
  Allowed: B,C
  Blocked: E
  ExcludeAllowedFromBlocked: true
• Route:
  Allowed: A,B,C
  Blocked: null
  ExcludeAllowedFromBlocked: null
• Final:
  Allowed: A,B,C
  Blocked: E
  ExcludeAllowedFromBlocked: true

3. The Route FileSecurityOptions values will be merged to Global Settings values
   eg.

• Global:
  Allowed: A,B,C
  Blocked: D,E
  ExcludeAllowedFromBlocked: true
• Route:
  Allowed: F,G,H
  Blocked: I,K
  ExcludeAllowedFromBlocked: false
• Final:
  Allowed: A,B,C,F,G,H
  Blocked: D,E,I,K
  ExcludeAllowedFromBlocked: false

Which one is the best?

[raman-m]

@Fabman08 Your research is too complicated!

Which one is the best?

It is best to prioritize the route-specific FileSecurityOptions object over the global settings. Therefore, if route settings are defined, all global settings should be disregarded. In practice, if the route object is null, then the global settings should be utilized.

Every properties in Route FileSecurityOptions overrides their Global Settings values

Yes, if route options are defined, all global ones should be ignored. We will highlight this in the documentation. There should be no merging whatsoever. This approach is the simplest and most correct solution, as merging properties would be erroneous due to potential conflicts within the algorithm. Therefore, merging is identified as a source of bugs.