Home - ryangurn/auther GitHub Wiki
up until this point each and every one of the applications developed for personal use have had authentication at the core. this projects main goal is to factor out the authentication core code that complicates each of those applications. currently applications all have separate requirements for authentication. some need a first and last name while others just use a combined name, so this process will not be simple.
the motivation for developing this system is mainly to introduce simplicity into the process of developing a microservice that relies on authentication. from the current situation section, we can see the fragmentation the methodology currently used. to improve the current situation we will effectively remove the requirement of authentication from any other microservice's requirements and keep it all nice and tightly integrated within the auther microservice.
the auther system will provide a simple web and api interface for user management, permissions management, api data management, and any other authentication related features. the vision is a single location to handle authentication similarly to active directory does for windows, but in a better way (hopefully). this system will be a unified dashboard that will allow any user to easily handle various tasks described below (such as user provisioning). this application will be build using Laravel and should have futureproof code structure so that modifications can easily be made. additionally it will be imperative that maintenance of this system after development is simple and follows framework and industry norms.
- default: this group of users will have very limited access to application, mainly just as a reference for their own account information. these users can change their personal information, view their provisioning, and access only personal information from the other features. there will be no access to oversight features, just personal features.
- administrator: this group of users has access to personal features (for modification of their own user) as well as oversight features (which allow for administration of users and their provisioning).
- super: this user group has extra access to auther specifically to view debugging information and logs.
- normal: the normal mode will be for personal information access. in essence this is where each user can view their own information (such as name, address, email, & provisioning). users in the normal mode will be able to edit their names, address, and email however they will not access provisioning.
- admin: the admin mode will provide access to the management side of this application, provisioning, api management and more.
Brief Description: this case describes how a normal user would access their personal information within auther and update said information.
Actors: a normal default user
Preconditions:
- the person who is attempting to change personal information already has an account login.
- the user has at least user provisioning within auther.
Steps:
- login to auther
- click on profile link/icon in a navigation bar
- see a listing of personal information
- click a button to edit the information.
- provides new information
- saves the personal information back to the system
Postconditions:
all of the new information provided will be stored back into the database for future use, the user will receive an email stating that there have been updates to personal information in auther.
Brief Description: this case describes how admin users would be able to create a new account within auther.
Actors: an administrator or higher
Preconditions:
- the person who is attempting to create a user must have some information about the user to create.
- name
- birthdate
- (optional) phone number
- (optional) address
- the person who is creating the account must not provide any information regarding password
- the person who is creating the account can specify the accounts security level (ie: normal password, security questions, 2fa).
Steps:
- login to auther
- navigate to the user management area.
- select an option to create a new user
- provide the required user information
- select a button to create the new user
Postconditions:
the information provided will be used to create a new account, and the new user will receive a welcome and setup account email. the user might be required to validate their email.
Brief Description: this case describes how an admin user would be able to reset the password for another user.
Actors: an administrator or higher
Preconditions:
- the requestor must know their own password to request the resetting of a password for any user.
- if 2fa or security questions are enabled the user (whose password is being reset) must provide additional information.
- the account holders birthdate might be requested
- details about the account access might be requested.
Steps:
- login to auther
- navigate to the user management area.
- select the user that you want to reset the password for
- provide current users password to confirm authorization
- email sent to user (whose password was reset) to provide new information
- user will provide new password to their account via auther
Postconditions:
the admin user will have completed the request for a new password, the user will have provided the new password along with additional security information.
Brief Description: this case describes how an admin user would be able to update a single user's account information.
Actors: an administrator or higher
Preconditions:
- a users birthdate can only be changed up to 3 times.
- a users email can only be changed at most 4 times per year.
- after enabling 2fa, there is no way to turn it off after 2 weeks of it being enabled.
- changing the phone number will not affect trusted phone numbers and devices
- updating security questions will not be possible by administrators
- the administrator will need to know the updated information that they wish to submit
- name
- birthdate
- phone number
- address
Steps:
- login to auther
- navigate to the user management area.
- select the user that you want to update information for
- fill in the new information
- select a button to save the new information
Postconditions:
the users information will be updated and saved back to the system. depending on that users notification settings they may receive an email.
Brief Description: this use case describes how an admin user would be able to update many users at the same time.
Actors: an administrator or higher
Preconditions:
- the administrator will need to have a normalized file of the updated content (something like a csv or xlxs)
- the administrator will only be able to edit the following fields for each user
- name
- email (up to 4 times per year)
- birthdate (up to 3 times total)
- phone number
- address
- changing the phone number will not affect trusted phone numbers and devices
- changing the email address will require an email verification
Steps:
- login to auther
- navigate to the user management area.
- click a button to upload a bulk file
- view headers from file and match with system attributes
- view single paginated view of changes before applying
- click button to apply all changes, or cancel
Postconditions:
the information for each of the users updated will be stored back to the system, this information will start being used as actionable information after verification of phone, and email.
Brief Description: this use case describes how an admin user would go through the process of deleting a user
Actors: an administrator or higher
Preconditions:
- the administrator will be asked to provide their password to verify the deletion
Steps:
- login to auther
- nagivate to the user management area.
- click update on the user that is being deleted.
- find the delete user section and click delete.
- provide password to confirm
Postconditions:
the user will be deleted from the system along with all related metadata, all access for that user will be revoked.
Brief Description: this use case describes how an administrator would change the roles of multiple users at the same time.
Actors: an administrator or higher
Preconditions:
- the administrator must know all the users that they desire to change the role for.
Steps:
- login to auther
- navigate to the user management area.
- click on the checkbox to the side of each user to update roles for
- click 'update roles'
- the administrator will see a list of selected users and be able change roles
- click on an update button
Postconditions:
the users will all have updated roles and thus different access to this system along with the various connected microservices.
Brief Description: this usecase describes how an administrato would create a new role within auther
Actors: an administrator or higher
Preconditions:
- the administrator has a name in mind for the role
- the administrator knows the permissions that they wish to assign to the role
Steps:
- login to auther
- navigate to the role management area
- in the roles panel click on a create button to create the role
- the user will be prompted with a form asking for the following information
- Name of the role
- Permissions that are applied to the role
- the user will need to click a create button at the bottom of the form to save
Postconditions:
the new role will be created and each of the selected permissions will be applied to the role, any users that end up having this role will have the permissions that are applied to the role.
Brief Description: this usecase describes how a user would add a new permission to a role after a role has already been created in the system.
Actors: an administrator or higher
Preconditions:
- the administrator will need to know which role they which to add a permission to
- the administrator will need to know which permission(s) they wish to apply
Steps:
- login to auther
- navigate to the role management area
- in the roles list select update in the row that corresponds to the role desired
- on the update page there will be a section to apply a permission to the role
- select the permission(s) that need to be applied
- the user will need to click a save button to apply the changes
Postconditions:
the permission(s) will be applied to the role within the system and in tern all users that have the role will now have the updated permissions.
Brief Description: this usecase will describe the process of updating a roles information, such as the name or guard.
Actors: an administrator or higher
Preconditions:
- the administrator will need to know which role they wish to update
- the administrator will need to provide the following information
- a new name
- a different guard that the role applies to
Steps:
- login to auther
- navigate to the role management area
- in the roles list select update in the row that corresponds to the role desired
- on the update page there will be a section to update the roles basic information, the administrator will need to provide the updated values
- then to save changes there will be an update button.
Postconditions:
the updated role information will be saved to the system and immediately take effect within the role system.
this section of uses cases is a work in progress, and will be filled in later. there needs to be more thought put into this section of the application before committing to anything.
- provide core authentication services to a variety of microservices that are connected throughout the system
- provide a simple rest api for management of user controls. this effectively will provide simple automation techniques using normal programming languages
- provide flexibility of responses to ensure that applications with different data needs can easily be handled.
- setup provisioning services that work throughout the variety of microservices that are connected
- add a management portal for authentication services (including user management, roles and permissions management, api data management, and more)