Rest Module
The rest
module sends HTTP requests to remote servers and decodes
the responses. Can also perform basic auth with user’s credentials.
See RFC 2616 for more details about HTTP.
- tls { … }
-
Configure the tls related items that control how FreeRADIUS connects to a HTTPS server.
Specifies how the certificate(s) presented by the HTTPS server being contacted are validated, and which certificates (if any) to send to the HTTPS server.
- ca_file
-
PEM formatted file containing the chain to validate the HTTPS server’s cert
Should usually contain a concatenation of one or more intermediary CA files, shallowest (i.e. the one that signed the HTTPS server’s cert) first, and deepest (the root CA) last.
Providing a complete certificate chain here is the most common way of validating the certificate presented by a HTTPS server.
- ca_issuer_file
-
PEM formatted file containing the CA that signed the HTTPS server’s cert
Specifies the certificate that directly signed the certificate presented by the HTTPS server.
This configuration option can be used to prevent certificates passing validation that were signed by other intermediary CAs or root CAs in the trusted certificate chain.
- ca_path
-
A directory containing multiple root CA certs named by their hash
See the OpenSSL documentation for more details: - https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set_default_verify_paths.html - https://www.openssl.org/docs/man1.1.1/man1/c_rehash.html
This configuration option should only be used when the HTTPS server being contacted is not known ahead of time (using a URL from an external source), and/or the CA used to sign the HTTPS server certificate is unknown.
- certificate_file
-
PEM formatted file containing the certificate we present to the HTTPS server
Specifies a certificate and any intermediary CAs we should send to the HTTPS server.
This file should usually contain the client certificate file first, then any intermediary signing CAs, shallowest (direct signee of the certificate_file) to deepest (signed directly by the root CA).
- private_key_file
-
PEM formatted file containing the private key for the specified certificate_file
Must be specified if certificate_file is being used.
- private_key_password
-
Password used to decrypt the private key file.
Should only be specified in the private_key_file is encrypted.
- random_file
-
Source of random data used for various cryptographic functions.
- check_cert
-
Server certificate verification requirements.
May be one of:
Option | Description |
---|---|
|
Server certificate can be signed by any CA or be self-signed. |
|
Server certificate must be issued by one of the trusted CAs. |
Default is yes
- check_cert_cn
-
Server certificate CN verification requirements.
May be one of:
Option | Description |
---|---|
|
Server certificate CN can be any value. |
|
Server certificate CN matches the host in the URI. |
Default is yes
- extract_cert_attrs
-
Extract OIDs from presented certificates as OIDs.
Default is no
- connect_uri
-
It will open a connection to the server specified in
connect_uri
to populate the connection cache, ready for the first request.
If you wish to disable this pre-caching and reachability check, comment out the configuration item below.
The server will not start if the server specified is unreachable. |
- connect_proxy
-
Proxy server used for all outbound connections.
- http_negotiation
-
The negotiation scheme and target HTTP version.
May be one of:
Option | Description |
---|---|
|
Use whichever negotiation scheme and version is the default
for |
|
Disable negotiation. Force HTTP |
|
Disable negotiation. Force HTTP |
|
Disable negotiation. Force HTTP |
|
Try and negotiate 2.0 and fallback to |
|
For |
- multiplex
-
Execute multiple requests simultaneously using the same HTTP connection.
HTTP >= 2.0 is required for multiplexing to succeed. If we can’t negotiate a high enough http version, multiplexing will be silently disabled. |
- chunk
-
Max chunk-size.
Sections
The following config items can be used in each of the sections. The sections themselves reflect the sections in the server.
For example, if you list rest
in the authorize
section of a virtual server
,
the settings from the authorize
section here will be used.
The following config items may be listed in any of the sections:
Option | Description |
---|---|
|
To send the request to. |
|
The request via this server, supports |
|
HTTP method to use, one of 'get', 'post', 'put', 'patch', 'delete' or any custom HTTP method. |
|
A custom header in the format '<header>: <value>'. |
|
The format of the HTTP body sent to the remote server. May be 'none', 'post' or 'json', defaults to 'none'. |
|
Send custom freeform data in the HTTP body. |
|
Force the response to be decoded with this decoder. May be 'plain' (creates reply.REST-HTTP-Body), 'post' or 'json'. |
|
TLS settings for HTTPS. |
|
HTTP auth method to use, one of 'none', 'srp', 'basic', 'digest', 'digest-ie', 'gss-negotiate', 'ntlm', 'ntlm-winbind', 'any', 'safe'. defaults to 'none'. |
|
User to authenticate as, will be expanded. |
|
Password to use for authentication, will be expanded. |
|
Require HTTP authentication. |
|
HTTP request timeout in seconds, defaults to 4.0. |
|
Maximum size of incoming HTTP body, defaults to 16k. |
Additional HTTP headers may be specified with control.REST-HTTP-Header
.
The values of those attributes should be in the format:
<attribute>: <value>
control.REST-HTTP-Header
attributes will be consumed after each call
to the rest module, and each %rest(…)
expansion.
POST - All attributes and values are urlencoded.
e.g:
[outer.][<list>.]<attribute0>=<value0>&[outer.][<list>.]<attributeN>=<valueN>
JSON - All attributes and values are escaped according to the JSON specification.
e.g:
{
"<attribute0>":{
"type":"<type0>",
"value":[<value0>,<value1>,<valueN>]
},
"<attribute1>":{
"type":"<type1>",
"value":[...]
},
"<attributeN>":{
"type":"<typeN>",
"value":[...]
},
}
The response format adds three optional fields:
Fields | Description |
---|---|
|
If |
|
If |
|
Controls how the attribute is inserted into the target list.
Defaults to |
{
"[outer.][<list>.]<attribute0>":{
"is_json":<bool>,
"do_xlat":<bool>,
"op":"<operator>",
"value":[<value0>,<value1>,<valueN>]
},
"<attribute1>":"value",
"<attributeN>":{
"value":[<value0>,<value1>,<valueN>],
"op":"+="
}
}
|
- xlat { … }
-
Allows a subset of section configuration items to be configured for any calls to this module’s
xlat
function.
Authorize { … }
Code | Meaning | Process body? | Module code |
---|---|---|---|
404 |
not found |
no |
notfound |
410 |
gone |
no |
notfound |
403 |
forbidden |
no |
disallow |
401 |
unauthorized |
yes |
reject |
204 |
no content |
no |
ok |
2xx |
successful |
yes |
ok/updated |
5xx |
server error |
no |
fail |
xxx |
- |
no |
invalid |
Accounting { … }
Code | Meaning | Process body? | Module code |
---|---|---|---|
204 |
no content |
no |
ok |
2xx |
successful |
yes |
ok/updated |
5xx |
server error |
no |
fail |
xxx |
- |
no |
invalid |
Post-Auth { … }
Same as Accounting { … }
- connection { … }
-
Configure how connection handles are managed per thread.
Reusable connection handles are allocated in blocks. These parameters allow for tuning how that is done.
Since http requests are performed async, the settings here represent outstanding http requests per thread.
- min
-
The minimum number of connection handles to keep allocated.
- max
-
The maximum number of reusable connection handles to allocate.
Any requests to allocate a connection handle beyond
this number will cause a temporary handle to be allocated.
This is less efficient than the block allocation so
max
should be set to reflect the number of outstanding
requests expected at peak load.
- cleanup_interval
-
How often to free un-used connection handles.
Every cleanup_interval
a cleanup routine runs which
will free any blocks of handles which are not in use,
ensuring that at least min
handles are kept.
- connect_timeout
-
Connection timeout (in seconds).
The maximum amount of time to wait for a new connection to be established.
Default Configuration
rest {
tls {
# ca_file = "${certdir}/cacert.pem"
# ca_issuer_file = "${certdir}/caissuer.pem"
# ca_path = "${certdir}"
# certificate_file = /path/to/radius.pem
# private_key_file = /path/to/radius.key
# private_key_password = "supersecret"
# random_file = /dev/urandom
# check_cert = no
# check_cert_cn = no
# extract_cert_attrs = no
}
connect_uri = "http://127.0.0.1:9090/"
# connect_proxy = "socks://127.0.0.1"
# http_negotiation = "default"
# multiplex = yes
# chunk = 0
xlat {
tls = ${..tls}
}
authorize {
uri = "${..connect_uri}/user/%{User-Name}/mac/%{Called-Station-ID}?section=authorize"
method = 'GET'
tls = ${..tls}
}
authenticate {
uri = "${..connect_uri}/user/%{User-Name}/mac/%{Called-Station-ID}?section=authenticate"
method = 'GET'
tls = ${..tls}
}
accounting {
uri = "${..connect_uri}/user/%{User-Name}/sessions/%{Acct-Unique-Session-ID}"
method = 'POST'
tls = ${..tls}
}
post-auth {
uri = "${..connect_uri}/user/%{User-Name}/mac/%{Called-Station-ID}?action=post-auth"
method = 'POST'
tls = ${..tls}
}
connection {
reuse {
min = 10
max = 100
cleanup_interval = 30s
}
connect_timeout = 3.0
}
}