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.