Chapter 6: Phase 3 - Protocol

Phase 3 of WIA-ACS establishes secure communication protocols ensuring end-to-end encryption, authentication, and integrity for all access control operations. This chapter covers TLS 1.3 for transport security, OAuth 2.0 and OpenID Connect for authorization and authentication, SAML 2.0 for enterprise single sign-on, and certificate management practices. These protocols form the security backbone of WIA-ACS deployments.

Transport Layer Security (TLS 1.3)

All WIA-ACS communications must use TLS 1.3 or later for encryption and integrity. TLS 1.3 provides significant security and performance improvements over earlier versions:

Feature	TLS 1.2	TLS 1.3	Benefit
Handshake Round Trips	2-RTT	1-RTT (0-RTT resume)	Faster connection establishment
Cipher Suites	37 options	5 strong options	Eliminate weak ciphers
Perfect Forward Secrecy	Optional	Mandatory	Past sessions remain secure if key compromised
Encrypted Handshake	Partial	Complete	Prevent metadata leakage
Removed Features	N/A	RSA key exchange, SHA-1, MD5	Eliminate known vulnerabilities

Required Cipher Suites

WIA-ACS Mandatory Cipher Suites (in order of preference):

1. TLS_AES_256_GCM_SHA384
   - AES-256 encryption with GCM mode
   - SHA-384 for HMAC
   - Strong security for highly sensitive data

2. TLS_CHACHA20_POLY1305_SHA256
   - ChaCha20 stream cipher
   - Poly1305 authenticator
   - Faster on mobile/embedded devices

3. TLS_AES_128_GCM_SHA256
   - AES-128 encryption with GCM
   - SHA-256 for HMAC
   - Good performance/security balance

TLS Configuration:
server {
    listen 443 ssl http2;
    ssl_protocols TLSv1.3;
    ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256';
    ssl_prefer_server_ciphers on;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_stapling on;
    ssl_stapling_verify on;
}

Certificate Requirements

Algorithm: RSA 4096-bit minimum, or ECDSA P-384/P-521
Signature: SHA-256 or stronger (SHA-384, SHA-512)
Validity: Maximum 397 days (13 months)
Key Usage: Digital Signature, Key Encipherment
Extended Key Usage: Server Authentication, Client Authentication
Subject Alternative Names: All DNS names and IPs covered
Certificate Transparency: SCT (Signed Certificate Timestamp) required

OAuth 2.0 Authorization Framework

WIA-ACS uses OAuth 2.0 for API authorization, enabling secure delegated access without sharing credentials.

Grant Types

Grant Type	Use Case	Flow
Authorization Code	Web applications with server backend	User redirects, exchanges code for token
PKCE Extension	Mobile apps, SPAs, public clients	Authorization code + code verifier
Client Credentials	Server-to-server, batch jobs	Client ID + secret → token
Device Code	Smart TVs, IoT devices, kiosks	User authorizes on separate device
Refresh Token	Long-lived sessions	Exchange refresh token for new access token

Authorization Code Flow with PKCE

1. Client generates code verifier and challenge
   code_verifier = BASE64URL(RANDOM(32 bytes))
   code_challenge = BASE64URL(SHA256(code_verifier))

2. Authorization request
   GET /oauth/authorize
     ?response_type=code
     &client_id=wia-acs-app-001
     &redirect_uri=https://app.example.com/callback
     &scope=read:credentials+write:credentials
     &state=random_state_xyz123
     &code_challenge=CHALLENGE_FROM_STEP1
     &code_challenge_method=S256

3. User authenticates and authorizes
   → Returns authorization code

4. Token exchange
   POST /oauth/token
   Content-Type: application/x-www-form-urlencoded

   grant_type=authorization_code
   &code=AUTH_CODE_FROM_STEP3
   &redirect_uri=https://app.example.com/callback
   &client_id=wia-acs-app-001
   &code_verifier=VERIFIER_FROM_STEP1

5. Response
   {
     "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
     "token_type": "Bearer",
     "expires_in": 3600,
     "refresh_token": "rt_abc123xyz789",
     "scope": "read:credentials write:credentials"
   }

JWT Access Token Structure

Header:
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "wia-acs-key-2025-001"
}

Payload:
{
  "iss": "https://auth.example.com",
  "sub": "usr-20251226-abc123",
  "aud": ["https://api.example.com"],
  "exp": 1735228800,
  "iat": 1735225200,
  "nbf": 1735225200,
  "jti": "jwt-20251226-143217-xyz",
  "scope": "read:credentials write:credentials",
  "client_id": "wia-acs-app-001",
  "roles": ["role-employee", "role-building-access"],
  "clearance_level": 3
}

Signature:
RS256(base64UrlEncode(header) + "." + base64UrlEncode(payload), privateKey)

Token Validation:
1. Verify signature using public key
2. Check expiration (exp claim)
3. Validate issuer (iss claim)
4. Verify audience (aud claim)
5. Check not-before time (nbf claim)
6. Validate scopes match request

OpenID Connect (OIDC)

OpenID Connect extends OAuth 2.0 to add authentication, providing standardized user identity information.

OIDC Authentication Flow

1. Authorization request (adds openid scope)
   GET /oauth/authorize
     ?response_type=code
     &client_id=wia-acs-app-001
     &redirect_uri=https://app.example.com/callback
     &scope=openid+profile+email
     &state=xyz123
     &nonce=abc789

2. Token response (includes ID token)
   {
     "access_token": "...",
     "token_type": "Bearer",
     "expires_in": 3600,
     "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
     "refresh_token": "..."
   }

3. ID Token Payload
   {
     "iss": "https://auth.example.com",
     "sub": "usr-20251226-abc123",
     "aud": "wia-acs-app-001",
     "exp": 1735228800,
     "iat": 1735225200,
     "nonce": "abc789",
     "auth_time": 1735225150,
     "acr": "urn:mace:incommon:iap:silver",
     "amr": ["pwd", "otp"],
     "azp": "wia-acs-app-001",
     "name": "John Doe",
     "given_name": "John",
     "family_name": "Doe",
     "email": "john.doe@example.com",
     "email_verified": true
   }

4. UserInfo endpoint (optional, for additional claims)
   GET /oauth/userinfo
   Authorization: Bearer ACCESS_TOKEN

   Response:
   {
     "sub": "usr-20251226-abc123",
     "name": "John Doe",
     "email": "john.doe@example.com",
     "department": "Engineering",
     "title": "Senior Software Engineer"
   }

SAML 2.0 for Enterprise SSO

SAML (Security Assertion Markup Language) enables single sign-on across enterprise applications, particularly for organizations using Active Directory, Okta, Azure AD, or other identity providers.

SAML Authentication Flow

Service Provider (SP) Initiated Flow:

1. User accesses WIA-ACS application
   GET https://acs.example.com/secure-area

2. SP generates SAML AuthnRequest
   <samlp:AuthnRequest
       xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
       ID="id-abc123"
       Version="2.0"
       IssueInstant="2025-12-26T14:32:17Z"
       Destination="https://idp.example.com/saml/sso"
       AssertionConsumerServiceURL="https://acs.example.com/saml/acs">
       <saml:Issuer>https://acs.example.com</saml:Issuer>
       <samlp:NameIDPolicy
           Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
           AllowCreate="true"/>
       <samlp:RequestedAuthnContext Comparison="exact">
           <saml:AuthnContextClassRef>
               urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
           </saml:AuthnContextClassRef>
       </samlp:RequestedAuthnContext>
   </samlp:AuthnRequest>

3. Browser redirects to IdP
   HTTP 302 https://idp.example.com/saml/sso
   ?SAMLRequest=BASE64(DEFLATE(AuthnRequest))
   &RelayState=original-url-state

4. User authenticates at IdP
   (Username/password, MFA, etc.)

5. IdP generates SAML Response with assertion
   <samlp:Response
       xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
       ID="response-xyz789"
       IssueInstant="2025-12-26T14:33:00Z"
       Destination="https://acs.example.com/saml/acs">
       <saml:Issuer>https://idp.example.com</saml:Issuer>
       <samlp:Status>
           <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
       </samlp:Status>
       <saml:Assertion ID="assertion-123" IssueInstant="2025-12-26T14:33:00Z">
           <saml:Subject>
               <saml:NameID>john.doe@example.com</saml:NameID>
               <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                   <saml:SubjectConfirmationData
                       NotOnOrAfter="2025-12-26T14:38:00Z"
                       Recipient="https://acs.example.com/saml/acs"/>
               </saml:SubjectConfirmation>
           </saml:Subject>
           <saml:AttributeStatement>
               <saml:Attribute Name="email">
                   <saml:AttributeValue>john.doe@example.com</saml:AttributeValue>
               </saml:Attribute>
               <saml:Attribute Name="department">
                   <saml:AttributeValue>Engineering</saml:AttributeValue>
               </saml:Attribute>
               <saml:Attribute Name="role">
                   <saml:AttributeValue>employee</saml:AttributeValue>
                   <saml:AttributeValue>engineer</saml:AttributeValue>
               </saml:Attribute>
           </saml:AttributeStatement>
       </saml:Assertion>
   </samlp:Response>

6. SP validates assertion signature and creates session
7. User redirected to original URL (RelayState)

SAML Security Requirements

Signature validation: All assertions must be signed with RSA-SHA256 or stronger
Certificate verification: Validate IdP certificate chain and expiration
Timestamp validation: Check NotBefore, NotOnOrAfter, IssueInstant
Audience restriction: Verify assertion intended for this SP
Replay prevention: Track assertion IDs to prevent replay attacks
Encrypted assertions: Optional but recommended for sensitive data

