Region-Based

Assume that you want to control access to resources based on a geographic breakdown of your organization. For example, none of the components or VPEs created in the North American (NA) region should be able to be read, updated, or deleted by anyone outside of the NA region.

In this example, we assume that users can only belong to one region. However, if this is were not true, we could use modifiers to tweak the model.

Here are some suggested steps that you could follow to implement this access control model:

• Create groups that reflect your geographic divisions. For example, "NA-users", "EMEA-users", and "Global-users".

• Create a group attribute called “Region” and set it appropriately for each group (for example, "NA" for the "NA-users" group, "EMEA" for the "EMEA-users" group, etc.)

• Also create a similar "Region" UDA for your component scenarios, and plan to coordinate these with a VPE property such as Location or Description.

• Add your users to the appropriate groups.

• Set the "Region" UDA and the VPE region property to the appropriate values to coordinate with the "Region" group attribute. (For more information about UDAs and using them with components and assemblies, see Managing user defined attributes). You will be comparing these values within permission rules, so you must ensure that the value strings are identical.

Next create permissions and associate them with the groups:

• Perm1: Component: Create: true

• Perm2: Component: (R, U, D):
component.customAttributes.region == currentGroup.attributeValues.region

• Perm3: VPE: (R, Cost_Using):
VPE.location == currentGroup.attributeValues.region

A note about roll-ups

If you have roll-ups, you should implement a consistent roll-up naming strategy that incorporates the region into the name. (Roll-ups currently cannot make use of UDAs.) For example:

"NA_Rollup_XYZ", "EMEA_Rollup_XYZ", etc.

Your permission rules would then need to reflect this naming convention. For example:

Perm4: Rollup: (U, D, R):
index(upCase(rollup.name),upCase(currentGroup.attributeValues.region)==1

A Note about VPEs

In the simplest case, your regional groups might be the same as your VPE locations. For example, all North American users could have the same access to the aPrioriUSA VPE. But what if your North American region makes use of separate VPEs for USA and Mexico?

If VPE.location values are not the same as the Region values, you might consider using a different VPE property such as "Description", or even editing the default value of the "Location" property. "Location" is not used internally by aPriori, so if your site does not already depend on this property, you should be able to modify it as necessary.

You could then develop a rule such as:

VPE.location == currentGroup.attributeValues.Region

Configuring Administrators

Setting up access control for administrators in multiple regions can be handled in a manner similar to the users shown in the previous sections. (This configuration is not necessary if all of your administrators have access to all regions.)

• Create a group for administrators in each region, such as "NA-admins", "EMEA-admins", and "Global-admins".

• Add administrators to the appropriate groups.

• Assign the "Region" group attribute to each group and set it to reflect the region.

• Assign a VPE property to the same Region values, as described in the previous section.

• Create different rules and associate them with the groups. For example, you might give more access rights to VPEs for administrators.