Authentication Wiki

Introduction

The feature that team Delphi is implementing is authentication. Using extensive research and by coordinating meetings and discussions, our team has been better able to understand and implement our feature. Authentication is a critical portion of the graduate portal as it is one of the first pages that is interacted with by a user. Authentication is also used extensively with other features. Team Delphi handles session identification, login, and registration which are vital and must be used to access the portal.

Authentication consists of:

Something you know (name, email, etc)

Something you have (token)

Something you are (biometrics)

The aspects of “Something you know” and “Something you have” will be within the scope of our implementation of our feature.

There are a plethora of approaches to session identification. After thorough research (noted in the research section below) we were led to token based authentication. We have decided on using a JSON Web Token (JWT) approach for our feature. JWT allows us to securely transmit information between parties as a JSON object. In order to store this object, we have decided to use Redis as an in-memory data structure store.

For Session identification we had decided to go with OAuth when it came to authenticating student accounts. OAuth allowed the team to check email address if they were genuine Gmail University of Pretoria student accounts. This makes for an easier time authenticating students as Google will authenticate the Gmail accounts and provide us with information on whether they are student accounts from the University of Pretoria or not.

An in-depth analysis of these options was conducted by Johan (See “Planning and different approaches to authentication” in Research, below) to allow the team to make a decision. The team then, after some consultation with the Project Owners we came to understand that using OAuth for authenticating students would be the ideal solution.

As documented in the following research section, the team has undergone meticulous, methodical and elaborate research, to inform every decision. This was done to find the best possible way to implement all functionality of the authentication feature. Our research will ensure a well-defined path of execution, resulting in an effective end-product.

Research links:

Functional Requirements: This document displays our functional requirements.

Planning and different approaches to authentication: This document shows the different planning and thought process we used for deciding how to approach Authentication.

Working Mockup/UI design: This UI design allows for a better understanding and more practical view on the design.

Github upstream and forking tutorial: This youtube video allowed for the team to get a better understanding of how to use github and its many features.

OpenID Connect with NestJS: This webpage helped the team get a clearer view on OpenId and the commands to utilise it.

NestJS Documentation: This webpage assisted with using NestJS as well as its understanding of what the team could take advantage of.

GIT Commands: These Git commands were set up by Reece to help the team set up our repositories and speed the process up.

Formal Testing Plan: The final of the testing plan created by Johan for the team to see how he would be running his testing.

Proposed Testing plan (replaced by formal above): The rough draft of the testing plan created by Johan.

Software Requirements Specification: The documentation is the software Requirements specification created by Damian.

Repository Data-access: This document is the contract created by Leonardo about the functions created in the authentication features repository.

Contracts

Many other teams are using the Authentication features resources and API however the Authentication is not using any other teams data for our feature, as such all our work is independent of others.

Functional Requirements

FR1: Registration

The emails must also be checked to see if they are valid email addresses in use and not ‘dummy’ emails. The passwords of users need to meet a certain criteria for the users safety such as the passwords being a minimum 8 characters in length and containing at least 1 special character. The password also needs to be hashed and salted so the user's login details are encrypted and can not easily be stolen.

Input: Enter Email, Name, Surname, and create a password.

Process: Check the Email to be a student/company email and password follows standard.

Output: The user will be logged in.

FR2: Login

The login feature requires Email validation to ensure it is on the system for an existing user and that the email address is correct for a user. Login is done through OAuth to ensure it is a student Gmail account. Passwords must also be checked to be correct and correspond if the email address is valid. A forgotten password system could potentially be in place in the case that the user forgets their password allowing them to recover it to login. The login is set to be the front page of the graduate portal and as such must meet a decent quality and work without fault.

Input: Enter Email and Password

Process: Checks Email to ensure the user is registered and checks password to determine if it is correct to determine if it is the user.

Output: The user will be logged in to the portal.

FR3: Session Identification/Tokens/AuthGuards

