Feature request: Pass lease-request context (email, user identity) as blueprint parameter tokens

[chrisns]

Summary

Allow blueprint authors to reference lease-request metadata — such as the requesting user's email address, display name, and lease ID — as token substitutions in blueprint CloudFormation parameter values. This would enable blueprints to personalise provisioned environments for the individual lease holder without requiring manual parameter input.

Motivation

When building blueprints that provision services requiring user identity (e.g. Amazon QuickSight, Amazon WorkSpaces, or any service with per-user resource ownership), there is currently no way for the blueprint to know who requested the lease.

We hit this concretely while building a QuickSight dashboard blueprint for NDX:Try. QuickSight requires a registered user to own dashboards, datasets, and data sources. Without knowing the lease holder's email or identity, the blueprint has to either:

1. Hardcode a username — which doesn't exist in ISB sandbox accounts since they use unpredictable SSO-federated identities
2. Auto-create a synthetic IAM user — which works for resource ownership but means the actual human user still hits QuickSight's self-registration page when they try to view the dashboard
3. Use anonymous embedding — which adds significant complexity (API Gateway + Lambda) for what should be a simple "open the dashboard" experience

If the blueprint could receive the lease holder's email address as a parameter, it could register them as a QuickSight user during provisioning, giving them seamless access to the dashboard the moment their lease is approved.

Proposed approach

When ISB deploys a blueprint's StackSet instance, allow the blueprint configuration to reference lease-context tokens in parameter values. For example:

{
  "parameters": [
    {
      "name": "UserEmail",
      "value": "{{lease.requester.email}}"
    },
    {
      "name": "UserDisplayName",
      "value": "{{lease.requester.displayName}}"
    },
    {
      "name": "LeaseId",
      "value": "{{lease.id}}"
    }
  ]
}

Suggested tokens

Token	Description
{{lease.requester.email}}	Email address of the user who requested the lease
{{lease.requester.displayName}}	Display name / friendly name
{{lease.requester.id}}	Unique user identifier
{{lease.id}}	The lease ID
{{lease.templateName}}	The lease template name
{{lease.expiryDate}}	Lease expiry timestamp

Where tokens would be resolved

The token substitution would happen at StackSet instance creation time within the ISB lease-approval workflow, before the parameters are passed to CloudFormation.

Use cases beyond QuickSight

• Amazon WorkSpaces / AppStream — provision a workspace pre-assigned to the requesting user
• IAM Identity Center assignments — grant the specific user access to provisioned applications
• Notification configuration — send deployment-complete emails to the lease holder directly
• Audit and tagging — tag all resources with who requested them
• Personalised demo environments — pre-populate applications with the user's name/email for a more realistic experience

Current workaround

For our QuickSight blueprint, we register the Lambda execution role as a synthetic QuickSight admin user. This allows CloudFormation to create the dashboard, but the actual human user still sees QuickSight's self-registration prompt when they first visit. There is no clean way to bridge this gap without knowing the user's identity at deployment time.