Forum Discussion

Scott123456789's avatar
Scott123456789
Icon for Cirrus rankCirrus
Sep 30, 2015

Access profile - force user to reauthenticate

Hello,

 

I would like to use my Access profiles to force users to periodically re-authenticate. I'm primarily using Kerberos and NTLM authentication (depending on the application). As an example, one of my access profiles is to authenticate to a test instance of SharePoint 2013. I have the Inactivity Timeout period set to 900 seconds; it's using a Kerberos SSO configuration; the access profile, to allow a client, does a client cert inspection, a variable assign, and SSO Credential Mapping. All of that works as expected. If a user is constantly working on this application for 2 hours without hitting the inactivity timeout period, they would never be asked to re-authenticate. I'd like them to have to re-authenticate periodically, let's say every hour, even if they don't hit the inactivity timeout threshold.

 

Does anyone have any ideas how this could be accomplished? Thanks in advance.

 

APM
design
security

2 Replies

Sort By
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Sep 30, 2015

    Since you're doing client cert, even if you did force re-authentication the client wouldn't see it, as modern browsers will remember the chosen cert and not re-prompt. If you set the frequency option in the client SSL profile to always (vs. once), a full mutual handshake will be forced at each new TCP connection, which would do what you need more or less, but also incur some latency.

     

    You're using the client cert inspection agent in the visual policy, so that also implies that you're requiring the client certificate from within the client SSL profile. In that case, the client is establishing an SSL (encrypted) session with a server (BIG-IP) that requires mutual authentication. The client and server may periodically renegotiate new session encryption keys, but at no time would there be a lapse in SSL continuity that might warrant forced re-authentication. If you used the on-demand cert auth agent or any other authentication form, that'd be a different story.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Oct 01, 2015

    So I think it then boils down to how you want users to re-authenticate. The fact that browsers remember your cert selection and won't re-prompt you is something that you're not going to be able to get around. Even if you force an SSL renegotiation by invalidating the current session, the user won't see this. If the intent is to display something for the user to click on, then certificate authentication isn't going to be the best option. If you just need the client to re-submit their certificate, even if that's not visible to the user, then that's already happening as part of the SSL exchange between the client and BIG-IP. You can validate this with a WireShark capture on the client side of the BIG-IP. You'll see the client periodically sending a ClientHello (via new session request, resumed session request, or renegotiation) and the server responding with ServerHello, Server Certificate, and Certificate Request messages. The Certificate Request message causes the client to send a Certificate message and then a Certificate Verify message. The first contains the client's certificate, and the second a hash of that signed by the client's private key.