SAIF.Application security and authorization

This page documents authorization mechanisms implemented or consumed by this library. Authentication is handled entirely by infrastructure (NTLM/AD) and is not application-level — all code receives a WindowsIdentity on the request context.

Authorization architecture

Authorization is centralized and AD-resource-name-based, delegated to the framework. SAIF.Application does not perform its own AD lookups and does not host or call a WCF SecurityService client directly — it consumes clsSecurityPrincipal.IsAuthorized(resourceName) from the referenced SAIF.BOF.Framework.Security package as the single point of truth for "is this AD resource granted." Two complementary, non-overlapping mechanisms exist in this library: 1. UserAccess — a direct, resource-name-keyed "does the user have this AD resource" check with per-instance caching, intended to be mixed into or inherited by concrete managers that need ad hoc resource checks. 2. AppManagerBase — a role-gating pattern (AppSecurityRole + Mark*/Is* members) intended for whole-object/whole-context accessibility (view-only vs. update vs. no access), driven by the subclass's own OnCheckSecurity() implementation.

No wiring between the two mechanisms is visible in this library.* No MVC [SAIFAuthorize] attributes are present in this library (it contains no MVC controllers/actions).

flowchart TD
    Caller[Concrete AppManagerBase / UserAccess subclass] --> UA[UserAccess.HasAccess/CheckAccess]
    Caller --> AMB[AppManagerBase.OnCheckSecurity]
    UA --> Principal[clsSecurityPrincipal.IsAuthorized]
    AMB --> Role[AppSecurityRole via Mark*/Is* members]
    Principal --> AD[(Active Directory, via SAIF.BOF.Framework.Security)]

AD resource catalog

This library declares no hardcoded AD resource names. It implements a generic, parameterized authorization mechanism whose concrete resource names are supplied entirely by callers (concrete AppManagerBase/UserAccess subclasses in consuming libraries, e.g. SAIF.Application.Claim, SAIF.Application.Claim.Legal — out of scope for this library).

Resource name	Purpose	Enforcement point	Source
(none hardcoded)	UserAccess.HasAccess(inResourceName)/CheckAccess(inResourceName()) accept the AD resource name as a caller-supplied String parameter; no literal resource name (e.g., SecureClaimResource) appears anywhere in this library's source.*	UserAccess.HasAccess / UserAccess.CheckAccess	SAIF.Application\UserAccess.vb

The complete AD resource-name catalog for the application cannot be produced from SAIF.Application alone — it requires analysis of the consuming libraries where concrete resource-name string literals are expected to be supplied.**

Authorization enforcement points

Programmatic authorization checks

Class	Method	Resource / Role	Check type	Source
UserAccess	HasAccess(inResourceName As String) As Boolean	Caller-supplied AD resource name	IsAuthorized (delegated to clsSecurityPrincipal)	SAIF.Application\UserAccess.vb
UserAccess	CheckAccess(ParamArray inResourceName As String())	Caller-supplied AD resource names	IsAuthorized (via HasAccess, result discarded)*	SAIF.Application\UserAccess.vb
AppManagerBase	OnCheckSecurity() (MustOverride)	AppSecurityRole (ViewOnly/Update/NoAccess)	Role-gating (abstract hook implemented by subclass)	SAIF.Application\AppManagerBase.vb
AppManagerBase	IsAccessible / IsRestricted / IsUpdateable / IsViewOnly	AppSecurityRole	Read-only gates derived from SecurityRole	SAIF.Application\AppManagerBase.vb

No attribute-based authorization exists in this library (it contains no MVC controllers/actions), so no "Attribute-based authorization" subsection applies.

Data-level authorization

None found in this library. AppManagerBase exposes a generic ValidContext (Public ReadOnly Property) backed by the abstract OnValidContext() hook and ContextSet/MarkContextSet/MarkContextNotSet state, but no concrete ownership/context-validation logic (e.g., an IsValidPolicyForCurrentUser-style check) is implemented anywhere in this library — the actual validation rule is left entirely to concrete subclasses.*

Segregation of duties

None found. No class or method named *SegregationOfDuties*/*SOD*, and no SQL querying conflicting-privilege tables, exists in this library.

Security interfaces and contracts

Interface / Class	Role	Consumers	Source
clsSecurityPrincipal (external, from SAIF.BOF.Framework.Security)	Single point of truth for AD-resource authorization decisions	AppManagerBase.SecurityPrincipal (Protected), UserAccess's private m_Principal	SAIF.Application\AppManagerBase.vb, SAIF.Application\UserAccess.vb

No local ISecurityManager/IDomainSecurityManager interface, no custom AuthorizeAttribute-derived attribute, and no direct System.DirectoryServices/System.DirectoryServices.AccountManagement usage were found anywhere in this library's source.

Notes

• Two distinct, identically-named AppSecurityRole enum declarations exist (nested in AppManagerBase vs. top-level in Enums.vb); which one downstream consumers reference could not be determined from this library alone.**
• UserAccess.CheckAccess's discarded result means its practical effect (cache warming vs. incomplete implementation) is ambiguous without seeing call sites in consuming libraries.*
• Mark inferred statements with * and unknown statements with **. Do not use bold inline confidence labels.
• AD resource names listed here use base names only. The framework appends Resource (production) or TestResource (non-production) at runtime.

Related documentation

• Index
• Overview
• Architecture
• Dependencies
• Operations and processes
• Business rules
• API reference

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
• SAIF.Application\AppManagerBase.vb
• SAIF.Application\Enums.vb