---
title: Legacy resource access validation
summary: Evaluates resource access through the legacy ASMX AD service variants.
status: draft
owner: <owner>
last_reviewed: 2026-07-30
library: SAIF.Framework.Security
reference_type: package
operation_id: OP-006
trigger: Caller invokes a `ResourceAccessValid*` method
---

# Legacy resource access validation

This operation exists for callers that have not yet migrated to the WCF `SecurityService` path: it authorizes a resource request through the older ASMX `clsADServices` web service instead, using its own (different) environment-suffix convention. `clsAccountMaintProxy` exposes four near-identical entry points — internal vs. external domain, cached vs. uncached — that all funnel through this same logic.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-006 |
| **Trigger** | Caller invokes a `ResourceAccessValid*` method |
| **Inputs** | Mail ID and base resource name |
| **Outputs** | Boolean authorization decision |
| **Primary components** | `clsAccountMaintProxy.ResourceAccessValid`, `ResourceAccessValidCached`, `ResourceAccessValidExternal`, `ResourceAccessValidCachedExternal`, `GetADService` |
| **Entry point** | `SAIF.Framework.Security\clsAccountMaintProxy.vb` |

## Steps

1. Whichever public method the caller invokes first resolves a fresh `clsADServices` proxy through `GetADService()`, which reads `legacyADServiceUrl` from the environment service and assigns it as the proxy's endpoint — a new proxy is created on every call, with no reuse or caching.
2. The entry point the caller chose then determines which underlying ASMX operation to invoke: `HasAccess` (internal, uncached), `HasAccessCache` (internal, cached), `HasAccessExternal`, or `HasAccessCacheExternal`.
   - Authorization context: these four operations are the programmatic checks listed in [Programmatic authorization checks](../security-authorization.md#programmatic-authorization-checks).
3. When the application is not running in production, the method appends a plain `Test` suffix to the resource name before making the ASMX request; production calls send the base resource name unchanged — enforcing [BR-002](../business-rules.md#br-002-legacy-asmx-resource-checks-use-a-plain-test-suffix), a convention that differs from the `TestResource` suffix used by the WCF path.
4. The method returns the boolean result from the selected ASMX operation directly, with no local post-processing.
   - On failure: ASMX endpoint or transport exceptions are not caught locally and propagate to the caller.

## Process flow

The following diagram visualizes this operation's control flow.

```mermaid
flowchart TD
	Start([Legacy check requested]) --> Proxy[Create clsADServices proxy]
	Proxy --> Variant[Select access method variant]
	Variant --> Env{Production?}
	Env -->|Yes| CallProd[Call with base resource]
	Env -->|No| CallTest[Append Test and call]
	CallProd --> Decision{Authorized?}
	CallTest --> Decision
	Decision -->|Yes| EndOk([Return True])
	Decision -->|No| EndErr([Return False])
```

## Failure and edge-case behavior

- Every request creates a new ASMX proxy instance rather than reusing a cached client.
- Non-production requests use the legacy plain `Test` suffix, not the `TestResource` suffix applied by the WCF-based resource check.
- Service failures propagate unchanged to the caller.

## Related documentation
- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [Security and authorization](../security-authorization.md)

## Sources
- `SAIF.Framework.Security\clsAccountMaintProxy.vb`