Skip to content

Check and cache AD resource authorization

This operation checks whether the current security principal is authorized for a caller-supplied AD resource name and caches the result for the life of the UserAccess-derived instance.

Field Value
Operation ID OP-APP-003
Trigger Concrete subclass of UserAccess calls HasAccess(inResourceName) or CheckAccess(ParamArray inResourceName As String())
Inputs inResourceName (string), an associated clsSecurityPrincipal (set via SetPrincipal)
Outputs Cached boolean authorization result
Primary components UserAccess.HasAccess, UserAccess.CheckAccess, UserAccess.SetPrincipal
Entry point SAIF.Application\UserAccess.vb

Steps

  1. Concrete subclass of UserAccess calls the protected SetPrincipal(inPrincipal) to associate a clsSecurityPrincipal. No business rule is enforced at this step and no SQL/table access occurs.
  2. Caller invokes HasAccess(inResourceName). If the resource name (lower-cased) is already present in the internal m_AccessControl cache, the cached boolean is returned immediately — no re-authorization call is made (BR-APP-003).
  3. If not cached: the method delegates to clsSecurityPrincipal.IsAuthorized(inResourceName) (from SAIF.BOF.Framework) to obtain the authorization result, caches it in m_AccessControl, and returns it.

Origin: The actual AD-resource lookup is implemented in clsSecurityPrincipal.IsAuthorized (SAIF.BOF.Framework.Security). The framework's own IsAuthorized operation sequence was not resolved via RAG for this run and is not traced further here.** 3. CheckAccess(ParamArray inResourceName As String()) iterates the supplied resource names and calls HasAccess for each, but immediately discards the per-call boolean result into a local Result variable that is then reset to Nothing and never read or returned. - This method has no observable external effect beyond populating the HasAccess cache as a side effect; this appears to be dead/ineffective logic in its current form as written.*

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Caller invokes HasAccess or CheckAccess]) --> S1[SetPrincipal associates clsSecurityPrincipal]
    S1 --> S2{Resource name cached?}
    S2 -->|Yes| S3[Return cached boolean]
    S2 -->|No| S4[Call clsSecurityPrincipal.IsAuthorized]
    S4 --> S5[Cache result in m_AccessControl]
    S5 --> S3
    S3 --> EndOk([Authorization result available])

Failure and edge-case behavior

  • CheckAccess's discarded Result variable means its only observable outcome is warming the HasAccess cache; it is unclear whether this is intentional cache pre-warming or a leftover/incomplete implementation.*
  • A cached HasAccess result could be stale if the underlying AD membership changes during the instance's lifetime.*

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts. Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • SAIF.Application\UserAccess.vb