Multi-tenancy support

[Alan DeKok]

On Jun 20, 2022, at 10:45 AM, Cecil Wei <cecilwei at gmail.com> wrote:
> Thanks again for your reply. May I start by answering the questions that
> you mentioned?

  That's good.

> The requirement is to identify tenants of RADIUS requests from devices made
> by different vendors (Cisco,

  OK.  The vendor information is in the MAC address, but it's fine to ignore that.

> 1. Can the same MAC appear in different tenants?
> 
> Yes, we don't plan to add restrictions on this.

  OK.

> 2. Are there multiple tenants behind one RADIUS proxy?
> 
> There will be no radius proxy in front of freeradius server.

  You previously said:

>> I don't seem to find a way to identify tenants if the incoming traffic is
>> from the same proxy server.

  So which is it?

> 3. Is there anything in the Access-Request packets which lets you
> distinguish one tenant from each other?  (i.e. run the server in debug
> mode, or use wireshark)
> 
> We want our service to be vendor agnostic. So it’s preferable to identify
> tenant without specific attributes in Access-Request

  That's not really a good approach.

a) have a unique client (or set of clients) for each tenant, and then key off the "client" section to get a tenant ID

b) look in the RADIUS packets to see how you can tell tenants apart (NAS-Identifier with host name, etc.)

  Those are your choices.  Pick (a), (b), or some combination of (a) and (b).

> 4. An individual shared secret for each tenant for security concerns.

  The clients.conf file takes care of that.


  The problem here is that you're trying to make RADIUS fit your requirements.  This is impossible.  The RADIUS equipment from Cisco, etc. has a certain behavior.  No amount of wishful thinking will make it do anything else.

  i.e. you don't have a set of requirements that you invented.  Throw those away, and stop thinking about them.

  Instead, you have a set of *restrictions*.  What the RADIUS clients can do, what's in the packets, etc.  You have to come up with a solution which fits within those restrictions.

  On top of that, your requirements are changing and contradictory.  Which is not just confusing, those changes make it impossible to give you any reasonable advice.

  If there's no proxies, then just put a tenant field into each "client" definition, as Nathan suggested.  It's that easy.

  If there are proxies, then you MUST look at the packets.  You CANNOT say "Oh, I want to ignore the packet contents".  It's wrong, and it won't work.

  Alan DeKok.