Using X.509 Cert. subject and issuer for authorization with EAP-TLS

[Arnaud Ebalard]

Hi and thanks for your help,

Alan DeKok <aland at deployingradius.com> writes:

> Arnaud Ebalard wrote:
>>>From my understanding (don't hesitate to correct me), the authorization
>> step being done before the authentication step (for the purpose of
>> selecting the allowed authentication method), it does not seem possible
>> to use attributes from the X.509 Certificate provided by the client for
>> the purpose of authorization (it comes too late).
>
>   No... there are multiple packet exchanges involved.  You can check the
> certificate ONLY after you've received all of it.  This happens during
> one of the authorization phases, and before authentication happens.

I might be missing something but the certificates get available during
the TLS exchange, i.e. long after the decision from the authorization
modules. From the debug I added in the code, the rlm_files module
returns OK before the beginning of the authentication steps (implying
rcode has been set).

This rcode is conditioned by the issue of the authentication (if
authentication fails, the Accept will change to a Reject). In my case,
the idea is to authorize *unknown* people to authenticate with EAP-TLS
and decide later what to do with them (i.e. been someone from my PKI
should not automatically imply an Accept).

Obviously, I would like to be able to kick people or return specific
attributes based on the content of their certificate (where more
information is available than simply its username) even if they have
been authorized to authenticate. It seems to require actions *after*
authentication has happened (i.e. after the certificate gets
available). 


>> I expected I would be able to extract the information from the client
>> Cert during authentication and make it available for Post-Auth in
>> order to decide what to do in a more precise manner (change attribute,
>> reject, ...).
>
>   That's a great feature.  As always, patches are welcome.

If it's feasible (i.e. leads to functional code), i'll post it here.


>> - where to store the information grabbed in the SSL callback,
>
>   Don't.  There's no reason to grab that information if no one is
> looking for it.  Instead, save a pointer to the SSL session, and
> register a callback that can dynamically expand the strings, if, and
> when, someone asks for it.
>
>   See xlat.c, and other examples of registering a callback.

ok. Thanks, i'll take a look and see if it helps.


>> - how to make that information usable in a transparent fashion for
>>   Post-Auth modules like rlm_files, ... 
>
>   That's the purpose of the callbacks: to be transparent.

ok.


>> - how to force a reject and not only change attributes, ...
>
>   That's a policy.  It has nothing to do with certificates.

ok. Is there a place after authentication (i.e. not authorization) where
I can act on rcode? If not (and if policy prevents action in Post-Auth),
it seems I am stuck.

Thanks again for your comments and your time.

a+