In message <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Wietse Venema) wrote:
>Ronald F. Guilmette:
>>
>> I'd like to propose a small enhancement for the Policy Server protocol.
>> I'll code up a first cut of it, if nobody else is willing.
>>
>> Basically, I think it would be very useful if the protcol included a
>> line like:
>>
>> trusted_client=[yes/no]
>>
>> where the value would be set to "yes" if and only if the client had
>> either authenticated (SASL) _or_ the client connected from some IP
>> specified in $my_networks.
>
>You are assuming that mynetworks, SASL and TLS will grant identical
>privileges to the client
I don't believe that I was making such an assumption, but in any case,
I think the rest of what you said may make that debate moot anyay.
>For this reason, combining multiple different things in one name
>is not a good idea.
As a general design principal, I would have to agree with you 100% on that.
But of course, there are always times when one has to be a bit flexible about
one's design principals, in order to achieve the objective most succinctly
(e.g. reject_unauth_destination, which combines multiple kinds of checks
into a single name). But here again, we could save this philosophoical
debate for another day, because I think what you proposed (below) will
solve my original problem neatly, and it wouldn't violate your design
principal.
>Perhaps it is better to extend the existing
>sasl_ and cert_ attributes where needed
OK. That would work for me. Could I just have something like this?
client_in_my_networks=[yes/no]
>(for example, sasl_method
>and sasl_username already tell you if someone used SASL successfully).
Yes. Quite so. So that takes care of the SASL part of the problem. Now
I'd just like my policy server to have enough information so that it can
also properly deal with the case where the client is trused on account of
where he is, not on account of his having been formally authenticated.