Session identification can be put in place to ensure that users are not taken advantage of such as a hacker using their session ID to use the portal for malicious purposes. We could potentially implement refresh tokens to stop this as the hacker would only have a certain amount of time before the token expires and a new one needs to be issued. Provide an API to identify the session, that will allow for admins to check the session. When a user is logging in they will receive a JWT (JSON Web token) to authenticate them during their user session. The JWT contains data on the users session which will be sent to them for the duration of the session.

Input: (There is no input the user would log in)

Process: The user receives a session token

Output: There is no output unless the session times out which will state the user has timed out.

FR4: Google OAuth

Google OAuth was a necessary feature when logging in to use the portal. The email will be checked with OAuth to determine if the Gmail account is a University of Pretoria student account and not another Gmail account meaning that it is not associated with the University. If the account is a student account then the user will be logged in using Google OAuth. This allows for a better way of validating accounts and ensuring that only users who are students can create student graduate accounts.

Input: An Email is entered

Process: The Email is checked through Google OAuth to ensure it is a student of the University of Pretoria.

Output: The account will be allowed access to the portal.

Use case diagrams

Registration

Login

Authentication

Non-Functional Requirements

NFR1: View password button

NFR2: Login feedback

Quality Requirements

The Authentication features should reach a certain standard of reliability and availability when it comes to use. The features should be accessible at all times or at least while the graduate portal is active and the features should not fail in almost no circumstances. The registration, login and Session Identification should be secure and ensure that it will function as intended with no issues as this is the forefront of the portal which demands no errors to guarantee a good user experience. There should be as many guards as necessary to prevent human error as well as malicious tampering of these features. Through the use of Google OAuth we can help with achieving some these guards as only users who are registered students can login which will allow for better control over the system and keeping its users safe from hackers and data thieves.

Architectural Requirements

The system being created by the Authentication team had to investigate the various functions we needed to have in place. Using this we were able to look in to ways of implementing it which could be done through various components. Using a JWT token we could move it around from the the system to the user to allow them access to the graduate portal. Also using the already in place architecture created by Google OAuth with their login allowed us some flexibility in the ways of implementing the system in question as Google handled that function. The system required both free to use architecture and reliable resources that could be used without fail which were both satisfied through our choice of software.

Architectural Constraints

The architecture that we would use had to have some limitations or else most could fulfil the job required. Firstly it had to be open sourced or at least have a free option for the intentions we had planned for it. Second it had to be able to work reliably with sensitive data so there could be less chance of risk with all the data and give users some security over their data. Lastly the software had to be implemented inline with our features functions meaning it could only be used if it benefited the feature without doing too little for it to be justified in the system and also without it doing too much and it being a complete over estimation of what is needed.

Components/Services

We used components such as an API for the users login data, Google OAuth to handle the user logging in to the system and JWT tokens to be assigned to users when they had successfully logged in for a session. The Services provided by Authentication included providing a login and registration for users, session identification for users to be safer when using the graduate portal and through Google OAuth a safer way of authenticating users to be students of the University of Pretoria and prevent other non-students from logging in to use the students data.

Mr Reece Stephenson - u20431997

Project Manager, Designer Managed team Delphi by planning and scheduling meetings. I managed my team on GitHub, added them all to the organization and kept track of what each of my members were doing by using the Github boards that we created. I made sure they kept up a good working pace. Whenever a team member had problems I helped them get the right resources and information to be able to solve the problem. I communicated with my team on a regular basis in order to keep them up to date with changes to the repository. I spent time compiling documentation, and worked on my own tasks in a time-effective and efficient manner. I designed the login and registration pages by making the Initial wireframes of both of the pages, and turning these into mockups by using Figma. I added design documentation to the wiki and collaborated with all of the other designers to come up with the general design language of the website.

Mr Damian Vermeulen - u20538945

Business Analyst Created the Software Requirements Specification as the main document to better illustrate what team Delphi features with a better understanding of our thought process on the features. I have had one meeting with the other Business analysts that lasted 25 minutes and multiple meetings with the project manager 1 on 1 about current work for about 2 hours in total meeting time. Setup the Functional Requirements for the team on what our defined features are with another document being the Feature Suggestions when all teams were still presenting features forward for consideration, with the Feature Story to decide how we should get around authentication as a feature. I have also assisted the project manager with other documents and tasks when needed.

