Alternate proxying methods.

[Arran Cudbard-Bell]

Due to the complicated filtering required for JRS, the standard way of 
doing proxying with the realms
module is not sufficient.

Most institutions will just use rlm_realm to strip the user name and 
realm out, and proxy the user to the default realm,
Then explicitly define a realm for themselves to catch local users.

This is fine, as locally terminated realms don't get sent through the 
pre-proxy and post-proxy sections, and so the stringent attribute
filters required for JRS don't affect locally proxied data.

The issue comes when you have a set of RADIUS servers in front of your 
home_servers.
Because you have to use DEFAULT in the attribute filter to match users 
going off to JRS (as you have no idea what their realm will be),
the data flowing through the front end servers will also have the 
DEFAULT filters applied, which is not good !

The obvious solution is to actually direct users at a realm, instead of 
relying on DEFAULT entries... But as soon as a user hits the rlm_realm
they will be proxied...

The solution I found is to ignore the standard front end for rlm_realm, 
and instead use the Proxy-To-Realm and Replicate-To-Realm in the users file.

1. User hits hints file.

# Writes stripped user name to use in authorization
DEFAULT User-Name =~ "^([[:alnum:]^@]+)@([[:alnum:].]*)$"
        Stripped-User-Name = "%{1}",
        Pre-Proxy-Realm = "%{2}"

You split the user name into two sections using a generic regular 
expression, user name goes into Stripped-User-Name, second part goes 
into a custom Attribute Pre-Proxy-Realm.

2. User hits users file.

############################################################################
# Reject annoying users who use the wrong realm, so we don't have to 
bother JRS with them.
# Shorthand sussex
DEFAULT Pre-Proxy-Realm =~ ".*susx.ac.uk.*", Auth-Type := Reject
        Reply-Message = "Please use %{Stripped-User-Name}@sussex.ac.uk 
as your user ID",
        Fall-Through = no
# Freeman centre users
DEFAULT Pre-Proxy-Realm =~ ".*freeman-centre.ac.uk.*", Auth-Type := Reject
        Reply-Message = "Please use %{Stripped-User-Name}@sussex.ac.uk 
as your user ID",
        Fall-Through = no
# Subdomains of sussex
DEFAULT Pre-Proxy-Realm =~ "(.+)sussex.ac.uk.*", Auth-type := Reject
        Reply-Message = "Please use %{Stripped-User-Name}@sussex.ac.uk 
as your user ID",
        Fall-Through = no

# Proxy user to JRS.
DEFAULT Pre-Proxy-Realm != "sussex.ac.uk", Pre-Proxy-Realm !="", 
Proxy-To-Realm := "jrs"
        Fall-Through = no
# Or to backend servers.
DEFAULT Proxy-To-Realm := "sussex"
        Fall-Through = no


You can then black hole users using incorrect domains.

And proxy users who don't belong to your local domain, directly to the 
jrs realm.

You can then define specific attribute filters for JRS users :)

3. Acct_users

############################################################################
# Replicate none sussex users accounting packets to jrs realm
# (allows us to use attr_filter properly!)
DEFAULT Pre-Proxy-Realm != "sussex.ac.uk", Pre-Proxy-Realm !="", 
Replicate-To-Realm := jrs
    Fall-Through = yes
DEFAULT Proxy-To-Realm := "sussex"

Just thought it was quite a neat way or doing it, as opposed to all the 
weirdness with prefixes and suffixes and using rlm_realm in the 
authorize and accounting section.
Also rely's on *standardish* behaviour.

Also heard talk to deprecating Proxy-To-Realm and Replicate-To-Realm... 
which is a really bad idea as using Proxy-To-Realm and 
Replicate-To-Realm is far more powerful , and can be configured from sql :)

---
Arran