Hi and thanks for your help, Alan DeKok <aland@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+