Miss Rebecca Pillay - u17016534

UI Engineer I created Structural Component Hierarchy Diagrams for each page of the login and registration system. This allows for easy translation of structure into code, once the UI Kit is established and Angular components are ready for integration. Placeholder Angular Palette and Angular Material Theme was established. Before the discussion with the UI Engineers, themes and palettes were created to hone skills using the respective frameworks and work towards a clickable system at the soonest possible time. I researched NGXS and implementation with authentication UI, paying close attention to cookies and how they will be dealt with in the registration and login process.

Mr Mohammed Moola - u18197729

API Engineer Created the authentication feature library with NX Implemented the initial resolver and configured it to work with the GraphQL schema. Typescript decorators are also implemented to generate SDL from the class definition, following the code first approach.
Configured entities using the ObjectType decorator to define properties that will be present in the database and graphQL schema. Hard coded data was used to display the properties of the API.

Mr Mxolisi Mkanzi - u18059326

Backend/Service Engineer Created the structure for the Backend. Implemented the entities, commands and queries that will be required for user registration and authentication. I also researched how tokens can be created for authentication using Passport from NestJS.

For sprint 2 I will be focusing on the implementation of user registration functionality and authentication that will create a token that will also be used by the authorization team for authorization. I am also planning to have a meeting with the authorization team to discuss what they would want from the token so I will implement the token generation in a way that will make the token to be used efficiently by the authorization team. We are also planning to talk to UP for authentication using Oauth.

Mr Leonardo Wessels - u17229457

Data Engineer Did Authentication Repository function contract documentation, this documentation defined the functionality that the database repository would provide while also giving information about attributes and issues with solutions or workarounds that are found. Created skeletons for the proposed functions in the authentication repository which will serve as a temporary guideline to help with the development of other features. Researched alternatives as back-ups to our proposed Redis implementation.

Mr Johan Smit - u20502126

Tester Created a proposed testing plan document to serve as a basis for the discussion in the Testers’ meeting. It outlines the phases that tests would be performed on code segments and provides additional information on the various testing that needed to be done. After discussing Logging Protocols with other testers, I compiled the following document and also added it to the wiki Architecture section. This document expands and adjusts the proposed plan above, to become a formal procedure for testers to follow in assuring code works and is of good quality. I assisted with research into various authentication techniques, how it can be performed and what can be used to accomplish our tasks. I compiled a document to assist our authentication team and to base further research and work off of.

Mr Tshegofatsho Motlatle - u17066736

Developer Operations I had a meeting with the CI/CD team and did Research and planning for the github actions scripts that would be used to test all code before any pull request would be made to the repository. Managing and reviewing pull requests on github to ensure that the pipeline remains intact while continuing to push code to the repository. A meeting with other developer operations to establish operational protocol for pull requests and breakage of the pipeline.

Acceptance Criteria

Authentication as a feature holds much importance in the scope of this project. This feature sets up users for the Graduate portal in which they will register, login and be assigned a session token. Authentication needs to hold a certain standard for it to be a functional feature that can be used well in the system that has been created.

• Registration must check to see if users are students of the University of Pretoria for the sake on integrity.
• Login must accurately assign the correct token to the user who has logged in.
• Users data must be secure during the registration to ensure it is not used maliciously.

Expanding on the feature

After completing the work of the authentication feature there are thoughts on what the following year will do to expand on the feature. With Authentication there are the goals to implement a forgot password feature for students to access their passwords. Another goal of creating 2-factor authentication for login to ensure a safer and more reliable system of confirming the user. The existing functions of the Login, Registration and session identification could also updated or expanded upon to create a better system than what was previously made. There are many options and methods to use for a new and improved take on authentication, future teams will need to research in to what can be done and present a better version of what currently exists.

UI Engineer

Component Structure Diagrams

Authentication Feature

In the Authentication feature we aimed to create a feature that would implement a login through Google OAuth, Registration and Session Identification using JSON Web tokens. All these functionalities could not be implemented completely in the time available.

Signed off by DPA Vermeulen