Cleaning up the "realms"

[Alan DeKok]

Geoffroy Arnoud wrote:
> If I understand, you would like to "merge" realm
> detection (made in a module) with server proxy
> configuration/code?

  No.  The confusion arises because right now, realms *are* home
servers.  That's wrong.

  In the new code, home servers are defined independently of realms.
There are server pools for failover && load-balancing , which are again
defined independently of realms.  Realms are then defined to use the
server pools.

  i.e. realm -> server pool -> list of home servers

  What's left in a "realm" section of "proxy.conf" is not much.  The
name, and pointers to the authentication && accounting pools.  The proxy
code currently proxies by realm, and it should really proxy by server pool.

  i.e. ideally, the only knowledge of realms should be in the
configuration of the "realms" module.

  The "Proxy-To-Realm" should go away and/or be replaced with
"Proxy-Using-Server-Pool", or "Proxy-To-Home-Server".  The "realms"
module can map "Proxy-To-Realm" to the appropriate new proxy configuration.

  However... changing all that requires a lot of updates to existing
configurations.  It may be easier just to fix the home server && server
pool issues, and leave the proxying code with some knowledge of realms.

> My opinion is that it is not so interesting because
> having a module setting a specific attribute
> "Proxy-To-Realm" with the wanted value allows to proxy
> request with criteria not only based on the User-Name.

  Yes, that's useful.  But proxying to a *realm* is wrong.  Proxying to
a *server* is correct.

> Of course, is what I describe is still possible with
> what you propose, I don't have any objection.
> Else this would mean that FR 2_0 can do less than 1_1.

  That's never the goal.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog