Update on auth changes

context/security-testengine-authentication-changes.md

@@ -0,0 +1,39 @@
+# Test Engine Security - Authentication Changes
+
+When the experimental release of the Test Engine was initially made available, the only authentication method provided was through environment variables for the username and password. This approach presented several issues. Firstly, it relied on Basic authentication, which is inherently less secure as it transmits credentials in an easily decodable format. Additionally, this method did not align with Microsoft's strong recommendations for Multi-Factor Authentication (MFA), which is crucial for enhancing security by requiring multiple forms of verification.
+
+The reliance on environment variables for authentication posed significant risks. Environment variables can be inadvertently exposed through logs, debugging sessions, or misconfigurations, leading to potential credential leaks. Moreover, Basic authentication does not provide the robust security measures needed to protect sensitive information, making it vulnerable to various attacks such as phishing and man-in-the-middle attacks.
+
+In response to these security concerns, the newer updates to the Test Engine have introduced a new storage state provider that integrates with the browser's storage state. This update allows for Multi-Factor Authentication, significantly enhancing the security of the authentication process. By leveraging the browser's storage state, the Test Engine can now support more secure and user-friendly authentication methods, aligning with Microsoft's Security Framework Initiative (SFI).
+
+The integration with the browser's storage state enables the use of modern authentication mechanisms, such as OAuth and OpenID Connect, which support MFA. These mechanisms provide a more secure and seamless user experience by allowing users to authenticate through familiar and trusted interfaces. Overall it allows the use organization controlled settings to manage the lifetime of the created persistant login state. 
+
+In conclusion, the shift from environment variable-based authentication to a storage state provider that supports Multi-Factor Authentication marks a significant improvement in the security posture of the Test Engine. This change not only addresses the inherent vulnerabilities of Basic authentication but also aligns with Microsoft's broader security recommendations and initiatives, ensuring a more secure and reliable authentication process for users.
+
+## Example: Previous vs. New Authentication Approach
+
+### Previous Approach: Using pac test run
+In the previous approach, the pac test run command required setting both the username and password as environment variables. Here is an example:
+
+```pwsh
+$env:user1Email="your_username"
+$env:user1PAssword="your_password"
+pac test run -test testPlan.yaml
+```
+
+This method relied on Basic authentication, which, as mentioned earlier, is less secure and does not support MFA.
+
+### New Approach: Using Storage State Provider
+
+In the new approach, only the email is set via an environment variable, and user credentials are collected during the first interactive session and saved to the storage state. Here is an example:
+
+```pwsh
+$env:user1Email="your_username"
+pac test run  -test testPlan.yaml
+```
+
+During the first run, the user will be prompted to enter their credentials interactively. These credentials are then saved securely in the browser's storage state, allowing for MFA and eliminating the need to store sensitive information in environment variables.
+
+### Deeper Dive into Storage State Authentication
+
+For a more detailed understanding of the storage state authentication and the choices available, you can refer to the [Deep Dive - Test Engine Storage State Security](./security-testengine-storage-state-deep-dive.md).

context/security-testengine-storage-state-deep-dive.md

@@ -1,4 +1,21 @@
-# Deep Dive: Test Engine Storage State Security
+---
+title: Deep Dive - Test Engine Storage State Security
+layout: single
+author_profile: true
+read_time: true
+permalink: /context/security-testengine-storage-state-deep-dive
+toc: true
+entries_layout: grid
+feature_row:
+  - image_path: /assets/images/windows.png
+    alt: "Windows Machine icon"
+    title: '<center style="width=300px">Local Windows PC</center>'
+    url: /context/security-testengine-storage-state-deep-dive#local-windows
+  - image_path: /assets/images/dataverse.png
+    alt: "Dataverse icon"
+    title: '<center style="width=300px">Data Protection with Dataverse</center>'
+    url: /context/security-testengine-storage-state-deep-dive#data-protection-dataverse
+---
 
 One of the key elements of automated discussion using the multiple profiles of automated testing of Power apps is the security model to allow login and the security around these credentials. Understanding this deep dive is critical to comprehend how the login credential process works, how login tokens are encrypted, and how this relates to the Multi-Factor Authentication (MFA) process. Additionally, we will explore the controls that the Entra security team can put in in place and the security model across Test Engine, Playwright, Data Protection API, OAuth Login to Dataverse, Dataverse, and Key Value Store.
 
@@ -37,7 +54,23 @@ Continuous security validation and verification are crucial to maintaining a sec
 
 ## End to End Process
 
