Daiyaan Ijaz
  11:25 AM
you will be very pleased
11:25
regarding the document for jira, the tool is finished
11:25
only thing left is the help button on the tool
11:25
for auth troubleshooting


Kulveer Virk
  3:37 PM
could you please send me the write up you had on auth? that long text file?


Daiyaan Ijaz
  3:38 PM
information on auth organized.txt
 
Authentication Setup:
UI (Vue.js): A custom plugin handles authentication-related information.
Nest server (TypeScript with Node.js): Implements server-side logic for authentication, token handling, and user management.
Cloud server (Spring Boot): Implements server-side logic for handling authenticated requests and managing user sessions.
Native authentication layer (C#): Utilizes the MSAL library to establish authentication with Azure Active Directory.
Azure Application Setup:
An Azure application is created for both development and production environments, with specific application ID, tenant ID, and authority details determining the authentication process used.
UI-Nest Integration:
The UI component connects to the Nest server using a WebSocket, identifying itself as the UI client.
A custom plugin is initialized in the Vue application's main.ts file, using the msalInstance object to configure the MsalPlugin class.
The plugin is responsible for WebSocket communication and authentication functionality, with separate concerns for the WebSocket and authentication logic.
The plugin's installation function creates a $msal observable used for handling authentication in the UserLogin.ts file.
Nest-Native Integration:
Communication between UI, Nest, and the native authentication layer is facilitated through WebSockets.
The native application is called through a WebSocket connection, triggered by events from the UI.
Various events (e.g., "uiReadyEvent", "uiUpdateEvent") are used for specific operations and data exchange between Nest and the UI.
Native Authentication Layer (C#):
The native authentication layer handles authentication independently of Nest and the UI.
It uses the MSAL library to prompt the user for login credentials via a popup.
Upon obtaining the login result, the B2C token is exchanged for a Ford Pro token required by the cloud service.
The Ford Pro token is refreshed every 5 minutes using the refresh token API.
The encrypted tokens are stored in memory using AES 256 GCM encryption.
The nativeSocket is established and closed as per the authentication process.
The nativeSocket connection is tracked and used for handling events and errors between Nest and the native authentication layer.
Coordination with Ford PRO IAM:
Ford Pro provides login credentials, URLs, and application IDs for the development, staging, and production environments.
Ford Pro assists with the coordination of Azure application details and authentication process.
User Session Management:
The UI and Nest store user details received from the cloud server, ensuring the user session remains active.
The cloud server intercepts and handles traffic using an interceptor and custom WebSecurityFilter configuration.
User information is retrieved from the token, and the server checks if the user exists before inserting or returning user details.
The Nest server has a sign-out function triggered by the UI, which removes tokens from memory and initiates the logout process in the native application.
Please note that this summary is a condensed version of the provided information, organized to enhance readability and comprehension.
In the UI (Vue.js), a custom plugin is created to handle authentication-related information.
In the Nest server (TypeScript with Node.js), the server-side logic for authentication, token handling, and user management is implemented.
In the cloud server (Spring Boot), the server-side logic for handling authenticated requests and managing user sessions is implemented.
The native authentication layer is developed using C# and utilizes the MSAL (Microsoft Authentication Library) to establish authentication with Azure Active Directory.
For both the development and production environments, an Azure application is created with a specific application ID, tenant ID, and authority. These details determine the authentication process used.
The UI component connects to the Nest server using a WebSocket. When the connection is established, we store the client ID to identify it as the UI client. This identification is done by sending an event from the UI to the Nest server upon connection, specifically the "uiReadyEvent."
To initialize the plugin we created, we utilize it in the main.ts file of our Vue application. On line 28, we have the code Vue.use(new MsalPlugin(), msalInstance). This line initializes the plugin with the msalInstance object, which contains the configuration for our MsalPlugin class.
While the original purpose of the MsalPlugin was to leverage the Msal library for VueJS authentication, we have made modifications to adapt it to our specific use case. We have stripped out the usage related to the Msal library authentication process and kept the plugin installation intact.
In the refactored version of the plugin, we have separated concerns for the WebSocket and the main authentication functionality. By setting up a vue observable.prototype within the plugin, we can call functions within the MsalPlugin that are part of the same instance. This allows us to maintain a singleton pattern for the plugin.
The installation function of the plugin creates a $msal observable, which is used in our UserLogin.ts file for handling authentication.
There are several events from the Nest side that we listen to in order to handle specific operations. The "uiReadyEvent" is responsible for establishing the connection ID within Nest. The "uiUpdateEvent" receives user object data, which is used to save the user data within the UI. The Nest server calls the cloud and passes an authorization token via a cookie to retrieve the user details object.
To gain a holistic understanding of how things are working, it is important to consider how the user details object from the cloud is hydrated. At this point, we will switch our focus to the native application to further explore this flow.
The native application has a program.cs file that takes two arguments: "login" and "logout". Based on the interaction (such as clicking the logout button or continuing with SSO), the desired event is handled.
The native application is called through a WebSocket connection. When the user clicks a button in the UI, an event is sent to the Nest server. In the UserLogin.vue file, there is a function that calls this.$msal.launchLogin() from the plugin. Before calling this function, this.hideShowLogin() is invoked, which sets showLogin to false. This variable controls the visibility of the login component based on different conditions and interactions.
The launchLogin() function in the plugin triggers the "uiLaunchLogin" event in NestJS. Conversely, the UI also listens for the "uiLaunchLogin" event. This means that after calling uiLaunchLogin from the UI to Nest, Nest takes note of the UI's attempt to launch the login process. If the application is in developer mode, we also receive console logs to understand the process fl. Nest checks if the nativeSocket client already exists. This client is tracked similarly to the UISocket client that is established when the UI page is initially opened.
If the nativeSocket client already exists, an event called uiThrowEvent is sent to the UI to handle the error, and a BadGateway exception is thrown within Nest. However, this error occurrence is rare due to additional validation measures in place to prevent multiple instances of the native authentication layer from being launched simultaneously.
After that, the client is re-established by sending the event as the UISocket for consistency. The function isNativeLaunching is checked to ensure that an instance of the native authentication layer is not already in the process of launching. This flag is important because it prevents the opening of a second instance where both are attempting to connect. If the native authentication layer is not already launching, the launchLogin function is called within Nest.
Communication between the UI, Nest, and the native authentication layer is facilitated using WebSockets. The Nest server hosts a WebSocket server on a designated port (e.g., port 1335). Both the UI and the native authentication layer connect to this WebSocket server.
In terms of coordination with Ford Pro, they provide assistance with the login credentials used to retrieve user details. They provide URLs for the development, staging, and production environments, as well as the application IDs for the corresponding environment credentials (referencing the Azure application section).
The launchLogin function checks whether the user is in developer mode or not before running the native authentication application. In developer mode, the folder for the native dev application is located in an upper-level directory from the Nest server. In production mode, the folder is within the Nest server itself. This setup allows both folders to coexist, and the mode can be switched based on a flag. However, this implementation is due for a refactor, possibly using a launch argument to use dev credentials in the authentication layer instead of having two separately built executables with environment-specific credentials.
The login argument is used in the exeNative.spawn launch. By checking if the uiSocket is connected during the process launch of the native application, the showLoginAfterInitial function is called, allowing the spinner to be displayed, regardless of whether the user is authenticated or not.
Once control is handed over to the native application, it operates independently of Nest and the UI. The "exeNative.on('INTERACTION')" event can be used to intercept outputs logged by the native app within Nest. Additionally, the closure of the native child process spawned by Nest can be detected and handled. Before doing so, a flag called "justLoggedIn" is checked to ensure that the continue with SSO button should not be displayed. If the user has just successfully logged in, it doesn't make sense to show the button; instead, the spinner should continue until the other process is finalized, and the user is redirected to the project listing. This prevents a scenario where the user briefly sees the continue with SSO button after successful login before being redirected. The "hideLoginAfterInitial" event is called to inform the UI when the continue with SSO button needs to reappear.
Regardless of the outcome, when the native authentication layer is closed, the nativeSocket is set back to null. The initial setting of the nativeSocket is done within the native authentication layer when the application loads the specified argument (in this case, "login"). In the C# LoginHandler.cs file, the WebSocket server is set up in the constructor, and the LoginAccount function is called, leveraging the connection established in the constructor by triggering the "nativeReadyEvent" event.
The launchLogin function is responsible for checking whether the user is in developer mode or not before running the native authentication application. In developer mode, the native dev application is located in an upper-level directory from the Nest server, while in production mode, it resides within the Nest server itself. This allows both versions to coexist, and the mode can be switched based on a flag. However, this implementation is scheduled for a refactor, possibly using a launch argument to utilize dev credentials in the authentication layer instead of maintaining two separately built executables with environment-specific credentials.
It's important to note the usage of the login argument within the exeNative.spawn launch command. By checking if the uiSocket is connected during the process launch of the native application, the showLoginAfterInitial function is invoked, enabling the display of a spinner, regardless of whether the user is authenticated or not.
Once control is handed over to the native application, it operates independently of Nest and the UI. The "exeNative.on('INTERACTION')" event is utilized to identify when the native application logs an output, which can be intercepted within Nest. Additionally, the closure of the native child process spawned by Nest is detected and handled. Before doing so, a flag named "justLoggedIn" is checked to ensure that the continue with SSO button should not be displayed. This check is necessary because after the native authentication layer closes, we want to confirm that the user didn't just successfully log in. If the user did log in, it wouldn't make sense to display the continue with SSO button; instead, the spinner should persist until the other process is finalized, and the user is redirected to the project listing. Without this flag, the user would briefly see the continue with SSO button after successful login before being redirected. By having the flag, we can anticipate scenarios where the user manually closes the authentication layer or if it crashes without successful login.
The "hideLoginAfterInitial" event is triggered to inform the UI when the continue with SSO button needs to reappear.
Regardless of the outcome, when the native authentication layer is closed, the nativeSocket, which was initially set, is reset to null. The initial setting of the nativeSocket occurs within the native authentication layer when the application loads the specified argument (in this case, "login"). In the C# LoginHandler.cs file, the WebSocket server is set up within the constructor, and the LoginAccount function is called, leveraging the connection established in the constructor by triggering the "nativeReadyEvent" event.
After setting nativeSocket to null within the close listener for the child process spawned in Nest (exeNative or the native authentication layer), the process is terminated to ensure it is fully closed. The justLoggedIn flag is reset to false, along with the isNativeLaunching flag.
Now, let's discuss the process in the C# native authentication layer. Upon hitting the ready event, the user is prompted to log in using a popup provided by the Microsoft library, which is configured with the designated redirect URI, B2C authority, tenant ID, and client ID. The specific credentials for the Azure application, which provide these details, need to be coordinated with Ford Pro.
Once the login result is obtained from the popup, the B2C token is exchanged for a Ford Pro token, which is the required token for the cloud service. This exchange involves making a call to an endpoint that accepts the B2C token and returns the Ford Pro token. The response from this exchange includes the following details: access_token, token_type, refresh_token, expires_in, id_token, and scope.
The access_token is used to hydrate the principle object, which provides user details within the auth interceptor integration in the cloud. To perform this hydration, a library is used, which can be found at the provided GitHub link.
The token_type is set to "bearer", and the refresh_token has a lifetime of 8 hours. It is used to refresh the Ford Pro access_token, which has a lifetime of 5 minutes. The remaining time until expiry can be determined by converting the Unix timestamp to a DateTime format.
To maintain the user's login session, the refresh token API needs to be called every 5 minutes to refresh the Ford Pro access token. This process ensures that the user's login remains valid until it can no longer be refreshed, requiring the user to log in again to obtain a new token.
Once the token is swapped, it is sent to the Nest server by passing the entire token object through the "sendToken" event.
In Nest, upon receiving the token, the payload is checked for the required data. If the data is missing, an UnauthorizedException error is thrown, indicating that the token is not valid.
The tokens are then stored in an encrypted format in memory. To encrypt the tokens, AES 256 GCM encryption is used, utilizing Node.js core functionality. The encryption process involves an encryption key IV, a cipher, and an authTag.
The encrypted tokens are used for REST calls, and no unencrypted token data is stored in memory.
Next, the signInNative function is called, passing the encrypted token, refresh token, and expiresIn values. It's important to note that at this point, the token data is in an encrypted format. The returned value of this function, called userDetails, is awaited, and the execution of the sendToken event does not continue until the data is hydrated.
Within the securityService in the signInNative function, the instance of the current token and refresh token is stored, allowing for on-demand updates. For example, when the token is refreshed and has a new expiry time, the updated token values are used in other functions within the security service. Once stored within the security service, the createUserFromToken function is called. This function decrypts the token and sends it as an access token in the cookie header to the handle-sign-in endpoint, which is directed to the cloud server.
In the cloud server, an interceptor is installed to handle traffic based on the configuration defined in WebSecurityConfigurationAdapter of Spring Boot. This interceptor requires the issuer, Azure application ID (based on the environment), config URL, and resolver to be specified. For the stage/dev environment, the issuer and application ID are set to "stage" (as both stage and dev are connected to the same database), while for production, the appropriate values are used.
The interceptor has the inject filter set to false since a custom WebSecurityFilter configuration is used.
If a token is passed to the cloud server and it doesn't exist, a 403 Forbidden response is returned. In this case, an attempt is made to refresh the token at least once, and the handling for this scenario is implemented.
If the token exists, the server receives the user's UUID, company ID, roles, company information (name), email, first name, and last name. The server first checks the SQLite repository to ensure that the user doesn't already exist. If the user doesn't exist, a new user entry is inserted, and UUIDs are inserted in uppercase to ensure case sensitivity across the cloud system. If the user already exists, the current user information is returned based on the retrieved entity. The signedOut flag is set to false at this point because the UI's ui.gateway.ts file handles disconnections, and the signedOut flag is checked to ensure the user is logged out just before closing Nest in case it is a redirect from signing out.
The Nest server has a signOut function that is called when the UI clicks the sign-out button. The user makes a call to Nest, which removes all encrypted tokens from memory and sets the signedOut flag to true. Then, the listenSignout function is called, which initiates the logout process in the native application.
Collapse
 This snippet was truncated for display; see it in full



3:39
second one was before i organized it
information on auth without refining.txt
 
The technology we are using to communicate between all 3 layers (UI,NEST,AUTH)
is called Websockets.
Nest server has a websocket server hosted on a designated port (we are currently
using port 1335).
Click to expand inline (279 lines)



3:39
it doesnt cover more than half of the rest of the auth work
3:39
here are docs regarding all the work
Zip
 

logindocs.zip
Zip
3:40
fcg advisor Thomas Kopczynski


Kulveer Virk
  3:42 PM
Ok


Kulveer Virk
  3:55 PM
Thanks.
3:55
Have a nice weekend.


Daiyaan Ijaz
  4:44 PM
thank you, you too. here are the bullet points from yesterday
work.txt
 
Coordinating with security
- Preparing documents to convince security
-- sequence diagrams, flows
Designing of the auth layer
- System responsibility
Subject Matter expert on UIS Auth Integration
with desktop tool
As subject matter expert, i worked with cybersecurity
vehicle engineering team, product owners, and team of software engineers
to integrate and deliver the ICA and PCA solutions for product launches at various phases
Explained security changes to product owners and other stakehodlers in business nomenclature 
I did ICA for the previous phase and PCA for the phase that is coming
also presented the solution to security leadership team
as well as FPI leadership team to address
the security vulnerabilities.
You also worked on developing our implementation, design, and engineering solution architecture.
Worked with troubleshooting of end external end customers.
Call with customers to troubleshoot the auth layer.
You have also developed the internal tool for production support to validate connectivity within the auth layer.
Also integrated auth code with distributed software (MSI), provided environment switching, and v2 cloud security.
Delivered user stories for frontend backend and collaborated with architecture team on design sessions.
Subject matter expert so owner of that key functionality of auth integration. developed the functionality. 
Cross organization collaboration with Ford ProTech, Cybersecurity, IAM team on auth layer security for approval and attaining integration
requirements.
Delivered quality code on critical functionality on time. Participated in various process improvement opportunities and provided multiple
process improvement ideas that were incorporated.
Supported production launch during off-hours.
Participate in on-site and in-vehicle testing for f250 and european transit launches.
Worked with cybersecurity team on quantification of threats. 
Did discovery phase on potential threats and explored level of severity on various threats (like man in the middle exploits).
 
C#, Springboot, VueJS,
Collapse






Daiyaan Ijaz
  5:08 PM
Objective: To showcase my accomplishments and contributions as a subject matter expert in UIS on Auth Integration during my first year at Ford.
Professional Summary: As the subject matter expert in UIS on Auth Integration, I collaborated with the cybersecurity vehicle engineering team, product owners, and a team of software engineers to integrate and deliver the ICA and PCA solutions for product launches at various phases. My responsibilities included explaining security changes to stakeholders in business nomenclature, presenting the solutions to security and FPI leadership teams, and coordinating with cross-functional teams to attain integration requirements.
Developed the authentication layer,  designed the implementation, engineering, and solution architecture for the integration of auth code with distributed software (MSI) while under existing and incoming rigid requirements.
Presented sequence diagrams and flows to convince security and delivered user stories for frontend backend and collaborated with the architecture team on design sessions.
Supported production launch during off-hours and participated in on-site and in-vehicle testing for F250 and European Transit launches.
Conducted a thorough discovery phase on potential threats, exploring the level of severity on various threats like man in the middle exploits, and quickly finding solutions to mitigate risks.
Worked with troubleshooting of external customers and developed an internal tool for production support to validate connectivity within the auth layer.
Developed an MVP concept for an internal tool for production support, validating connectivity within the auth layer and troubleshooting issues for external customers.
Took ownership of the project, drawing on my background experience and knowledge, and independently worked on designing and delivering the auth layer.
Developed and implemented the authentication layer while adhering to existing and incoming rigid requirements, resulting in successful integration with distributed software (MSI) within a very large codebase.
(edited)
5:10
early on pushed for documentation
image.png
 
image.png
5:10
here is my ford internship powerpoint
5:10
https://www.figma.com/proto/v4JELzGReiWoAedhNnYeXM?type=design&node-id=0-1&mode=design&t=pxQW9SYJsU4uLS3o-6
5:11
cusotm internal tools was something i always considered as an investment
image.png
 
image.png







5:11
https://github.ford.com/DIJAZ/contentconverter


Daiyaan Ijaz
  5:18 PM
i forwarded u an old email