Forum Discussion
Maudigan
Altocumulus
AltocumulusRevocation Status in HTTP Request Header
I'm setting up a web app that will use the EDIPI to validate my user's accounts. I think I have a working udnerstanding of how that'll work--I'm going to be setting up a iRule to forward the users EDIPI to the server. (see here)
It dawned on me that I'm not really sure how that process works with the revokation status. If their CAC is revoked will CLIENTSSL_HANDSHAKE or HTTP_REQUEST_RELEASE fire?
I'm picturing still getting their EDIPI off the CAC and setting that in the header, but also getting their revocation status and putting a yes/no in the header for "x-revoked". I could easily then check that in my server code. I believe that's how that works with Cloud 1.
Is that the way I'd do that, or would the best practice be to just not send their request at all somehow?
CAC sites tend to be locked down. Often they'd prefer that if the user has a revoked CAC that the site simply refuse to issue ANY HTTP response to them at all, which is definitely the most secure position. Typically the less information you send to an unauthorized user, the better. However, if you set it up this way (clientssl set to require client cert), then the site appears broken to users with a bad CAC.
A slightly less secure one would be to have BIG-IP respond with a "CAC auth failed" kind of message and not forward the request to the server. This way the site doesn't seem completely broken to invalid users, which makes user support easier. But it gives attackers more information. It's a trade-off.
BIG-IP can easily facilitate either of these positions by configuring the clientssl profile to request (validate the cert, allow the associated HTTP request), or it can be set to require (validate the cert, shutdown the connection if the cert is not valid). I'd recommend reading this article to get an understanding of how to set that up to meet your requirements.
To answer your question directly though, the fired events would look like this depending on the request/require setting:
Cert Bad Cert Good clientssl client cert = Request CLIENTSSL_HANDSHAKE, HTTP_REQUEST_x CLIENTSSL_HANDSHAKE, HTTP_REQUEST_x clientssl client cert = Require CLIENTSSL_HANDSHAKE CLIENTSSL_HANDSHAKE,HTTP_REQUEST_x
- Lucas_Thompson
Employee
CAC sites tend to be locked down. Often they'd prefer that if the user has a revoked CAC that the site simply refuse to issue ANY HTTP response to them at all, which is definitely the most secure position. Typically the less information you send to an unauthorized user, the better. However, if you set it up this way (clientssl set to require client cert), then the site appears broken to users with a bad CAC.
A slightly less secure one would be to have BIG-IP respond with a "CAC auth failed" kind of message and not forward the request to the server. This way the site doesn't seem completely broken to invalid users, which makes user support easier. But it gives attackers more information. It's a trade-off.
BIG-IP can easily facilitate either of these positions by configuring the clientssl profile to request (validate the cert, allow the associated HTTP request), or it can be set to require (validate the cert, shutdown the connection if the cert is not valid). I'd recommend reading this article to get an understanding of how to set that up to meet your requirements.
To answer your question directly though, the fired events would look like this depending on the request/require setting:
Cert Bad Cert Good clientssl client cert = Request CLIENTSSL_HANDSHAKE, HTTP_REQUEST_x CLIENTSSL_HANDSHAKE, HTTP_REQUEST_x clientssl client cert = Require CLIENTSSL_HANDSHAKE CLIENTSSL_HANDSHAKE,HTTP_REQUEST_x 
MaudiganAwesome, Thanks again!