Executive Overview

This case study explores identity as a control plane—focusing on how authentication, authorization, and user intent determine system behavior, data exposure, and trust. Rather than building a full production job board, the project emphasizes early-stage problem framing and system-level decision-making.

TechVets Solutions is a security-first platform concept designed to support veterans transitioning into technology careers. Identity, access control, and trust are treated as first-class design constraints rather than implementation details.

Originally developed as a capstone for the Google UX Design Professional Certificate, the project was expanded into an application security case study to demonstrate identity-first thinking across UX and AppSec contexts.

Problem Statement

Veterans entering the tech workforce often interact with platforms that fail to distinguish intent and trust boundaries.

  • Treat all authenticated users identically
  • Expose excess personal data by default
  • Fail to differentiate intent (candidate vs mentor vs employer)
  • Create unclear trust boundaries and unnecessary exposure context
Analyst realizing a concept
How Might We

How might we design a system that adapts behavior, exposure, and trust boundaries based on user intent—not just authentication status?

Role Post-Login Experience
Veteran Veteran Dashboard
  • Supportive and action-oriented
  • Focused on personal growth and next steps
  • Includes saved roles, mentorship requests, and resume tools
Mentor Mentor Dashboard
  • Responsibility-focused
  • Emphasizes guidance and stewardship
  • Limited visibility into mentee information
Employer Employer Dashboard
  • Most constrained and controlled
  • No free browsing of candidate profiles
  • Access only to opt-in, role-aligned candidate summaries
Figure 1. Role-based post-login routing derived from identity claims. Each role is granted only the access required to fulfill its intent.

Identity-Driven System Design

Phase 1 of this project prioritizes behavioral correctness over feature completeness. Rather than beginning with interface design or application functionality, the system is designed around identity as the primary control plane—determining what users can see, access, and do after authentication.

Phase 1 Design Goal

The goal of Phase 1 is to demonstrate how identity and role-based access control directly influence post-authentication behavior. This mirrors real-world enterprise systems, where authentication establishes who a user is, and authorization governs system behavior based on role, intent, and trust boundaries.

Role Modeling & Trust Boundaries

The system defines three core roles—Veteran, Mentor, and Employer—each with intentionally different permissions, responsibilities, and visibility. These roles are designed to reflect least-privilege principles and data minimization, rather than assuming equal access across authenticated users.

Role differentiation is treated as a security primitive, not a UX convenience. Each role represents a distinct trust boundary with different risk profiles and access needs.

Identity-Driven Routing

A key architectural decision in Phase 1 is that all users do not land on the same interface after login. Post-authentication routing is determined by identity context, reinforcing the separation between authentication (who the user is) and authorization (what the user is allowed to do).

This approach prevents unnecessary data exposure, reduces implicit trust assumptions, and enables role-aware telemetry and detection logic.

Identity Control Mechanism

Microsoft Entra ID was selected conceptually due to its enterprise IAM alignment, support for role-based access control, conditional access, and federation readiness. While Phase 1 uses static dashboards, the design explicitly anticipates claims-based authorization. 


{
  "roles": ["veteran"]
}

This model allows routing, interface exposure, and access decisions to be driven by identity claims rather than hardcoded logic, aligning with scalable enterprise authorization patterns.

Intentional Scope Constraints

To keep the signal focused on identity design, Phase 1 intentionally excludes features such as job listings, messaging systems, databases, search, and analytics. These capabilities increase surface area without improving the demonstration of identity-driven behavior.

By constraining scope, the system highlights how correct identity decisions upstream enable safer feature expansion downstream.

EXAMPLE Canonical Login Event 

{
  "event_type": "authentication.login",
  "identity_provider": "entra_id",
  "user_id": "uuid-redacted",
  "roles": ["veteran"],
  "auth_method": "password+mfa",
  "login_context": {
    "device_trust": "managed",
    "location": "trusted"
  }
}

Lessons Learned

  • Identity-aware UX is foundational, not additive.
  • Authorization decisions shape user experience as much as UI.
  • Correct behavior matters more than feature completeness.

What Comes Next

Future phases will explore real identity claims, conditional access, audit logging, and governance workflows—building on the trust foundation established in Phase 1.

Identity-First Secure UX Application Security