Skip to content
Access Control
Release Notes

Deprecation and Expiration Lifecycle

Basic Lifecycle

When you think about the lifecycle of an employee, you usually look at their hire date, a day that they change jobs laterally to a different team, get promoted into a different position, or leave the company.

These are the major events that are tracked reasonably well by your Human Resources Information System (HRIS). From an employee perspective, these are milestone dates for updating their job history on their resume or LinkedIn profile.

When we look at these in their simpest form, we can think of the state of an employee as ACTIVE or DEACTIVATED. In Access Control, these are applied on the Directory User record.

TODO Example Metadata JSON

Promotion Lifecycle

Now let’s think about an employee that is an engineer for 2 years and then is promoted to a manager. From an access persective, they may have access to 20 applications when they are an engineer. When they were promoted, they lost access to 10 of those engineering systems and gained access to 5 HR related applications for management tasks.

If you or your team has to manually handle the tasks involved with changing a users access, you’re not alone. It can be painful and require a lot of care and attention.

It only gets more complicated if the user is going to transition into the new role over the next month and needs access to all 25 applications during the transition period. This might mean that the IT and Security team has to add the HR application access, then wait a few weeks and come back to remove their engineer access. If you’re at a larger company and it is performance review and promotion season, you may be juggling dozens or even hundreds of these.

Something is going to get missed, and your auditors or your users will complain about it.

Does this sound familiar? There is a better way.

Deprecation

In the software world, we are familiar with the concept of deprecation. We don’t want to cause a breaking change, so we will introduce a new version and announce that the old version is deprecated and will be removed at a future date. This gives everyone plenty of time to adapt and have a “grace period” that is less disruptive.

Since Access Control has a cache of the state for each system, we can compare before and after changes. Access Control has the same deprecation concept by updating a record with the EXPIRING state and an expires_at date timestamp that is automatically calculated based on your configuration set in expires_after_days (default: 30).

Job Title Changes

For example, if a user’s job title changes, we know what it was before and what it is now.

With traditional group rules, once the value changed, the user would ubruptly lose any access associated with the group and group rule that matches their old job title string value.

The reason that this has been a pain point in the industry is that most user profiles are a key value array and the key for job_title only accepts a single string value, so it can only have one job title at a time.

TODO Example Checklists

Access Control has taken a different approach with a database record for each user, each attribute (possible values for a dimension), and a many-to-many table for attaching a user to one of the possible attributes.

This allows us two key benefits:

  1. We can attach a user to multiple attributes at the same time. This is useful for that 1 month period where they need access to both engineering and HR systems.
  2. Each database record can have its own timestamps and state, effectively allowing it to have its own lifecycle.

(TODO Diagram)

Expiration

One of the biggest pain points when dealing with transitions is coming back later to do Part 2 of the work to deprovision the old job title’s access.

We have solved this with expires_after_days that allows us to automatically calculate the expires_at timestamp on a record and start a proverbial countdown timer. This is a one time calculation and you can override the expires_at value as needed.

We perform sync jobs hourly. When the expires_at timestamp is reached, the next sync job detects expired records and deactivates them. The follow up sync jobs for the user manifests detect that the user no longer matches the rule conditions and removes them.

In the case of job title changes, this sets the new many-to-many database record as ACTIVE. The old job title many-to-many record changes to EXPIRING with a calculated expires_at date timestamp. When the expiration is reached in the future, it changes to EXPIRED and is soft deleted in the database which is identical to being DEACTIVATED.

We use soft deletes to ensure that we do not permanently lose data for audit reasons. The only difference between EXPIRED and DEACTIVATED is whether the system background jobs automatically did it using previously configured expires_after_days or whether a human administrator manually deleted the record.

TODO Model Diagram with State

Configuring Expiration Settings

Every organization has different needs when it comes to setting the grace period before user’s lose access.

It is reasonable at first glance to think that users should lose access immediately or in 1-5 days. This is true for employees that are leaving the company. However there is more nuance with changes while a user is still active. You should think about how often you have to grant exceptions and delay deprovisioning access for some users.

When looking at access management, there is a balance between the goal of least privilege and mitigating risk combined with ease of access for a group of users. You will generally grant less sensitive applications to the entire department and more sensitive applications to a specific team or job title.

If a user changes job titles, they may need different levels of access through the transition. For example, if an employee in the IT department changes job roles, it would make sense to remove their administrative access within a few days but maybe they should have access to the shared Google Drive and the documents inside of it for the next month. These are examples where you can have different expires_after_days values on the respective Directory Ruleset that provides that access.

The global setting that is inherited downstream is set in directory_dimension_expires_after_days in the Auth Tenant record.

By default, this is set to 30 days but you can change it to a lower value if your organization is more stringent. It is strongly discouraged to set this value to less than 10 days unless you accept the risk of higher volume of helpdesk support requests and dealing with exceptiom cases for extending the expires_at value. The best practice is to provide a sensible default grace period, and override the expires_after_days value on a case-by-case basis in the Source, Dimension, Attribute, Blueprint, or Ruleset that is more sensitive to remove access sooner.

TODO Precedence Diagram

You can customize your expiratiom policies based on your own risk perception and organization needs. You can also make changes later if you need to raise or lower the expires_after_days, or override the expires_at value for a specific record or situation.

Organizational Changes

Let’s expand this to some of the other events that happen at most organizations:

  • A user’s manager changes
  • One or more teams are renamed
  • A team’s responsibilities have changed and need to be added or removed from various applications or resources inside.
  • A team split into multiple teams
  • A team merges with another team
  • A department has been renamed or refactored
  • The job titles for team member(s) change
  • The systems that you have access to change due to policy updates
  • The administrator of a system you have access to has changed what role you have on that system

These are all common events that happen frequently at companies with 500+ users, and each comes with its own transition period since an announcement date, effective date, and process transition complete date are three differnt things.

How are you supposed to keep all that straight in your head? If you’ve got a handle on it, give yourself a pat on the back.

The only constant in companies is change.

Ruleset Manifests

Now let’s see how we can gracefully automate these transition situations with automation in Access Control.