EEM Calculation Filtering with most commonly used scenarios

Products

• CA Directory

Issue/Introduction

EEM FILTERS

EEM Filters: Filters in EEM help us to have fine grained control over the policies that we write. Using filters we can impose higher control over the authorizations using user details, groups details, session attributes, named attributes and request attributes.

This document assumes that you understand the EEM basics and know the usage of EEM UI in performing administrative tasks.

In this document, we will understand filters with the help of various examples.

• Example
  
  Policy Definition: "The identities in a group whose name starts with "a" are only allowed to "create"
  
  Resource1".
  
  Policy Implementation: The identity of the policy contains a global group. We are saying that the identities of this group can create "resource1". The filter imposes the condition of allowing identities whose user name starts with "a". The LHS contains the global user whose attribute "user name" is being evaluated over the operator "starts with" to the value "a" in the RHS.
  
  

  <Please see attached file for image>

  
  
  

  <Please see attached file for image>

  
  
  There are various attributes of a global user than can be used in the filter. The following image shows some of them which can be used.
  
  

  <Please see attached file for image>

  
  
  We shall now understand the operator data types and the various operations that can be performed.
  
  If the operator data type is selected as "STRING", the following operations can be performed:
• MATCH: Check whether a string value conforms to a regular expression.
  
  

  <Please see attached file for image>

  
• NOTMATCH: Check whether a string value does not conform to a regular expression
• CONTAINS: Check whether a string value is contained within the other string.
• STARTSWITH: Check whether the string starts with a particular string
• ENDSWITH: Check whether the string ends with a particular string
• WITHINSET: Check whether a string is present in a set of strings. The strings are separated by a "'," character.
  
  

  <Please see attached file for image>

  

The following example checks for the action being equal to either of write or execute.

<Please see attached file for image>

• NOTINSET: Check that a string is not present in a set of strings
• EQUAL: Check whether a string is equal to another string
• NOTEQUAL: Check whether a string is not equal to another string
• LIKE: check whether a string starts with, ends with or contains a specific string. The only Meta character allowed here is '*' in beginning or ending or both sides of the string being compared.
  
  The following example checks for the string "a*b" (Note here that * in middle of a and b is not treated as a Meta character) to be contained within the name of any of the dynamic user group the user belongs to.
  
  

  <Please see attached file for image>

  
• NOTLIKE: checks whether the string does not start or end or is present in a string being compared
• LESS/ GREATER/LESSEQUAL/GREATEREQUAL: Checks whether the string specified in the LHS is less than /greater than /lesser or equal to/greater or equal to/ the one specified in RHS. The strings are lexicographically compared.
  
  The following example:
  
  Allows: for a value of resource being "abcd"
  
  Denies: for a value of the resource being "abcw"
  
  

  <Please see attached file for image>

  
  
  If the operator data type is selected as "INT32", "UINT32", " REAL32", "REAL64", "TIMESTAMP" the following operations can be performed
• EQUAL
• NOTEQUAL
• LESS
• GREATER
• LESSEQUAL
• GREATEREQUAL

The above six operators imply the natural meaning of a number being equal, not equal to, less than, greater than, less than or equal to, greater than or equal to the number being compared.

The below example applies a specific policy if the incorrect login count is lesser than or equal to three.

<Please see attached file for image>

• 1. WITHINSET ( applies only to integers)
  
  

  <Please see attached file for image>

  

The above example tells us that the specified set of identities can "execute" all resources if the named attribute "release" is equal to 8 or 12 or contained within the range of 15-18 inclusive. So the release numbers allowed are 8, 12, 15, 16, 17, 18.

If the operator data type is selected as "BOOLEAN", the following operations can be performed.

• EQUAL
• NOTEQUAL

The Boolean variable whose value is true can be specified in either of these ways: y, t, yes, true. They are case insensitive, remaining strings are treated as false. The following example gives the specified identities to access the change password page if the "ChangepasswordNextLogin" is set to true.

<Please see attached file for image>

If the operator data type is selected as "REGEX", the following operations can be performed:

• MATCH:
• NOTMATCH:

They are similar to the match and not match definition of "STRING" data type.

Selecting the operator data type as "XPATH", has no real significance. If the operator data type has been selected as XPATH, the operations LIKE, NOTLIKE, MATCH, NOTMATCH, WITHINSET, NOTINSET, STARTSWITH, ENDSWITH, CONTAINS will be performed on the operands assuming them to be strings.

We have understood the operator data types and the operations. We will now have a closer look at the operands that can be used. We have already used some operands in our previous examples.

• The operands can also be global groups, application groups and dynamic groups .
• The operands can also specify values that involve things directly involved with making an authorization itself. They can be specified using the " request" operand.
  
  

  <Please see attached file for image>

  

