Implement enterprise application identity and OAuth security rules

Objective

Implement the Azure Entra application identity and OAuth security rule pack with evidence-backed findings and conservative handling of incomplete Microsoft Graph data.

Scope

Implement these controls:

1. An application has high-risk Microsoft Graph permissions.
2. An application has tenant-wide admin consent without approved justification.
3. An unverified publisher application has privileged permissions.
4. Application credentials have an excessive validity period.
5. An application contains multiple active secrets without documented need.
6. A stale application retains credentials or privileged permissions.
7. A service principal allows access without required user assignment.
8. A federated identity credential uses an overly broad subject or trust condition.
9. An application permits public-client authentication unnecessarily.
10. Application ownership contains inactive, guest, or unsuitable accounts.

Collection architecture

• Microsoft Graph applications and service principals.
• Microsoft Graph owners, directory roles, app-role assignments, delegated permissions, and admin consent.
• Application passwords, certificates, federated identity credentials, publisher verification, and account status.
• Tenant policy and documented exception metadata where required.

Required implementation behavior

• Use paginated collectors and preserve resource identifiers and tenant context.
• Return NOT_APPLICABLE when an application, credential type, or feature is absent.
• Return UNKNOWN for permission failures, API errors, partial inventory, or ambiguous ownership.
• Return FAIL only when unsafe configuration is positively evidenced.
• Never expose secret values.
• Include observed/expected state, evidence source and collection time, remediation, required permissions, severity, confidence, and UNKNOWN reason.

Delivery order

1. Permissions, admin consent, publisher, and user-assignment rules.
2. Credential age, duplicate-secret, stale-application, and ownership rules.
3. Federated credential trust and public-client authentication rules.

Acceptance criteria

• Every rule has collector, evaluator, remediation, documentation, and verified mappings.
• Tests cover compliant, non-compliant, empty, paginated, malformed, stale, missing-owner, duplicate-credential, permission-failure, and API-failure cases.
• No API or authorization error creates a false PASS or FAIL.
• No TBD framework mappings remain.
• Scanner, serialization, compliance scoring, and CI-equivalent tests pass.
• An origin-branch PR references this issue.