Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 14:46:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Adopt 11 community rules into custom always-on layer

Browse source 
Promotes rules that are already published in community/ to custom/knowledge/,
so they load at every session start instead of only on keyword relevance.
Each file carries extends: pointing back to its community source.

Passed Immanuel's four-test Categorical Imperative validation on 2026-08-07.
This commit is contained in:
Michael Dieringer 2026-08-07 08:04:12 +02:00
parent b79b90c4ec
commit d4e351f333
11 changed files with 231 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

21
custom/knowledge/security/prefer-oauth2-over-api-keys-for-external-http-calls.md Normal file
View file

@ -0,0 +1,21 @@
---
bc-version: [all]
domain: security
keywords: [oauth2, api-key, authentication, httpclient, token-refresh]
technologies: [al]
countries: [w1]
application-area: [all]
extends: community/security/prefer-oauth2-over-api-keys-for-external-http-calls.md
---
# Prefer OAuth2 Over API Keys For External HTTP Calls
> Contributions welcome — open a PR to refine or extend this article.
## Description
External HTTP integrations from AL can authenticate using OAuth 2.0 (client-credentials for service-to-service, authorization-code for user-delegated), API keys, basic authentication, or credentials in URLs. The mechanisms differ substantially in the blast radius of a leaked secret and in how cleanly tokens can be rotated. OAuth-issued tokens expire on their own schedule and rotate cleanly; API keys and basic-auth passwords typically have to be rotated manually and usually live unencrypted in a configuration table. When the partner supports OAuth, the difference is a material security improvement, not a stylistic preference.
## Best Practice
When the partner supports OAuth, use the platform `OAuth2` codeunit (`AcquireTokenWithClientCredentials` for service-to-service, `AcquireAuthorizationCodeTokenFromCache` for user-delegated flows) rather than hand-rolled token acquisition. Carry tokens and client secrets as `SecretText`, persist them only in IsolatedStorage (see `secrets-isolated-storage`), and refresh tokens proactively — on a buffer before the documented expiry — so routine calls never block on a token refresh.
## Anti Pattern
Accepting an API-key or basic-auth integration because it is the first option documented, even when the partner supports OAuth. The shared secret usually ends up in a setup-table `Text` field, rotation becomes a manual operation that rarely happens, and a single disclosure exposes every tenant using the extension.

21
custom/knowledge/security/secrets-isolated-storage.md Normal file
View file

@ -0,0 +1,21 @@
---
bc-version: [all]
domain: security
keywords: [isolatedstorage, secrets, api-key, oauth-token, connection-string, table-field, credentials]
technologies: [al]
countries: [w1]
application-area: [all]
extends: community/security/secrets-isolated-storage.md
---
# A Secret Belongs In IsolatedStorage, Never In A Table Field
> Contributions welcome — open a PR to refine or extend this article.
## Description
API keys, OAuth tokens, client secrets, and connection strings must not be stored in an ordinary table `Text` field — not even on a hidden setup table. A regular field is exposed through record reads, page display, RapidStart and Excel export, report datasets, and surfaces in `DataClassification` review; anyone with table permission can read it. The correct home is `IsolatedStorage`, which is invisible to database queries, API pages, and configuration packages. The storage-*location* decision is the rule here; how to scope and encrypt the value once it is in IsolatedStorage is covered separately.
## Best Practice
Persist every credential with `IsolatedStorage`, write it at the point of capture, and read it only when needed. For the per-secret details — choosing the right `DataScope`, encrypting at rest, and typing the value as `SecretText` so it cannot leak into logs — follow the companion rules on IsolatedStorage `DataScope`, `SetEncrypted`, and `SecretText`.
## Anti Pattern
A "Setup" or "Connection" table carrying a `Text` field named `API Key`, `Password`, or `Client Secret`. The value is now readable by any object with table permission, ships in RapidStart packages and Excel exports, and appears in record snapshots — a credential disclosure that no amount of encryption-in-transit elsewhere makes up for. Reviewer signal: a secret-shaped field declared on a table instead of an `IsolatedStorage` call.