...
The prerequisites for this deployment are:
- radsecproxy version 1.4.2 6 or higher
- A server certificate and a private key for that certificate to establish the RadSec RADIUS/TLS connection which designates the server as an IdP+SP.
Include Page |
---|
...
|
...
|
Sample config file
Most of the radsecproxy configuration file is static. Therefore, a template configuration file is provided at http://www. eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip. A detailed explanation of this configuration file follows. However, the comments included in the file should make its action almost self- explanatory. This means you can start and experiment with it right after installation.
Base configuration / logging / F-Ticks
This walk-through goes through the template radsecproxy.conf line by line and explains the meaning of each stanza.
Code Block |
---|
ListenUDP *:1812
ListenTCP *:2083
|
radsecproxy will receive requests from all connected Service Providers via both RADIUS and RadSec. Therefore it has to listen on the appropriate ports on its network interfaces (the * meaning: all interfaces). If you want radsecproxy to listen only on specific interfaces, enter the interface names here. Beware: in this case you may also have to set the more exotic options SourceUDP and/or SourceTCP (see the man page of radsecproxy for details).
Include Page |
---|
...
|
...
|
Client definition
Code Block |
---|
client 127.0.0.1 {
type udp
secret testing123
}
client ::1 {
type udp
secret testing123
}
|
There is no other RADIUS server running on localhost, which makes these client definitions almost superfluous. They may be of some use however to initiate debugging requests and tests from the server itself, so it is considered good practice to list localhost as a client. If your system is not IPv6-enabled, simply delete the second stanza.
Code Block |
---|
client __SP_IP_ADDR__ { type udp secret __SP_SECRET__ FTicksVISCOUNTRY XZ # will generate F-Ticks for a non-existant visited country } |
Stanzas like this one are used for each connected service provider that is connected via RADIUS. You need to know the IP address of every SP's RADIUS server and negotiate a shared secret with the SP
Please note that the client and server stanza for the GEANT Monitoring (SA3-T2 activity) have the same host address, but different stanza names. This is important: it disables the LoopDetection for this host, and the SA3 monitoring deliberate uses loops to do its tests. The following stanza is the eduroam Service Activity's monitoring client. Negotiate the IP address and shared secret for European monitoring with the operators in SA3-T2 (eduroam Operational Team) and enter it here.
Code Block |
---|
client SA3-monitoring-incoming { host x.y.z.a type UDP secret __MONITORING_SECRET__ } |
.
Code Block |
---|
client incoming { host * 0.0.0.0/0 host [::]/0 type TLS tls defaultClient secret radsec } |
All incoming RadSec connections can be handled with this stanzaAfter all specific clients in the configuration, you can the above stanza as a "catch-all" for incoming RADIUS/TLS connections.It does not need to be modified (if you do not support IPv6, you can delete the second "host" line though). In particular, the string "radsec" for secret is fixed by the RADIUS/TLS protocol and is required to remain unchanged. It also has no effect; RADIUS/TLS depends on TLS security rather than the shared RADIUS secret.
...
- A X.509 certificate from an eduroam-accredited CA
- which carries a Policy OID as configured above to prove authorisation as a eduroam Service Provider
Please note that the client and server stanza for the GEANT Monitoring (SA3-T2 activity) have the same host address, but different stanza names. This is important: it disables the LoopDetection for this host, and the SA3 monitoring deliberate uses loops to do its tests. The following stanza is the eduroam Service Activity's monitoring client. Negotiate the IP address and shared secret for European monitoring with the operators in SA3-T2 (eduroam Operational Team) and enter it here.
...
These checks were defined via "tls defaultClient", above.
Request forwarding
To deliver requests to your connected IdPs, their servers need to be configured. This stanza is for IdP servers using RADIUS.
Code Block |
---|
server __DESCRIPTIVE_NAME_ {
host __IP_ADDR__
type UDP
secret __SERVER_SECRET__
}
|
This is the equivalent stanza for IdP servers using RADIUS/TLS.
Code Block |
---|
server __RADSEC_PEER_DNS_NAME_ { type TLS tls defaultServer secret radsec statusserver on } |
The two following stanzas define the uplink to the European eduroam Confederation root servers. This entry can be kept as it stands and doesn't need any further configuration.
Code Block |
---|
server etlr1.eduroam.org { type TLS tls defaultServer secret radsec statusserver on } server etlr2.eduroam.org { type TLS tls defaultServer secret radsec statusserver on } |
European monitoring works both ways. The client entry near the beginning of the configuration file was needed for incoming requests from the monitoring servers. The entry below specifies the outgoing connections to the monitoring server. Outgoing connections are currently monitored with RADIUS only. Use the negotiated IP address and shared secret with SA3-T2 Monitoring in the following stanza:
Code Block |
---|
server SA3-monitoring-outgoing {
host a.b.c.d
type UDP
secret __MONITORING_SECRET__
}
|
...
First, there are (very few) known-bad realms which are not forwarded at all. They should ideally never reach the FLR server, and be caught by the SP local RADIUS server, but as an extra safety measure they are filtered (i.e. immediately rejected) here:
Code Block |
---|
realm /myabc\.com$/ { replymessage "Misconfigured client: default realm of Intel PRO/Wireless supplicant! Rejected by <TLD>." accountingresponse on } realm /@.*3gppnetwork\.org$/ { replymessage "Misconfigured client: Unsupported 3G EAP-SIM client!" accountingresponse on } realm /^$/ { replymessage "Misconfigured client: empty realm! Rejected by <TLD>." accountingresponse on } |
...
Requests for proper realms that are coming in from upstream and are supposed to be handled by an identity provider are listed in stanzas like the below. _IDP_REALM_ contains the realm of the connected IdP. Create one such stanza for each IdP realm. If an IdP has multiple servers for a failover configuration, you can list all servers in a row, as in the example below.
Code Block |
---|
realm /IDP_REALM$/ { server __FROM_SERVER_STANZAS_ABOVE__ server __BACKUP_NAME__ } |
The configuration stanza below is for outgoing European monitoring connections.
Code Block |
---|
realm /eduroam\.YOUR_TLD/ { server SA3-monitoring-outgoing } |
All the valid realms were listed earlier in the configuration file, and this server is authoritative for the own TLD. If a supplicant or downstream servers sends a realm with the own TLD, but also with a realm name that is not registered, this request is unauthorised and bound to fail. It will be rejected immediately to prevent routing loops.
Code Block |
---|
realm /\.YOUR_TLD$/ { replymessage "Misconfigured supplicant or downstream server: uses known-bad realm in <TLD> federation!" } |
Finally, all realms that do not belong to the own federation are forwarded to the European eduroam Confederation root servers. However, we limit this to 'sane' realms: these must include a tld of at least 2 characters. Anything else is dropped.
Code Block |
---|
realm * /@.+\..{2,}$/ { server etlr1.eduroam.org server etlr2.eduroam.org } realm * { replymessage "Misconfigured client: username does not contain a valid realm!" } |
Goodies
This section contains some optional configuration parameters that can do good in many cases.
...
radsecproxy allows to split the configuration file into several files on disk and include the parts into the main configuration file. This is very practical when many sites have to be managed. You can create a subdir and put the client, server, realm parts together in one file per participant. By adding
Code Block |
---|
include /etc/radsecproxy.conf.d/*.conf
|
...