22 sep 2011 kl. 08:46 skrev Markus Ludwig Grandpre:

> On 09/22/2011 01:57 AM, Sam Hartman wrote:
>>    Luke> How do we solve Markus' problem with the tools we have today?
>>    Luke> It seems like a very real one. Presumably we don't want to
>> 
>> To the extent things can be expressed in RADIUS, we can do it there.
> 
> In RADIATOR configuration there is a SearchFilter directive in LDAP
> section (inner authentication) that is used to define basic authZ rules,
> e.g.
> 
>  SearchFilter = ([log in to unmask])
> 
<snip>
> 
> I don't think authZ should be expressed in configuration of a RADIUS
> server. AFAIK RADIUS protocol is only used for authN. I do think
> moonshot SPs should be enabled (like common Shibboleth SPs) to define a
> set of authZ rules and they should be enabled to validate the required
> SAML attributes that have been returned from IdP and that are only
> tunneled through a RADIUS server via EAP protocol.

After a phone call with Josh and Rhys the other day I added a filtering functionality to the freeradius_pysaml2 SP.
This would filter the returned attributes depending on service-name and hostname.
Extending this filter function with simple LDAP like search filters like your example above would be rather trivial.

Note though that we had a discussion about whether the filter should be applied by the SP or at the AA/IdP.
We decided to go with the SP since it would be easier to get something up and running in the short term.
After gaining some more experience we could then decide on the proper place to do this.

-- Roland