Extend Condition DSL with Contains and Like operators (list-aware evaluation)

[blindzero]

Problem Statement

The current Condition / Precondition DSL does not provide native support
for evaluating list membership or wildcard matching on resolved context data.

Typical real-world use cases include:

• Execute a step only if the identity is not member of a specific group
• Execute a step only if the identity is not member of any group matching a pattern
• Execute a step only if a string attribute matches a wildcard pattern

Today, these scenarios require host-side boolean flags or workaround logic,
which reduces expressiveness and breaks provider-agnostic design principles.

Proposed Solution

Extend the Condition / Precondition DSL with the following operators:

• Contains
• NotContains
• Like
• NotLike

Semantics

Case-insensitive by default.

Contains / NotContains

• Intended for list membership evaluation
• Path must resolve to a list
• Contains returns true if the list contains the specified value
• NotContains returns true if the list does not contain the specified value

Example:

Condition = @{
  NotContains = @{
    Path  = 'Request.Context.Identity.Entitlements'
    Value = 'CN=BreakGlass-Users,OU=Groups,DC=example,DC=com'
  }
}

Like / NotLike

• Intended for wildcard pattern matching
• If Path resolves to:
  • Scalar → evaluate normally
  • List → evaluate true if any element matches the pattern

Example (list evaluation):

Condition = @{
  NotLike = @{
    Path    = 'Request.Context.Identity.Entitlements'
    Pattern = 'CN=HR-*'
  }
}

Example (scalar evaluation):

Condition = @{
  Like = @{
    Path    = 'Request.Context.Identity.Profile.DisplayName'
    Pattern = '* (Contractor)'
  }
}

Design Principles

• All, Any, and None remain logical combinators (AND / OR / NOT)
• No new logical operators introduced
• No provider changes required
• Fail-fast if:
  • Contains used on scalar
  • Invalid Path
  • Missing Value/Pattern

Applies to

• Condition
• Preconditions

Alternatives Considered

Introduce dedicated operators such as AnyLike

Rejected because:

• Any is a logical combinator (OR), not a comparison operator
• Overloading it would break DSL consistency
• Adds unnecessary surface area

Host-side boolean flags

Rejected because:

• Breaks provider-agnostic workflow design
• Pushes logic outside DSL
• Reduces readability and maintainability

Impact

• Does not affect existing workflows
• No breaking changes
• Pure additive DSL extension

Backward compatibility: fully preserved.

Additional Context

This enhancement improves common enterprise scenarios:

• Joiner / Mover / Leaver group-guard logic
• Conditional entitlement pruning
• Pattern-based exclusion rules
• Safer destructive step gating

Documentation updates required:

• Conditions page (new operators section)
• Preconditions page (reference section)
• Common Patterns examples
• Explicit note: Contains only valid for lists, Like supports scalar and list paths