User access modification / termination

Occasionally in ZPA deployments there is a desire to respond to modification or termination of user access more quickly than would be executed by the user re-authentication timeout. Eventually this functionality will be automated by SCIM integration, but in the meantime, here are a couple of approaches for dealing with these two scenarios today.

Access Modification

For modification of access privileges, to update user access when their roles change in the back-end AAA, one easy approach is to set up “phantom” app - the sole purpose of which is to trigger a re-authentication request. The simplest way to implement this is by defining an unused FQDN on TCP 80 / 443, setting a very short reauth policy for that app, and then instructing the end user to browse to that FQDN.

These are the steps to set up the dummy hostname for triggering an immediate SAML assertion refresh:

  1. Choose a unique FQDN not used for anything - e.g. rolechange.corp.com - you don’t need a server set up for it.
  2. Define a ZPA app segment for rolechange.corp.com on TCP 80 & 443
  3. Put that app segment in its own dedicated app segment group - no other app segments in that group.
  4. Define an access policy to permit all users to access that app segment (allow / all / rolechange).
  5. Define a reauth policy to force reauth if the SAML assertion is older than 10 minutes (all / rolechange / reauth=10min).

When a user’s role or other attributes are changed in the back-end AAA, instruct the user to web browse to that hostname (i.e. http://rolechange.corp.com). This will trigger the reauth policy, since their SAML assertion will almost certainly be older than 10 minutes old. When they reauth, the fresh SAML assertion will have the updated roles / attributes.

Access Termination

To eliminate user access after a termination - assuming their user account has been disabled in the back-end AAA - the simplest method is to go into the Zscaler App portal, search for the user name, and force remove all devices associated with that user. ZPA will delete the enrollment cert within 4-5 minutes and terminate all associated app sessions. Following this, the user will see a Connection error in ZApp and won’t be able to re-enroll, since their account is no longer valid in the IdP.

Regards,
Lisa

1 Like

Hi Lisa,

Access Modification => we did this some time ago already quite like you described it but then user were confused that the browser just shows an error when going to rolechange.corp.com as they expected to see sth in the browser and didnt watch the Zapp beeing triggered for reauth.

Therefore we did a Little modification to the above:

  1. rolechange-url is Setup in Zapp but with infinte reauth
  2. rolechange-url points to a webserver where a simple page is shown with a text that reauth has been triggered and a screenshot how to click on reauth in Zapp etc…
  3. This simple Webpage calls another URL in a hiddenframe like rolechange2-url . This is again configured with a reauth policy of 2 minutes which then triggers the actual reauth in the Background.

Conclusion: User clicks on a working link, gets a html page shown in the browser what to do and reauth is done

Note: I would love to have a button in the Zapp Client called Force Reauthentication, which would then call our URL.

Thanks

Alex, that’s brilliant! Thank you for sharing. :slight_smile:

Regards,
Lisa

If the customer is also a ZIA customer, then there might be some tricks you can do with block pages and redirects to send them to the phantom app automatically. You’d have to make sure the redirect only triggers once and never again after they re-auth.