fix: update sbt-aws.sh and format website md files (#125)

* fix: update sbt-aws.sh and format website md files

* fix broken anchor on website

scripts/sbt-aws.sh

@@ -11,7 +11,7 @@ CONFIG_FILE="${HOME}/.sbt-aws-config"
 help() {
   echo "Usage: $0 [--debug] <operation> [additional args]"
   echo "Operations:"
-  echo "  configure <control_plane_stack> <email_user> <email_domain>"
+  echo "  configure <control_plane_stack> <user_email>"
   echo "  refresh-tokens"
   echo "  create-tenant-registration"
   echo "  get-tenant-registration <tenant_registration_id>"
@@ -57,6 +57,8 @@ generate_credentials() {
   aws cognito-idp update-user-pool-client \
     --user-pool-id "$USER_POOL_ID" \
     --client-id "$CLIENT_ID" \
+    --id-token-validity 3 \
+    --access-token-validity 3 \
     --explicit-auth-flows USER_PASSWORD_AUTH \
     --output text >/dev/null
 
@@ -94,8 +96,9 @@ generate_credentials() {
 
 configure() {
   CONTROL_PLANE_STACK_NAME="$1"
-  EMAIL_USERNAME="$2"
-  EMAIL_DOMAIN="$3"
+  USER_EMAIL="$2"
+  EMAIL_USERNAME="$(echo $USER_EMAIL | cut -d "@" -f 1)"
+  EMAIL_DOMAIN="$(echo $USER_EMAIL | cut -d "@" -f 2)"
 
   if $DEBUG; then
     echo "Configuring with:"
@@ -132,7 +135,7 @@ refresh_tokens() {
     echo "Refreshing tokens..."
   fi
 
-  generate_credentials "$ADMIN_USER_PASSWORD"
+  generate_credentials "$ADMIN_USER_PASSWORD" "$CONTROL_PLANE_STACK_NAME"
   CONTROL_PLANE_API_ENDPOINT=$(aws cloudformation describe-stacks \
     --stack-name "$CONTROL_PLANE_STACK_NAME" \
     --query "Stacks[0].Outputs[?contains(OutputKey,'controlPlaneAPIEndpoint')].OutputValue" \
@@ -181,6 +184,7 @@ create_tenant_registration() {
         ]
       },
       "tenantRegistrationData": {
+        "registrationStatus": "In progress",
         "tenantRegistrationData1": "test"
       }
     }')

website/docs/partners/isv-integrations/moesif.md

@@ -105,7 +105,7 @@ Once you deploy your updated stack, create a tenant in your AWS SBT setup using
 
 When you create a tenant, you must also set the price id to be used for creating subscriptions, By default, the field name is `priceId`, but this can be overridden via the above options. If you are using Zuora, you must also set the plan id. The field `email` must also be set.
 
-_If your provider is set to Zuora, [you must also set these fields](#Zuora)_
+_If your provider is set to Zuora, [you must also set these fields](#zuora)_
 
 If you're running the `hello-cdk` project, this can be done by running [this script](https://github.com/awslabs/sbt-aws/tree/main/docs/public#test-the-deployment) to onboard a new tenant. Modify, the script to also include the price (and plan if required).
 

website/docs/reference_architectures/ecs-reference-architecture.md

@@ -4,15 +4,19 @@ sidebar_position: 2
 # Amazon ECS SaaS - Reference Architecture
 
 The AWS SaaS Factory ECS SaaS Reference Architecture is a example architecture that illustrates how to build and manage multi-tenant Software-as-a-Service (SaaS) applications using Amazon Elastic Container Service (ECS). It serves as a guide for developers looking to implement best practices in building multi-tenant SaaS applications on AWS using ECS, offering a flexible and scalable solution tailored to various business needs. This architecture leverages SBT for both control plane and tenant deployments. Key components and considerations of this reference architecture include:
+
 ## Key Features
+
 - **Multi-Tenant Architecture**: The architecture supports different tenant isolation strategies, including pooled and silo models, across three tiers: Basic, Advanced, and Premium. These tiers offer varying levels of resource sharing and isolation to meet different tenant needs.
 - **AWS Integration**: The solution leverages native AWS services for routing, observability, and service discovery. It uses AWS CloudFormation, AWS CDK, and ECS Service Connect for seamless integration and management of services.
 - **AWS SaaS Builder Toolkit (SBT)**: This toolkit extends the SaaS control plane with functionalities like tenant onboarding, user management, and billing. It also integrates with the ECS application plane for bi-directional communication necessary for SaaS operations.
+
 ## Architectural Tiers
+
 - **Basic Tier**: Utilizes shared ECS services across all tenants in a pooled model. This tier is preloaded in the baseline architecture and shares resources like product and order microservices.
 - **Advanced Tier**: Features a shared ECS cluster with dedicated ECS services per tenant, following a silo model. This setup provides more isolation compared to the Basic tier.
 - **Premium Tier**: Offers dedicated ECS clusters per tenant, providing the highest level of isolation and customization for each tenant.
 
 ## GitHub Repository
 
-For a complete implementation of the sample architecture for this pattern, see the [GitHub repository](https://github.com/aws-samples/saas-reference-architecture-ecs)
+For a complete implementation of the sample architecture for this pattern, see the [GitHub repository](https://github.com/aws-samples/saas-reference-architecture-ecs)

website/docs/reference_architectures/eks-reference-architecture.md

@@ -4,7 +4,9 @@ sidebar_position: 1
 # Amazon EKS SaaS Reference Architecture
 
 The AWS SaaS Factory EKS SaaS Reference Architecture provides a working example of a multi-tenant SaaS solution using Amazon Elastic Kubernetes Service (EKS). This architecture, like all SaaS Factory reference architectures, are provided as examples from which to create scalable, secure, and efficient SaaS applications on AWS. This architecture leverages SBT for both control plane and tenant deployments. Key components and considerations of this reference architecture include:
+
 ## Key Components
+
 1. **Multi-Tenant Isolation**: The architecture emphasizes tenant isolation, which is crucial for ensuring that each tenant's data and operations are secure and separate from others. This is achieved through Kubernetes namespaces and network policies.
 2. **Identity and Access Management**: Amazon Cognito is used for managing user identities and access controls, ensuring that tenant-specific access policies are enforced.
 3. **Data Partitioning**: Data for each tenant is partitioned to maintain privacy and security. This can involve using separate databases or schemas for each tenant, depending on the application's requirements.

website/docs/reference_architectures/serverless-saas-reference-architecture.md

@@ -3,15 +3,20 @@ sidebar_position: 3
 ---
 # Serverless SaaS - Reference Solution
 
-The AWS SaaS Factory Serverless SaaS Reference Architecture is a comprehensive example of a working, multi-tenant SaaS application using serverless technologies on AWS. This architecture leverages a range of AWS services to optimize operational efficiency and scalability while minimizing the complexity of managing infrastructure. The architecture leverages SBT for its control plane and tenant deployments. Key components and  concepts of this architecture include:
+The AWS SaaS Factory Serverless SaaS Reference Architecture is a comprehensive example of a working, multi-tenant SaaS application using serverless technologies on AWS. This architecture leverages a range of AWS services to optimize operational efficiency and scalability while minimizing the complexity of managing infrastructure. The architecture leverages SBT for its control plane and tenant deployments. Key components and concepts of this architecture include:
+
 ## Key Components
+
 - **Control Plane**: This is where tenant management and operational services reside. It includes components for registration, onboarding, and provisioning of tenants. The control plane is crucial for managing the lifecycle of tenants in a SaaS environment.
 - **Application Plane**: This consists of the core application services that handle business logic and data processing. It typically involves AWS Lambda for compute, Amazon API Gateway for routing requests, and Amazon DynamoDB for data storage.
 - **Identity and Access Management**: Amazon Cognito is used for user authentication and authorization, providing a secure way to manage user identities across different tenants.
+
 ## Architectural Strategies
+
 - **Serverless Model**: By using serverless services like AWS Lambda, the architecture reduces operational overhead and allows automatic scaling based on demand. This model aligns resource consumption with tenant activity, optimizing cost efficiency.
 - **Multi-Tenant Management**: The architecture supports both pooled and siloed deployment models, allowing flexibility in how resources are shared or isolated among tenants. This can be configured using AWS Lambda layers and API Gateway usage plans to manage tenant-specific configurations.
 - **Deployment Automation**: The reference architecture includes automated deployment pipelines using AWS CodePipeline, enabling continuous integration and delivery of updates across all tenants.
 
 # GitHub Repository
+
 For a complete implementation of the sample architecture for this pattern, see the [GitHub repository](https://github.com/aws-samples/aws-saas-factory-ref-solution-serverless-saas/tree/main)

website/docs/tutorials/sbt-workshop/workshop.md

@@ -6,6 +6,6 @@ sidebar_position: 1
 
 >For a detailed step by step walkthrough, click [this link](https://catalog.us-east-1.prod.workshops.aws/workshops/edc9cdde-87b1-4da3-8db8-ac0667b87cb6/en-US) to follow along in a workshop.
 
-In this workshop, you will walk through the development of a multi-tenant Software-as-a-Service (SaaS) solution using the [SaaS Builder Toolkit for AWS (SBT)](https://github.com/awslabs/sbt-aws) . SBT is an open-source toolkit designed to streamline and accelerate the development of SaaS applications by encapsulating best practices and common patterns into reusable components. As SaaS continues to dominate the software delivery model, the ability to rapidly deploy and scale applications becomes increasingly crucial. SBT utilizes the robust AWS Cloud Development Kit (CDK) to provide developers with high-level object-oriented abstractions, enabling a focus on building unique features rather than managing the underlying infrastructure.
+In this workshop, you will walk through the development of a multi-tenant Software-as-a-Service (SaaS) solution using the [SaaS Builder Toolkit for AWS (SBT)](https://github.com/awslabs/sbt-aws). SBT is an open-source toolkit designed to streamline and accelerate the development of SaaS applications by encapsulating best practices and common patterns into reusable components. As SaaS continues to dominate the software delivery model, the ability to rapidly deploy and scale applications becomes increasingly crucial. SBT utilizes the robust AWS Cloud Development Kit (CDK) to provide developers with high-level object-oriented abstractions, enabling a focus on building unique features rather than managing the underlying infrastructure.
 
-This workshop guide is structured into five comprehensive labs (with two optional ones), each aimed at enhancing your understanding and skills in utilizing the SBT to its full potential. By the end of this workshop, you will have built a fully functional SaaS application. It's important to note that prior knowledge of SBT is not required for this workshop. Instead, you can use this workshop as a step-by-step guide to gain a deeper understanding of the SBT components, enhancing your ability to effectively utilize these tools in building scalable SaaS solutions.
+This workshop guide is structured into five comprehensive labs (with two optional ones), each aimed at enhancing your understanding and skills in utilizing the SBT to its full potential. By the end of this workshop, you will have built a fully functional SaaS application. It's important to note that prior knowledge of SBT is not required for this workshop. Instead, you can use this workshop as a step-by-step guide to gain a deeper understanding of the SBT components, enhancing your ability to effectively utilize these tools in building scalable SaaS solutions.