Best Practice for Referencing User Stores in Authentication Rule Conditions (Object ID vs. String Name)
search cancel

Best Practice for Referencing User Stores in Authentication Rule Conditions (Object ID vs. String Name)

book

Article ID: 446118

calendar_today

Updated On:

Products

Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Issue/Introduction

When automating or configuring Identity Security Platform policies, administrators may notice that user conditions within an authentication rule can occasionally accept either a String Name or a specific Object ID (UUID) for a user store.

This article outlines the preferred approach for referencing user stores in authentication rules to ensure configuration stability, consistency, and alignment with the rule engine parser.

Environment

Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Resolution

The recommended and supported approach is to always use the Object ID (UUID) when configuring user store references within authentication rule conditions.

While using a String Name may appear to offer an abstraction layer or alias protection, it introduces structural vulnerabilities. The Object ID should be used due to the following system behaviors:

  1. No True Runtime Alias Protection: The rule condition engine resolves configurations at configuration time, not at runtime. If a user store object is deleted and recreated, it will be assigned a brand new UUID. Even if the recreated user store retains the exact same String Name, the authentication rule reference will break. You must update the reference regardless of whether a name or an ID was used.

  2. Ambiguity and Risk of Renaming: Object IDs (UUIDs) are globally unique and unambiguous. String Names, however, can be duplicated across different contexts or renamed by other administrators, which can inadvertently break authentication rules without warning.

  3. Rule Condition Parser Limitations: The authentication rule condition parser is designed to strictly accept the canonical Object ID format. While the API lookup endpoints may allow short name queries, the rule condition parser itself does not utilize a dynamic name resolver at execution time. Relying on String Names in conditions can lead to parsing errors or evaluation failures.

Recommended Automation / Configuration Pattern

To maintain robust automation scripts and ensure you are always injecting the correct, canonical identifier into your authentication policy rules, utilize the following multi-step workflow:

  1. Query the User Store by Name: Perform a GET request to the administrative endpoint filtering by the desired user store name.

    HTTP
     
    GET /admin/v1/UserStores?name=Your+User+Store+Name
    
  2. Extract the Object ID: Parse the JSON response from the API and extract the unique .id field (UUID) associated with that user store.

  3. Apply the UUID to the Rule: Inject the extracted UUID into the user condition payload of your authentication rule configuration.