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

[Alan DeKok]

Arnaud Ebalard wrote:
> I might be missing something but the certificates get available during
> the TLS exchange, i.e. long after the decision from the authorization
> modules.

  Please read what I read.  There are MULTIPLE packet exchanges.  The
certificate is available during ONE of those packet exchanges.

> 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).

  Yes.  So?  Do you understand that multiple packets go back and forth?

> 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

  That's not the way EAP-TLS works.  They need a client certificate in
order to be authenticated.

> and decide later what to do with them (i.e. been someone from my PKI
> should not automatically imply an Accept).

  You can turn an Accept into a Reject.  You can't turn a Reject into 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). 

  As I said.  This is possible.

  But... only for known users.  If you're trying to authenticate unknown
people with EAP-TLS, then it won't work.  Stop trying to do the impossible.

>>> - 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.

$ man unlang

  Alan DeKok.