Certificate Management

Proper certificate lifecycle management is critical for WIA-ACS security:

Certificate Hierarchy

WIA-ACS PKI Structure:

Root CA (Offline, air-gapped storage)
├── Validity: 20 years
├── Key Size: RSA 4096 or ECDSA P-521
└── Purpose: Signs intermediate CAs only

    └── Intermediate CA (Online, HSM-protected)
        ├── Validity: 10 years
        ├── Key Size: RSA 4096 or ECDSA P-384
        └── Purpose: Signs end-entity certificates

            ├── TLS Server Certificates
            │   ├── Validity: 397 days (13 months)
            │   ├── Auto-renewal: 30 days before expiry
            │   └── Usage: API servers, web portals

            ├── TLS Client Certificates
            │   ├── Validity: 2 years
            │   ├── User-specific or device-specific
            │   └── Usage: Mutual TLS authentication

            ├── Code Signing Certificates
            │   ├── Validity: 3 years
            │   ├── EV (Extended Validation) recommended
            │   └── Usage: Firmware, software updates

            └── Smart Card Certificates
                ├── Validity: 3 years
                ├── Stored on PIV/CAC cards
                └── Usage: Physical + logical access

Automated Certificate Renewal

ACME Protocol (Let's Encrypt compatible):

1. Certificate request
   POST /acme/new-order
   {
     "identifiers": [
       {"type": "dns", "value": "api.example.com"},
       {"type": "dns", "value": "acs.example.com"}
     ]
   }

2. Challenge authorization
   DNS-01: Set TXT record _acme-challenge.example.com
   HTTP-01: Serve file at /.well-known/acme-challenge/TOKEN
   TLS-ALPN-01: Serve self-signed cert with challenge

3. CSR submission
   POST /acme/finalize/{orderId}
   {
     "csr": "BASE64(DER-encoded CSR)"
   }

4. Certificate issuance
   Download from /acme/cert/{certId}

Renewal Workflow:
┌─────────────────────────────────────────────┐
│ Certificate Lifecycle Automation            │
├─────────────────────────────────────────────┤
│ 90 days:  Certificate issued               │
│ 60 days:  Renewal notification             │
│ 30 days:  Automatic renewal triggered      │
│ 29 days:  New certificate issued           │
│ 28 days:  Gradual rollout to servers       │
│  7 days:  Old certificate deprecated       │
│  0 days:  Old certificate expired          │
└─────────────────────────────────────────────┘

Protocol Security Best Practices

Security Control	Implementation	Rationale
HSTS	Strict-Transport-Security: max-age=31536000; includeSubDomains	Force HTTPS, prevent downgrade attacks
Certificate Pinning	Public-Key-Pins: pin-sha256="..."; max-age=5184000	Prevent MITM with rogue certificates
CAA Records	example.com. CAA 0 issue "letsencrypt.org"	Restrict which CAs can issue certificates
OCSP Stapling	Server provides fresh OCSP response	Faster cert validation, privacy preservation
Token Binding	Bind tokens to TLS channel	Prevent token theft and replay

Chapter Summary

This chapter covered Phase 3 of WIA-ACS: secure communication protocols. We explored TLS 1.3 for transport security, OAuth 2.0 for authorization, OpenID Connect for authentication, SAML 2.0 for enterprise SSO, and comprehensive certificate management practices. These protocols ensure all WIA-ACS communications are encrypted, authenticated, and integrity-protected.

Key Takeaways

TLS 1.3 is mandatory for all WIA-ACS communications, providing encryption, perfect forward secrecy, and reduced latency
OAuth 2.0 with PKCE enables secure API authorization for web, mobile, and server applications
OpenID Connect extends OAuth 2.0 to provide standardized user authentication and identity claims
SAML 2.0 enables enterprise single sign-on integration with existing identity providers
Automated certificate management using ACME protocol prevents expiration-related outages

Review Questions

What are the key improvements of TLS 1.3 over TLS 1.2? Why is perfect forward secrecy important?
Explain the OAuth 2.0 authorization code flow with PKCE. Why is PKCE critical for mobile applications?
What is the difference between an OAuth 2.0 access token and an OpenID Connect ID token?
Describe the SAML 2.0 authentication flow. How does the service provider validate the assertion's authenticity?
Design a certificate hierarchy for a global enterprise with 50 locations. What validity periods would you use?
Why is automated certificate renewal important? What problems does it solve?

Looking Ahead

With secure protocols established, Chapter 7 examines Phase 4: Integration with existing systems. We'll explore adapters for LDAP, Active Directory, PACS systems, biometric devices, and IoT hardware, enabling WIA-ACS to work seamlessly with current infrastructure.