Example:

The following filter illustrates that, the authorizing identity's either of the global groups must contain the name of the resource being protected.

• The operand can also specify the session attributes. These session attributes are the attributes of the authorizing user's session. Session attributes include global groups, application groups, dynamic groups, authentication method by which the session was generated, global user attributes( internal) etc:
• dug:Name, gug:Name, ug:Name
• gu:ChangePasswordNextLogin
• gu:DisableDate
• gu:EnableDate
• gu:FirstName
• gu:IncorrectLoginCount
• gu:OverridePasswordPolicy
• gu:PasswordChangeDate
• gu:PasswordExpireTime
• gu:PasswordTimeToWarn
• gu:Suspended
• AuthenticationMethod

The following example specifies that an identity can modify a specific resource if the user account is not suspended.

<Please see attached file for image>

• We can specify named attributes of an application while authorizing. They are additional attributes that can be defined for an application to denote a specific usage.
  
  

  <Please see attached file for image>

  

The following example illustrates submitting of an authorization event only if it was denied permission.

• We can specify user defined environment attributes.

A safe context object can specify an environment. It is a set of name-value pairs. The following code snippet sets an environment attribute by key "os" and the value as the name of the operating system.

SafeContext safeContextObject = new SafeContext();
//set backend
// attach to the application

safeContextObject.insertEnvAttr("os", System.getProperty("os.name"));

The following filter tells to apply the policy only if the environement "os" attribute starts with "win" ( policy can only be applied if the EEM client environment is on windows).

<Please see attached file for image>

• We can specify "calculation" in the filters. Calculators help us to achieve filter values that require multiple combinations of strings.

The below example specifies a policy which requires the resource to be compared of the form <global group name> + "-"+ <global user department>

<Please see attached file for image>

Below is the example of a nested calculation filter. It compares the resource being equal to

<user name> + ( <group name> - "d")

Please note that the "MINUS" operator for the string can only be used to subtract the trailing strings. For example if the group name is "abcdefd", the operation: <group name> - "d" on the group makes it to be "abcdef".

<Please see attached file for image>

REGEX, XPATH are not supported in calculations.

The operations supported under STRING for a calculation filter are:

• PLUS: Concatenate two strings
• MINUS: Subtract the trailing string.
• STRIP: remove leading or trailing white spaces
  
  

  <Please see attached file for image>

  

The string "motor " will be changed to "motor"

• LOWERCASE: convert the string to a lower case
• MIN: Returns the highest among the set of strings in a lexicographic order.
  
  

  <Please see attached file for image>

  

The above filter returns the value of "tractor"

• MAX: Returns the lowest among the set of strings in a lexicographic order.
• COUNT: counts number of values. The below example returns 2.
  
  

  <Please see attached file for image>

  
• LENGTH: length of all the values. The above example returns length("user1user2") which is 10.

The operations supported under INT32, UNIT32 for a calculation filter are:

• PLUS
• MINUS
• TIMES ( multiply)
• DIVIDE
• ABS ( absolute value of the number)
• BITAND (bitwise AND of specified numbers)
• BITOR ( bitwise OR)
• BITXOR (bitwise XOR)
• MIN ( minimum value of the numbers defined )
• MAX ( maximum value of the numbers defined)
• COUNT ( count the number value's defined)

The operations supported under REAL32, REAL64 for a calculation filter are:

• PLUS, MINUS, TIMES, DIVIDE, MIN, MAX, COUNT, ABS, ROUND, FLOOR.

The operations supported under TIMESTAMP are:

• PLUS, MINUS, MIN, MAX, COUNT
• We shall now look at an example where multiple filters are to be defined. Let's say we want to write a filter of the form:
  
  ((filter1 & filter2) | (filter3 | filter4 ))

The filters are written sequentially, where the logic and the parenthesis fall in order.

<Please see attached file for image>

<Please see attached file for image>

• Normalization:
  
  If either of the operands (either LHS or RHS) contain username or principal name, groups (application, global, dynamic) and request identity and delegated identity, the operands are always normalized. The operations performed between them are case insensitive.
  
  If either of the operand contains a resource, the operations are performed case sensitively.
  
  Identities defined inside a calculation filter are always normalized. The groups defined inside the calculators always have their case preserved.
  
  

  <Please see attached file for image>

  
  
  Group name = "Group1"
  Department = "security"
  The calculation becomes: Group1-security
  The resource: group1-security

As the resource operations are performed case sensitively, group1-security != Group1-security

If the LHS had contained, say a dynamic group instead of resource, the comparison would have been successful.

Environment

Release: ESPDIR99000-12-Extended Support Plus-for CA Directory
Component: