Don’t Forget about Access Policies in Application Workspace

When configuring a new Application Workspace environment for a customer, establishing robust access policies should be a top priority. These policies allow you to restrict or grant access to specific components, while also enhancing security by ensuring that only authorized users and administrators can access sensitive data. They also support improved compliance with industry standards by clearly defining access rights and reducing the risk of unauthorized activity. Access policies come in two types: role-based, which provides predefined privileges, and script-based, which offers greater control through customized scripting.

There are a few ways to assign access policies: they can be applied per user, per user collection, per group, or per context. There are two types of access policies:

• Role: Grants predefined privileges.
• Script: Offers greater control but requires scripting.

For now, let’s focus on role-based access policies. When you install a fresh copy of Application Workspace, you will find a few built-in role-based access policies:

• Administrator
• Catalog Maintainer
• Connector
• User

The first thing I always do is copy the Administrator and User roles. I then rename them using the customer’s naming convention.

When duplicating a role, all the privileges of the built-in role are preserved. This is beneficial for administrators, as the default privileges often meet the team’s needs. However, the privileges for the user role usually require custom configuration. The configuration of user privileges depends on the type of Application Workspace customer and the components of the suite they intend to use.

Once the access policies are created and assigned to identities such as users, user collections, groups, or contexts, you might think you can set them once and never revisit them. But of course, they should be regularly reviewed and updated to reflect changes in both the product feature set or potential new roles in the organization.

Watch for New Access Policy Capabilities

The Recast development team frequently adds new features and improvements, introducing new privileges. These should be assigned in a controlled manner so that users are not surprised by unexpected components and administrators receive only the privileges they need.

Recently, after new release, I discovered the ability to add newly introduced privileges to access policies while configuring auditing in a customer’s Application Workspace environment.

Before configuring the access policy with the correct privileges for event collectors, the auditing section did not appear in the menu, and there was no way to configure the event collector with an auditing database.

After comparing a newly configured Application Workspace environment with the customer’s environment, I noticed a slight difference in the privileges assigned to my administrator role.

After configuring the access policy with the correct privileges for viewing auditing events and configuring event collectors, the newly added feature appeared in the customer’s environment, as if by magic!

I added the auditing configuration to the filter section of the event collector database, and shortly thereafter, the auditing events became visible in the environment.

Auditing events are now visible in the environment!

Conclusion: Access Policies Updated Application Workspace

Lesson learned: periodically review your access policies, whether you’re learning about new features or troubleshooting an environment that behaves differently. It’s always wise to verify that you have granted the appropriate components to your users and administrators.

---

Introducing Jeroen Ebus, PeopleRock

Meet Jeroen—an IT consultant specializing in Microsoft, Citrix, EUC, and endpoint management solutions including ConfigMgr, XenApp/XenDesktop, Azure, Liquit Workspace, and Ivanti Workspace Control. He holds a bachelor’s degree in IT Management & Security.