This page documents the application-wide authorization architecture for Claims Legal, consolidating authorization patterns from all analyzed libraries and the front-end layer. Authentication is handled entirely by infrastructure (NTLM/AD) and is not application-level — all code receives a WindowsIdentity/clsSecurityPrincipal on the request context.
Authentication is handled entirely by infrastructure and is not part of application code. All requests arrive with an identity established by IIS (internal users via NTLM/Kerberos); no MVC controllers, [SAIFAuthorize]/[SaifAuthorize] attributes, or System.DirectoryServices/System.DirectoryServices.AccountManagement usage were found in any of the five analyzed libraries. The application has no code for the authentication mechanism itself.
Claims Legal's authorization is exclusively programmatic and layered: a generic, parameterized resource-name check (UserAccess.HasAccess, defined in SAIF.Application) is the single mechanism through which every higher layer resolves "does this user hold AD resource X." SAIF.Application.Claim and SAIF.Application.Claim.Legal build claim-level and case-level composite checks on top of that mechanism, combining AD resource membership with claim/case entity attributes (conflict, exposure, hostile-worker flags). SAIF.Business.View.Policy layers a similar composite check for policy-level access, and SAIF.Presentation.Web.Controls.PopUps.Infragistics111 applies claim/image checks inside shared popup controls. No WCF SecurityService client code is visible in any of the five analyzed libraries; the underlying AD group membership resolution is delegated to the external clsSecurityPrincipal type (SAIF.BOF.Framework.Security), outside this repository's scope.*
flowchart TD
User[User request] --> Identity[WindowsIdentity established by IIS/NTLM]
Identity --> Principal[clsSecurityPrincipal injected into managers]
Principal --> UA["UserAccess.HasAccess(resourceName)"]
UA --> Cache{Cached?}
Cache -->|Yes| Result[Cached access decision]
Cache -->|No| Framework["clsSecurityPrincipal.IsAuthorized(resourceName)"]
Framework --> AD[(Active Directory)]
Framework --> Result
Result --> Claim[ClaimSecurity.CheckClaim composite check]
Claim --> Legal[LegalManagerBase.OnRetrieve composite gate]
Result --> Policy[clsPolicySecurity.IsPolicyValidForUser]
Result --> Popup[ImageMovePopup.CheckClaimSecurity / CheckImageSecurity]
Gates access to "secure" SAIF-owned policies (SecurePolicyCode = clsConstants.SAIF); denies access to any user lacking this resource, regardless of user type.
SEC-APP-001 Confidential claim access requires resource membership or override¶
Field
Value
Statement
Claims flagged as worker-conflict or exposure claims are hidden from users who lack the corresponding AD resource, unless an explicit security override succeeds.
Trigger
A claim with IsWorkerConflict or IsExposure set is loaded through ClaimAppManager or a legal case is opened through LegalManagerBase.
Enforcement
ClaimAppManager.OnCheckSecurity() calls MarkNoAccess() unless ClaimSecurity.ConflictAccess (from ConflictClaim) is true or CheckForSecurityOverride() succeeds; LegalManagerBase.OnRetrieve() applies an equivalent gate combining LNConflict/LNExposure with an LNAdmin bypass.
SEC-APP-002 Admin and case-update roles govern note edit delete rights¶
Field
Value
Statement
Full note edit and delete rights require LNAdmin or LNCaseUpdate; non-privileged users may only edit bill (DOCCO category) notes via LNUpdate; notes created by SYSTEM cannot be deleted by any user.
Trigger
A user attempts to edit or delete a case note in clsCaseNotesManager.
Deletion/edit attempts outside the allowed role/category combination are rejected.
Related resources
LNAdmin, LNCaseUpdate, LNUpdate, LNNoteView
SEC-APP-003 Secure SAIF-owned policies require the SAIFpolicyInfo resource¶
Field
Value
Statement
Any user, regardless of user type, is denied access to a policy flagged as "secure" (SecurePolicyCode = clsConstants.SAIF) unless they hold the SAIFpolicyInfo AD resource.
Trigger
A screen requests policy or policyholder data through clsPolicySecurity.IsPolicyValidForUser.
Enforcement
clsPolicySecurity.IsPolicyValidForUser runs a data-level, policy-scoped SAIFpolicyInfo override check before applying the per-user-type ownership/scope rule.
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.