-With that context in place lets explore the end to end process at a high level
+With that context in place lets explore the possible end to end process at a high level. 
+
+{% include feature_row type=center %}
+
+### Local Windows
+
+The first and simplest option to secure storage state is using Windows Data Protection API. While this option has less components it does have limitations as it requires Microsoft Windows together the user account and machine to secure the files locally. If you are looking to execute on a different operating system or execute your tests in the context of pipelines the [Dataverse Data Protection](#data-protection-dataverse) approach will be a better approach.
+
+{% include figure popup=true image_path="/context/media/test-engine-security-storage-state-local.png" alt="Diagram of end to end process of Browser storage state using local storage and Windows Data Protection API" %}
+
+1. The current storage state user authentication provider is extended to Save and load the Playwright browser context as Encrypted values
+2. Make use of the [Windows Data Projection API](https://learn.microsoft.com/dotnet/standard/security/how-to-use-data-protection) to protect and unprotect the saved state at rest.
+3. Save encrypted json file or retrieve un protected JSON to the file system for use in other test sessions
+
+### Data Protection Dataverse
+
+The next approach makes use of a more comprehensive data protection approach that allows saved user persona state to be shared across multiple machines. This approach adopts a multi level approach to allow for a wider set of operating systems and execution environments.
 
 {% include figure popup=true image_path="/context/media/test-engine-security-storage-state.png" alt="Diagram of end to end process of Browser storage state using Microsoft Data Protection and Dataverse Data store for secure values" %}
 
@@ -47,7 +80,8 @@ With that context in place lets explore the end to end process at a high level
 4. Use a custom xml repository that provides the ability query and create Data Protection state by implementing IXmlRepository
 5. Store XML state of data protection in Dataverse Table. Encryption of XML State managed by Data Protection API and selected protection providers
 6. Make use of Dataverse Security model, sharing and auditing features are enabled to control access and record access to key and key data. Data Protection API is used to decrypt values and apply the state json to other test sessions.
-7. Use the Data Protection API to decrypt the encrypted value using Windows Data Protection API (DAPI) or X509 certificate private key.
+7. Use the Data Protection API to decrypt the encrypted value using Windows Data Protection API (DAPI) or X.509 certificate private key.
+8. A future option could also consider adding integration with [Azure Key Vault](https://learn.microsoft.com/aspnet/core/security/key-vault-configuration?view=aspnetcore-9.0)
 
 ## Tell Me More
 
@@ -78,6 +112,12 @@ The goal of the login process it work with organization defined login process so
 
 After a successful login process The storage state of the browser context can contain [cookies](https://learn.microsoft.com/entra/identity/authentication/concept-authentication-web-browser-cookies) that are used to authenticate later sessions. 
 
+The [How to: Use Data Protection](https://learn.microsoft.com/dotnet/standard/security/how-to-use-data-protection) provides more information and details on this approach.
+
+### Windows Data Protection API
+
+.NET provides access to the data protection API (DPAPI), which allows you to encrypt data using information from the current user account or computer. When you use the DPAPI, you alleviate the difficult problem of explicitly generating and storing a cryptographic key.
+
 ### Data Protection API
 
 The [Microsoft.AspNetCore.DataProtection](https://learn.microsoft.com/aspnet/core/security/data-protection/introduction?view=aspnetcore-9.0) package offers Windows Data Protection (DAPI) or Certificate public/private encryption. This ensures that sensitive data, such as login tokens, is securely encrypted and stored.

roles-and-responsibilities/security-architects.md

@@ -49,6 +49,7 @@ Expired License: Test the behavior of the application when a user's license has
 | Context | Notes |
 |---------|-------|
 | [Secure First Initiative](../context/security-first-initiative.md) | By integrating these principles, we aim to create robust, resilient, and secure applications that can withstand evolving cyber threats. |
+| [Test Engine Security - Authentication Changes](../context/security-testengine-authentication-changes.md) | Provides context on the evolation from basic authentication to more secure authentication providers with updated chaneges in the Power Apps Test Engine |
 | [Deep Dive: Test Engine Storage State Security](../context/security-testengine-storage-state-deep-dive.md) | One of the key elements of automated discussion using the multiple profiles of automated testing of Power apps is the security model to allow login and the security around these credentials. Understanding this deep dive is critical to comprehend how the login credential process works, how login tokens are encrypted, and how this relates to the Multi-Factor Authentication (MFA) process. |
 
 ## Discussions