IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
  • 1.  Fields visibility on person object - in ISIM's request log

    Posted 12 hours ago

    Hello everyone,
    I have a question and I'm looking for advice regarding the following scenario.

    In our environment, we use a custom objectclass for ISIM persons and we use ACIs to restrict attribute visibility for certain users. So far, so good: only the selected attributes are visible and authorized (R or RW).

    Here's the issue: users with lower privileges can still see all attributes (including those that should be hidden from them) by, for example, viewing the "entity" section of a "user data change" request.

    The question is: is there a simple way to control which attributes are exposed in db2 logs to lower-privileged users (who belong to a specific ISIM group)?

    As always, thanks for your valuable suggestions.



    ------------------------------
    Andrea Gatto
    ------------------------------


  • 2.  RE: Fields visibility on person object - in ISIM's request log

    Posted 9 hours ago

    This is a common challenge when working with ISIM and custom objectclasses. While ACIs control attribute visibility in the UI, they do not automatically restrict what appears in workflow-related objects like "entity" sections or logs.

    Unfortunately, there isn't a direct configuration in ISIM to filter attributes in DB2 logs based on user group privileges. Logs are typically system-level and capture full object data for auditing and troubleshooting purposes.

    However, here are a few approaches you can consider:

    1. Workflow Customization:
      Modify the presentation layer or workflow templates so that only authorized attributes are displayed in request details. This ensures lower-privileged users don't see sensitive attributes in the UI.

    2. Attribute Encryption or Masking:
      For highly sensitive attributes, consider encrypting or masking them at the application level so even if they appear in logs, they are not readable.

    3. Custom Logging Policies:
      Implement custom logging or use DB2 exit routines to filter or redact specific attributes before writing to logs. This requires development effort but gives fine-grained control.

    4. Access Control Review:
      Ensure that users who can view workflow requests truly need that level of visibility. Sometimes adjusting roles and responsibilities can reduce exposure.

    Unfortunately, ISIM does not provide an out-of-the-box feature to dynamically filter attributes in DB2 logs based on group membership. It usually requires customization or external masking solutions.



    ------------------------------
    Venkata Sathish Reddy Ambati
    ------------------------------