mirror of
https://github.com/norandom/OpenUltraSAST.git
synced 2026-10-21 05:59:29 +00:00
chore: add kiro spec-driven tooling and steering docs
Add the Kiro-style agentic SDLC tooling used to drive this project: the .opencode/skills/kiro-* skill set (discovery, spec init/requirements/design/ tasks, validation, implementation, review, steering), the .kiro/settings templates, and AGENTS.md describing the workflow. Update the spec docs (assessment/design/requirements/tasks) to current state. Scope tests/test_opencode_skills.py to the project's own openultrasast-* skills so the third-party kiro-* tooling (which uses a different frontmatter convention) no longer breaks the frontmatter check. Co-Authored-By: Claude Opus 4.8 <[email protected]>
This commit is contained in:
co-authored by
Claude Opus 4.8
parent
8fe8911020
commit
6699f1f8f9
@@ -0,0 +1,67 @@
|
||||
# Authentication & Authorization Standards
|
||||
|
||||
[Purpose: unify auth model, token/session lifecycle, permission checks, and security]
|
||||
|
||||
## Philosophy
|
||||
- Clear separation: authentication (who) vs authorization (what)
|
||||
- Secure by default: least privilege, fail closed, short-lived tokens
|
||||
- UX-aware: friction where risk is high, smooth otherwise
|
||||
|
||||
## Authentication
|
||||
|
||||
### Method (choose + rationale)
|
||||
- Options: JWT, Session, OAuth2, hybrid
|
||||
- Choice: [our method] because [reason]
|
||||
|
||||
### Flow (high-level)
|
||||
```
|
||||
1) User proves identity (credentials or provider)
|
||||
2) Server verifies and issues token/session
|
||||
3) Client sends token per request
|
||||
4) Server verifies token and proceeds
|
||||
```
|
||||
|
||||
### Token/Session Lifecycle
|
||||
- Storage: httpOnly cookie or Authorization header
|
||||
- Expiration: short-lived access, longer refresh (if used)
|
||||
- Refresh: rotate tokens; respect revocation
|
||||
- Revocation: blacklist/rotate on logout/compromise
|
||||
|
||||
### Security Pattern
|
||||
- Enforce TLS; never expose tokens to JS when avoidable
|
||||
- Bind token to audience/issuer; include minimal claims
|
||||
- Consider device binding and IP/risk checks for sensitive actions
|
||||
|
||||
## Authorization
|
||||
|
||||
### Permission Model
|
||||
- Choose one: RBAC / ABAC / ownership-based / hybrid
|
||||
- Define roles/attributes centrally; avoid hardcoding across codebase
|
||||
|
||||
### Checks (where to enforce)
|
||||
- Route/middleware: coarse-grained gate
|
||||
- Domain/service: fine-grained decisions
|
||||
- UI: conditional rendering (no security reliance)
|
||||
|
||||
Example pattern:
|
||||
```typescript
|
||||
requirePermission('resource:action'); // route
|
||||
if (!user.can('resource:action')) throw ForbiddenError(); // domain
|
||||
```
|
||||
|
||||
### Ownership
|
||||
- Pattern: owner OR privileged role can act
|
||||
- Verify on entity boundary before mutation
|
||||
|
||||
## Passwords & MFA
|
||||
- Passwords: strong policy, hashed (bcrypt/argon2), never plaintext
|
||||
- Reset: time-limited token, single-use, notify user
|
||||
- MFA: step-up for risky operations (policy-driven)
|
||||
|
||||
## API-to-API Auth
|
||||
- Use API keys or OAuth client credentials
|
||||
- Scope keys minimally; rotate and audit usage
|
||||
- Rate limit by identity (user/key)
|
||||
|
||||
---
|
||||
_Focus on patterns and decisions. No library-specific code._
|
||||
Reference in New Issue
Block a user