Example Moonshot Policies
Hi. We've been working with Alan to get some changes related to Moonshot (http://www.project-moonshot.org/ ) into FreeRADIUS. Thanks to his work, most of our changes are now in the code base. There's one change not yet integrated related to the support of a trust router for dynamic realm provisioning. We're putting together a number of sample policies. In particular: * Updates to the channel binding virtual server to do correct matching of ABFAB requests information * A policy for an ABFAB IDP (home AAA server) to use to verify that information supplied by the NAS matches what's expected for that NAS according to a database provisioned by the trust router * A policy to run on a proxy near the NAS to verify that the NAS is claiming the correct identity based on client configuration. None of these policies actually depend on the trust router code that isn't yet integrated, although most useful configurations where you'd want to turn on these policies would require that code. we'd like to supply these sample policies to be included. For the most part our preference is to give a policy.d file so that it can be easily updated. would you prefer that we also contribute commented out code to invoke this policy at the right places in sites-available? Should we contribute a sample database module to demonstrate the database we're using Or would you rather us put that in the trust router package? Thanks, --Sam
On 21 Jul 2014, at 21:56, Sam Hartman <hartmans@mit.edu> wrote:
Hi.
We've been working with Alan to get some changes related to Moonshot (http://www.project-moonshot.org/ ) into FreeRADIUS. Thanks to his work, most of our changes are now in the code base.
There's one change not yet integrated related to the support of a trust router for dynamic realm provisioning.
We're putting together a number of sample policies. In particular:
* Updates to the channel binding virtual server to do correct matching of ABFAB requests information
* A policy for an ABFAB IDP (home AAA server) to use to verify that information supplied by the NAS matches what's expected for that NAS according to a database provisioned by the trust router
* A policy to run on a proxy near the NAS to verify that the NAS is claiming the correct identity based on client configuration.
None of these policies actually depend on the trust router code that isn't yet integrated, although most useful configurations where you'd want to turn on these policies would require that code.
we'd like to supply these sample policies to be included. For the most part our preference is to give a policy.d file so that it can be easily updated.
Agreed, best to group them in a file with their own common prefixes.
would you prefer that we also contribute commented out code to invoke this policy at the right places in sites-available?
No, include example sites-enabled virtual servers to implement the various moonshot roles. The current default file is too cluttered already.
Should we contribute a sample database module to demonstrate the database we're using Or would you rather us put that in the trust router package?
Feel free. It should go in mods-config/sql/<db flavour>/moonshot or whatever the framework/protocol will be eventually known as. My preference is for sqlite, because the database can be bootstrapped using a schema file the first time the server is run. Most serious sites will probably be running PostgreSQL, so both would be good if you have time/resources. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
"Arran" == Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
>> Should we contribute a sample database module to demonstrate the >> database we're using Or would you rather us put that in the trust >> router package? Arran> Feel free. It should go in mods-config/sql/<db Arran> flavour>/moonshot or whatever the framework/protocol will be Arran> eventually known as. So, that doesn't seem to make sense with the current layout. We don't have a queries.conf and the schema lives in the trust router package. What we have is a database module definition for a sqlite (currently all the trust router supports) database. We access this with xlats from two places. First, from the psk_query section in a tls listener. Secondly, from a policy in authorize to reject the request very early if constraints aren't matched. i'll contribute a mods-available entry, but if you want to create something for this under mods-config feel free. It just doesn't seem to fit under there today.
On 23 Jul 2014, at 13:05, Sam Hartman <hartmans@mit.edu> wrote:
"Arran" == Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
Should we contribute a sample database module to demonstrate the database we're using Or would you rather us put that in the trust router package?
Arran> Feel free. It should go in mods-config/sql/<db Arran> flavour>/moonshot or whatever the framework/protocol will be Arran> eventually known as.
So, that doesn't seem to make sense with the current layout. We don't have a queries.conf and the schema lives in the trust router package. What we have is a database module definition for a sqlite (currently all the trust router supports) database. We access this with xlats from two places. First, from the psk_query section in a tls listener. Secondly, from a policy in authorize to reject the request very early if constraints aren't matched.
i'll contribute a mods-available entry, but if you want to create something for this under mods-config feel free. It just doesn't seem to fit under there today.
If you're only using SQL xlat, then there's mo requirement for additional files under mods-config. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (2)
-
Arran Cudbard-Bell -
Sam Hartman