User permissions, part of the overall user management process, are access granted to users to specific resources such as files, applications, networks, or devices. Let’s dive into the specifics of this important user management aspect and learn why you need to be on top of things for the best results.
User permissions can also specify:
- The type of access—for example, a user might be allowed to read data without modifying it (read only) or be allowed to read and write data.
- Specific functions a user can access—for example, most systems have an administrator role that allows users to change configuration or assign permissions to other users.
User Authorization vs Authentication
User permission is tightly related to two concepts—authentication and authorization. In general, authentication is performed before user permissions are granted, and authorization is the process of granting user permissions.
User authentication involves verifying a user’s identity before allowing them to access a system or application. Authentication requires the user to prove their identity using one or more authentication factors. These factors can include things the user has (for example, a digital signature, ID, security token), information the user knows (such as a password or PIN) and the user’s biological characteristics (such as fingerprint, voice, or retina scan).
User authorization is the process of determining which resources users are allowed to access. For example, users in a website content management system (CMS) can be assigned permissions to comment on articles (guest), author and edit articles (contributor), and change website look and feel and configuration (administrator). Authorization can also segment content in an application and allow each user to access content that is relevant to them.
Types of Authorization Permissions
Here are a few types of permissions administrators can grant to users:
- Role-based permissions—employees can access only the resources they need to do their job. The concept of least-privileged access ensures that each user has the minimal permissions they currently need, limiting the impact of compromised accounts.
- Device-based permissions—bring your own device (BYOD) policies mean a growing number of employees are accessing corporate systems using their personal devices. If users do not install operating system updates and security patches and do not have an antivirus installed, the device may be at risk. Device-based permissions can grant permission to users depending on the security hygiene or other characteristics of their device.
- Location-based privileges—users can receive different permission depending on their current location. For example, a user who has permission to access highly sensitive financial data, might not be permitted to access it from their home or from a foreign country.
Real-Life Example: User Permissions on Android
When creating an Android application, developers can choose to declare permissions that enable access to restricted data or resources on the user’s device.
The following diagram illustrates the process of declaring permissions. If the application requires special permissions, developers must declare them in the app manifest file, and in some cases, require users to grant access every time a specific action is performed.
Android has several types of permissions, including:
- Install-time permissions—allow the app limited access to restricted data and actions, which can have minimal impact to the system and other apps. These permissions are automatically granted when a user installs the app. The app store displays a notification to the user during the installation process.
- Normal permissions—allow access to data and actions outside the app sandbox, where these pose little risk to user privacy or to the operation of other applications.
- Dangerous permissions—permissions that involve user data or privacy, such as reading contact data, accessing the calendar, or using the camera.
- Special permissions—system-level permissions that are not used by most applications, and can only be defined by the Android platform and OEMs.
How to Review User Access and Permissions
Here are some of the steps administrators should take to evaluate an organization’s user access permissions.
Defining Access Management Policies
The user access management policy must at the very least include these components:
- Asset inventory—lists all the assets across the enterprise, including the networks, systems, databases, operating systems, applications, and physical locations (i.e., data centers, offices, etc.). Documenting assets is important for informing decisions about user access privileges.
- Asset owner list—identifies the owners of every asset, whether managers, administrators, specific teams, or team members. Each asset owner should detail the types of accessible content and data in each asset to help shape access-level and role-based policies.
- User roles and access level descriptions—specifies the roles and responsibilities of each user and details the access level required to perform these roles. The descriptions should be granular, specifying which employees require edit access, deleting capabilities, or can suffice with read-only access. Admins should identify the least privilege required for each job function to help minimize security gaps.
- Provisioning and de-provisioning details—help define the lifecycle of user access privileges, including the processes for provisioning and de-provisioning permissions. Provisioning involves assigning access permissions to users, while de-provisioning involves revoking access privileges when users move to a new role or leave the company. Deprovisioning access privileges and offboarding processes are essential to securing an organization’s assets. To update these processes, asset owners and managers should refer to regular access permission reviews.
A well-defined policy enables administrators to create reports of the organization’s database, system, and application access permissions. This step confirms who currently has access to each asset, including employees and external actors like contractors and vendors.
All asset owners should receive copies of these reports to audit and verify the list. Asset owners can then reassess the existing access privileges and modify or revoke them. They might use a granular or broader approach (i.e., role-based or team-based) to determine access privileges. Different individuals with the same role may have different responsibilities and permissions in some cases.
Remediating and Reporting
After receiving all the user access reviews from asset owners, admins can implement changes to the access policy. This step involves removing revoked privileges and updating employee privileges as required. Administrators can then generate new user access reports to verify that these changes are effective.
After finalizing reports, it is important to print and store them. A finalized report should cover all past and current access privileges and roles, asset owners, and the names of the admins who approved the permissions. It should also include notes for future actions. Reports are important for auditing and provide evidence of compliance with access certification rules and standards.
The final reporting phase is also the best time to reassess security measures and identify gaps. For example, an admin might rethink the established provisioning procedure if it results in excessive or insufficient revoking of user IDs and privileges. The final report also helps measure the efficacy of security and IAM policies. Its findings suggest whether the onboarding, role transferring, and access termination policies align with the organization’s overall security objectives.
Administrators can also use this opportunity to assess the reviewing process and identify ways to simplify it.
User Permission Management with Frontegg
Creating, managing, and tweaking roles and permissions is not an easy task. It puts extra pressure on your engineering teams and also contributes to frustration with the end-users, who have to contact support and IT teams to get the job done.
Frontegg is changing the whole dynamic of the situation with its self-served user management platform, where SaaS businesses can create their own roles and permissions to represent their business requirements and use cases. Furthermore, Frontegg also allows end users to create custom roles to represent their specific permissions model, without changing a single line of code in the product. It’s a true gamechanger. Try it out now.