Margaret and I were discussing how we expect constraints to be
communicated between trust_router and freeradius.

Within Freeradius, we'll receive an access-request packet including the
gss-acceptor-host-name and gss-acceptor-realm-name


It's possible that new constraint types will be added in the future
perhaps related to how a specific service considers
gss-acceptor-service-specifics.  Or perhaps related to
gss-acceptor-service-name.

The current constraints are strings containing  possibly prefix-matched
wildcards.

So, a constraint might look like "print-server.painless-security.com" or
"*.painless-security.com"

Currently the trust router and  Freeradius use an sqlite database to
communicate.

We'd like to set up things so that  it's efficient to  perform a single
database query for each type of constraint.

Also, the we need to discuss how we'll index the constraints.
From the standpoint of the trust router, a connection is identified by a
key ID.  However, as we've discussed, An RP proxy will tend to use the
most-recently created  key to a given realm.
So we want to merge privileges based on the DH public key used by the RP
proxy.

So, we include a dh_key column in the keys table along with the PSK key
name and the PSK.  This will allow Freeradius which DH public key is
used to set up the association.

Then we establish a table for each type of constraint looking something
like:

create table host_constraints (dh_key string, host_constraint string,
unique(dh_key, host_constraint));

Then we can do
select from host_constraints hc, keys k where k.dh_key = hc.dh_key
       and k.key_id = key_id_from_tls
       and constraint_from_packet like hc.host_constraint

If we encode the host_constraint to be compatible with an SQL like
clause, then everything works.

So, we'll want a function to iterate over all the constraints of a
specified type that are present in a request.

we'll also need a function to convert from our prefix match form into an
SQL like clause form, but that's relatively easy.

This set of queries is only efficient if there are a relatively small
number of constraint rows for a given dh_key.  I think that's going to
be very likely though.

Thoughts?