* fix(iam): scope IAM-managed OIDC provider lookup by role account Two account-scoped OIDC records sharing an issuer were collapsed into a single map slot keyed only by the URL. The last-write-wins entry then served every AssumeRoleWithWebIdentity, so a token destined for account B's role could be validated by account A's record (its clientIDs and thumbprints), defeating the per-account isolation the records exist for. The role-account check in enforceProviderAccountScope still rejected the cross-account assumption, but only after the wrong record's audience and TLS pin had already accepted the token. Refresh now keys IAM-managed records as (issuer, account), and validation parses the requested role's account up front and matches the record under that issuer in this order: exact account, global (account-less), static-config fallback. An unknown account hint deliberately skips account-scoped entries — picking one arbitrarily is the bug this commit fixes — and falls through to global or static. * fix(iam): route public AssumeRoleWithWebIdentity through IAMManager handleAssumeRoleWithWebIdentity called stsService.AssumeRoleWithWebIdentity directly, bypassing the IAMManager wrapper. The wrapper is where enforceProviderAccountScope rejects cross-account assumption attempts and capDurationByRole clamps to the role's MaxSessionDuration; both silently became no-ops for any AWS-SDK caller hitting the public endpoint. Dispatch through the IAMManager (via the existing IAMManagerProvider interface that other handlers in this file already use) when one is wired. Embedded test setups without an IAM integration fall back to the bare STS service unchanged. * fix(iam): mirror thumbprints, principal-tag keys, and policy claim from static OIDC config initOIDCProviderStore mirrored only URL and ClientIDs. Once RefreshOIDCProvidersFromStore ran (on any IAM-managed mutation, or on boot once the metadata-subscribe loop kicked in), buildOIDCProviderFromRecord rebuilt the runtime provider from this truncated record. Because IAM-managed entries take precedence over the static-config map, the rebuild silently shadowed the bootstrap with a weaker provider: - Thumbprints: dropped, so TLS-pinned issuers fell back to the system trust store. - AllowedPrincipalTagKeys: dropped, so principal-tag claims stopped reaching the session. - PolicyClaim: dropped, so claim-based policy mode stopped triggering. Pull all three from the provider's static Config map at mirror time so the stored record round-trips to a runtime provider equivalent to the one the static config produced directly. * fix(iam): allow empty RoleArn in AssumeRoleWithWebIdentity HTTP handler Phase 3b advertises that RoleArn MAY be omitted in claim-based policy mode — the STS service then derives the assumed-role ARN from the configured policy claim. The HTTP handler still rejected empty RoleArn up front with MissingParameter, so SDK callers using the documented omitted-role flow never reached the STS layer. Drop the pre-check; STS still validates that claim-based mode is configured and that the IDP emits policies, returning a precise error when either is missing. The existing error mapping below this point surfaces those as InvalidParameterValue, matching what an AWS SDK expects. * test(iam): update missing-RoleArn STS integration test for the new contract The previous commit drops the HTTP-layer RoleArn pre-check so claim-based mode can derive the ARN from a JWT claim. The integration test still asserted MissingParameter for the missing-RoleArn case, which now reaches the STS layer and surfaces a JWT-parse error instead. Update the assertion to match: missing RoleArn alone must no longer surface as MissingParameter, but a bogus JWT must still be rejected.
SeaweedFS S3 IAM Integration Tests
This directory contains comprehensive integration tests for the SeaweedFS S3 API with Advanced IAM (Identity and Access Management) system integration.
Overview
Important: The STS service uses a stateless JWT design where all session information is embedded directly in the JWT token. No external session storage is required.
The S3 IAM integration tests validate the complete end-to-end functionality of:
- JWT Authentication: OIDC token-based authentication with S3 API
- Policy Enforcement: Fine-grained access control for S3 operations
- Stateless Session Management: JWT-based session token validation and expiration (no external storage)
- Role-Based Access Control (RBAC): IAM roles with different permission levels
- Bucket Policies: Resource-based access control integration
- Multipart Upload IAM: Policy enforcement for multipart operations
- Contextual Policies: IP-based, time-based, and conditional access control
- Presigned URLs: IAM-integrated temporary access URL generation
Test Architecture
Components Tested
- S3 API Gateway - SeaweedFS S3-compatible API server with IAM integration
- IAM Manager - Core IAM orchestration and policy evaluation
- STS Service - Security Token Service for temporary credentials
- Policy Engine - AWS IAM-compatible policy evaluation
- Identity Providers - OIDC and LDAP authentication providers
- Policy Store - Persistent policy storage using SeaweedFS filer
Test Framework
- S3IAMTestFramework: Comprehensive test utilities and setup
- Mock OIDC Provider: In-memory OIDC server with JWT signing
- Service Management: Automatic SeaweedFS service lifecycle management
- Resource Cleanup: Automatic cleanup of buckets and test data
Test Scenarios
1. Authentication Tests (TestS3IAMAuthentication)
- ✅ Valid JWT Token: Successful authentication with proper OIDC tokens
- ✅ Invalid JWT Token: Rejection of malformed or invalid tokens
- ✅ Expired JWT Token: Proper handling of expired authentication tokens
2. Policy Enforcement Tests (TestS3IAMPolicyEnforcement)
- ✅ Read-Only Policy: Users can only read objects and list buckets
- ✅ Write-Only Policy: Users can only create/delete objects but not read
- ✅ Admin Policy: Full access to all S3 operations including bucket management
3. Session Expiration Tests (TestS3IAMSessionExpiration)
- ✅ Short-Lived Sessions: Creation and validation of time-limited sessions
- ✅ Manual Expiration: Testing session expiration enforcement
- ✅ Expired Session Rejection: Proper access denial for expired sessions
4. Multipart Upload Tests (TestS3IAMMultipartUploadPolicyEnforcement)
- ✅ Admin Multipart Access: Full multipart upload capabilities
- ✅ Read-Only Denial: Rejection of multipart operations for read-only users
- ✅ Complete Upload Flow: Initiate → Upload Parts → Complete workflow
5. Bucket Policy Tests (TestS3IAMBucketPolicyIntegration)
- ✅ Public Read Policy: Bucket-level policies allowing public access
- ✅ Explicit Deny Policy: Bucket policies that override IAM permissions
- ✅ Policy CRUD Operations: Get/Put/Delete bucket policy operations
6. Contextual Policy Tests (TestS3IAMContextualPolicyEnforcement)
- 🔧 IP-Based Restrictions: Source IP validation in policy conditions
- 🔧 Time-Based Restrictions: Temporal access control policies
- 🔧 User-Agent Restrictions: Request context-based policy evaluation
7. Presigned URL Tests (TestS3IAMPresignedURLIntegration)
- ✅ URL Generation: IAM-validated presigned URL creation
- ✅ Permission Validation: Ensuring users have required permissions
- 🔧 HTTP Request Testing: Direct HTTP calls to presigned URLs
Quick Start
Prerequisites
- Go 1.19+ with modules enabled
- SeaweedFS Binary (
weed) built with IAM support - Test Dependencies:
go get github.com/stretchr/testify go get github.com/aws/aws-sdk-go go get github.com/golang-jwt/jwt/v5
Running Tests
Complete Test Suite
# Run all tests with service management
make test
# Quick test run (assumes services running)
make test-quick
Specific Test Categories
# Test only authentication
make test-auth
# Test only policy enforcement
make test-policy
# Test only session expiration
make test-expiration
# Test only multipart uploads
make test-multipart
# Test only bucket policies
make test-bucket-policy
Development & Debugging
# Start services and keep running
make debug
# Show service logs
make logs
# Check service status
make status
# Watch for changes and re-run tests
make watch
Manual Service Management
If you prefer to manage services manually:
# Start services
make start-services
# Wait for services to be ready
make wait-for-services
# Run tests
make run-tests
# Stop services
make stop-services
Configuration
Test Configuration (test_config.json)
The test configuration defines:
- Identity Providers: OIDC and LDAP configurations
- IAM Roles: Role definitions with trust policies
- IAM Policies: Permission policies for different access levels
- Policy Stores: Persistent storage configurations for IAM policies and roles
Service Ports
| Service | Port | Purpose |
|---|---|---|
| Master | 9333 | Cluster coordination |
| Volume | 8080 | Object storage |
| Filer | 8888 | Metadata & IAM storage |
| S3 API | 8333 | S3-compatible API with IAM |
Environment Variables
# SeaweedFS binary location
export WEED_BINARY=../../../weed
# Service ports (optional)
export S3_PORT=8333
export FILER_PORT=8888
export MASTER_PORT=9333
export VOLUME_PORT=8080
# Test timeout
export TEST_TIMEOUT=30m
# Log level (0-4)
export LOG_LEVEL=2
Test Data & Cleanup
Automatic Cleanup
The test framework automatically:
- 🗑️ Deletes test buckets created during tests
- 🗑️ Removes test objects and multipart uploads
- 🗑️ Cleans up IAM sessions and temporary tokens
- 🗑️ Stops services after test completion
Manual Cleanup
# Clean everything
make clean
# Clean while keeping services running
rm -rf test-volume-data/
Extending Tests
Adding New Test Scenarios
-
Create Test Function:
func TestS3IAMNewFeature(t *testing.T) { framework := NewS3IAMTestFramework(t) defer framework.Cleanup() // Test implementation } -
Use Test Framework:
// Create authenticated S3 client s3Client, err := framework.CreateS3ClientWithJWT("user", "TestRole") require.NoError(t, err) // Test S3 operations err = framework.CreateBucket(s3Client, "test-bucket") require.NoError(t, err) -
Add to Makefile:
test-new-feature: ## Test new feature go test -v -run TestS3IAMNewFeature ./...
Creating Custom Policies
Add policies to test_config.json:
{
"policies": {
"CustomPolicy": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::specific-bucket/*"],
"Condition": {
"StringEquals": {
"s3:prefix": ["allowed-prefix/"]
}
}
}
]
}
}
}
Adding Identity Providers
-
Mock Provider Setup:
// In test framework func (f *S3IAMTestFramework) setupCustomProvider() { provider := custom.NewCustomProvider("test-custom") // Configure and register } -
Configuration:
{ "providers": { "custom": { "test-custom": { "endpoint": "http://localhost:8080", "clientId": "custom-client" } } } }
Troubleshooting
Common Issues
1. Services Not Starting
# Check if ports are available
netstat -an | grep -E "(8333|8888|9333|8080)"
# Check service logs
make logs
# Try different ports
export S3_PORT=18333
make start-services
2. JWT Token Issues
# Verify OIDC mock server
curl http://localhost:8080/.well-known/openid_configuration
# Check JWT token format in logs
make logs | grep -i jwt
3. Permission Denied Errors
# Verify IAM configuration
cat test_config.json | jq '.policies'
# Check policy evaluation in logs
export LOG_LEVEL=4
make start-services
4. Test Timeouts
# Increase timeout
export TEST_TIMEOUT=60m
make test
# Run individual tests
make test-auth
Debug Mode
Start services in debug mode to inspect manually:
# Start and keep running
make debug
# In another terminal, run specific operations
aws s3 ls --endpoint-url http://localhost:8333
# Stop when done (Ctrl+C in debug terminal)
Log Analysis
# Service-specific logs
tail -f weed-s3.log # S3 API server
tail -f weed-filer.log # Filer (IAM storage)
tail -f weed-master.log # Master server
tail -f weed-volume.log # Volume server
# Filter for IAM-related logs
make logs | grep -i iam
make logs | grep -i jwt
make logs | grep -i policy
Performance Testing
Benchmarks
# Run performance benchmarks
make benchmark
# Profile memory usage
go test -bench=. -memprofile=mem.prof
go tool pprof mem.prof
Load Testing
For load testing with IAM:
-
Create Multiple Clients:
// Generate multiple JWT tokens tokens := framework.GenerateMultipleJWTTokens(100) // Create concurrent clients var wg sync.WaitGroup for _, token := range tokens { wg.Add(1) go func(token string) { defer wg.Done() // Perform S3 operations }(token) } wg.Wait() -
Measure Performance:
# Run with verbose output go test -v -bench=BenchmarkS3IAMOperations
CI/CD Integration
GitHub Actions
name: S3 IAM Integration Tests
on: [push, pull_request]
jobs:
s3-iam-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-go@v3
with:
go-version: '1.19'
- name: Build SeaweedFS
run: go build -o weed ./main.go
- name: Run S3 IAM Tests
run: |
cd test/s3/iam
make ci
Jenkins Pipeline
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'go build -o weed ./main.go'
}
}
stage('S3 IAM Tests') {
steps {
dir('test/s3/iam') {
sh 'make ci'
}
}
post {
always {
dir('test/s3/iam') {
sh 'make clean'
}
}
}
}
}
}
Contributing
Adding New Tests
-
Follow Test Patterns:
- Use
S3IAMTestFrameworkfor setup - Include cleanup with
defer framework.Cleanup() - Use descriptive test names and subtests
- Assert both success and failure cases
- Use
-
Update Documentation:
- Add test descriptions to this README
- Include Makefile targets for new test categories
- Document any new configuration options
-
Ensure Test Reliability:
- Tests should be deterministic and repeatable
- Include proper error handling and assertions
- Use appropriate timeouts for async operations
Code Style
- Follow standard Go testing conventions
- Use
require.NoError()for critical assertions - Use
assert.Equal()for value comparisons - Include descriptive error messages in assertions
Support
For issues with S3 IAM integration tests:
- Check Logs: Use
make logsto inspect service logs - Verify Configuration: Ensure
test_config.jsonis correct - Test Services: Run
make statusto check service health - Clean Environment: Try
make clean && make test
License
This test suite is part of the SeaweedFS project and follows the same licensing terms.