Auth FSD

User Management#

Role Based Access Control#

• All users in the system must be assigned at least one role.
• The user’s role will determine their privileges, and each role will only be granted the minimum privilege required for the user to perform their tasks.
• Project manager or equivalent should create an access control matrix to enforce this requirement.

Separation of Duties#

• For any workflow in the system, the user initiating any application/request cannot be the user to approve the application/request

Activation/Deactivation of Users#

• For each user, there must be an “Status” column that tracks the status of the user’s account.
• The user’s “Status” can be one of the following:
  • “Active”
  • “Inactive”
  • “Void”
• User admins must be able to change the status of other users between “Active” and “Inactive”. 
  • User admins must not be able to change their own status.
• The “Void” status is reserved for users who have left the organisation. This status should be permanent, with no way for user admins to undo (unless agency requests otherwise).
• Changes to any user’s status must always be accompanied by remarks to give a reason for the change.
• Any change in the status of a user must be recorded in the application logs as well as the database for easy retrieval. Refer to User Related Logs and Reports for more information on logging.
• Upon login, the system must check the status of the user. Only active users can be allowed to access the system

Automated Deactivation of Users#

• The system must implement a scheduler service that automatically deactivates users who have not logged in for x days. This service should run once a day at midnight or a time when the system is not in use.
  • The time at which the service runs can be adjusted as per agency’s requirements.
• The logic for deactivation should check for user’s “Last Login Date” and “Last Activated Date”, and use whichever comes later.
  • Example: user A was deactivated by System after x days of inactivity. Admin B activates user A on day x+1. Assuming user A does not login at all, the system should only deactivate user A again on day x+91.
• Automated deactivation of users should only be done by the scheduler service. The system should not be deactivating users in any other way (Note: User admin can still deactivate users)
  • For internet users, this feature will likely not be required. Check with PM team and/or agency on this.
• Note: the application logs should contain enough information to tell us which user was automatically deactivated, why the user was deactivated and the time at which the user was deactivated. We should not need to check the database to find this information.
• Ensure that the application logs do not reveal any personally identifiable information (PII) .
• Bonus: Include a way to manually run the service at any time. 
  • Use a field in app settings or config to control the trigger time of the service.
  • A possible implementation is to add a field in the app settings that specifies a datetime. If the current time falls within a range from the specified datetime, the service should run once. Using this will allow us to manually run the service without modifying the default trigger time of the service.
    • This should be available in production, such that we do not need to make a deployment in order to run the service when we need to. It will also allow ad-hoc runs for emergency fixes without having to wait for the next scheduled trigger time.
  • This will also be useful during debugging.
  • Discuss with the project lead developer and devops team to figure out the best way to handle this for your project without needing to make a deployment.

Automated Voiding of Users#

• Most agencies should have their own HR system that keeps track of user job role changes, transfers and terminations.
• The application should integrate with the agency’s HR system and automatically void users who have left the agency.
• Note: the application logs should contain enough information to tell us which user was automatically voided, why the user was voided and the time at which the user was voided. We should not be checking the database to find this information.
  • Ensure that the application logs do not reveal any personally identifiable information (PII) .
• This feature may not be required if the agency does not want to integrate with their own HR system.

Authentication#

Generic Error Message#

• For login failures, the frontend system should show a generic error message regardless of whether userID or password is wrong. It should also give no indication to the status of an account. 

Throttling#

• The system should impose a limit on the number of invalid login attempts. This is to mitigate against denial of service (DoS) and brute force attacks.
  • When the limit is reached, the system should prevent the user from attempting to login.
• Throttling is especially important for internet facing systems. Please ask PM to check with the Agency if this is required. (This was implemented in CAAS - so we can get code samples for reference)

Session Management#

Logout#

• The system must implement an easily accessible logout button for the user to manually terminate their session at any time.
• After the user’s session is terminated, the user will have to perform another successful login in order to access the system again.
• The system must ensure that a terminated user session cannot be reused.
  • The back button in the browser must not be able to bring the user back to their previous session. It should instead prompt the user to login.

Force Logout on Web Browser Window Close Event#

• The frontend system should capture all web browser tab or window close events and take the appropriate actions to close the current user’s session before closing the web browser tab or window. 
• This should be equivalent to terminating the session manually via the logout button.

Session Timeout#

• The system should implement an idle timeout that will automatically terminate the user’s session if the user has been idle for more than the allowed idle time (e.g. 30 minutes)
• The frontend system should show a warning message for the session timeout 5 minutes before the session expires, to prompt the user that their session will be automatically terminated if they continue to remain idle.
• After the session timeout, the user should see a message which informs them that their session has been terminated due to inactivity.

Concurrent Sessions#

• The system should not allow concurrent sessions for a single user. Web browser tabs and windows should not share the same session.
• If a user has an existing session, the frontend system should display a prompt to inform the user of the existing session when they login successfully. On proceeding with the login, the existing session should be terminated.

General Logging#

Logging Levels#

• All application logs in the system must be written using appropriate log levels (e.g. Information, Warning or Error)
  • This allows easy filtering of the logs based on log level.
• Logs must not be written using “Console.WriteLine” or the equivalent.

Errors#

• Every error message in the system should be logged.
• Error messages displayed to end users should be in the form of a unique code, for example “ABC-DEF-00001”. Each error should be tied to a unique code.
  • End users should not see information other than the unique code.
  • Information leaked in error messages may be used by attackers to gain privileged information about the system. 

User Detail Changes#

• Refer to User Related Logs and Reports for more details.

Personally Identifiable Information#

• Application logs should not reveal personally identifiable information (PII).
• Nonexhaustive list of examples of PII:
  • Full name
  • Address
  • Email address
  • NRIC/FIN
  • Phone number
• When in doubt, check with PM team on whether the information being printed counts as PII.

User Related Logs and Reports#

• Any changes to a user’s details should be logged, along with relevant details such as:
  • Old and new values for details
  • Reason for the change
  • Datetime of the change
  • Responsible party for the change
• The change information should also be stored in the database for easy retrieval to compile in a report. The following sections will elaborate on the user related reports.

User Login Report#

• For all successful login attempts, record the following information in the database:
  • UserID
  • Login datetime
  • Session expiry datetime
  • Logout datetime (if user logged out before session expired)
  • IP address of user logging in
• Note on IP address: traffic from the browser often passes through many layers before arriving at the application. The commonly used “Request.UserHostAddress” in .NET will typically return the IP address of one of these layers and not the IP address from the user’s browser. In most cases, the IP address of the browser will be propagated using a custom header. This may differ between projects, so check with the devops team on how to retrieve the browser’s IP address for your project.
• If the system has both internet and intranet users, store the information for internet and intranet separately.
• The system should provide an interface for admins to retrieve and view the user login report.
• The user login report should contain the following fields:
  • Username
  • User role
  • Login datetime
  • IP address
  • Environment (if applicable)

User Failed Login Report#

• For all failed login attempts, record the following information in the database:
  • UserID
  • Attempted login datetime
  • IP address of user attempting to login
  • Error message
• Note on error message: login functionality is normally provided by 3rd party services such as Singpass/Corppass (SPCP) or Active Directory (AD). All information and errors from 3rd party services should be recorded.
  • For example, SPCP APIs may return errors such as “invalid_request” or “unsupported_response_type” along with an error message. Such errors and error messages should be recorded both in application logs and the database.
• If the system has both internet and intranet users, store the information for internet and intranet separately.
• The system should provide an interface for admins to retrieve and view the failed login report.
• The user failed login report should contain the following fields:
  • Username
  • User role
  • Attempted login datetime
  • IP address
  • Environment (if applicable)

User Active/Inactive Report#

• For all changes to any user’s status between “Active” and “Inactive”, record the following information in the database:
  • UserID of user whose status is being modified
  • User’s last login datetime
  • User’s updated status
  • Action (activate or deactivate)
  • Action datetime
  • Action by (userID of admin making the change or System)
  • Remarks (By user or system. Remark for system can be “Deactivated after 90 days of no activity”)
• If the system has both internet and intranet users, store the information for internet and intranet separately.
• The system should provide an interface for admins to retrieve and view the user active/inactive report.
• The user active/inactive report should contain the following fields:
  • Username
  • User role
  • User last login date
  • User current status
  • Action
  • Action datetime
  • Action by
  • Remarks
  • Environment (if applicable)

User Role Change Report#

• For all changes to any user’s role, record the following information in the database:
  • User ID of user whose role is being changed
  • User’s old role
  • User’s new role
  • Datetime of the change
  • User ID of admin making the change
  • Remarks (admin to enter reason for change)
• If the system has both internet and intranet users, store the information for internet and intranet separately.
• The system should provide an interface for admins to retrieve and view the user role change report.
• The user role change report should contain the following fields:
  • Username of user whose role is being changed
  • Old role
  • New role
  • Datetime of change
  • Action by (username of admin making the change)
  • Remarks
  • Environment (if applicable)

New User Report#

• For all new users added to the system, record the following information in the database:
  • User ID of new user
  • New user’s role
  • Created By (userID of admin creating user or System)
  • Created Datetime
  • Remarks (admin to enter reason for creating user)
• If the system has both internet and intranet users, store the information for internet and intranet separately.
• The system should provide an interface for admins to retrieve and view the new user report.
• The new user change report should contain the following fields:
  • Username of new user
  • New user’s role
  • Created By
  • Created Datetime
  • Remarks
  • Environment (if applicable)

Void User Report#

• For all users voided in the system, record the following information in the database:
  • User ID of voided user
  • Voided By (userID of admin voiding user or System)
  • Voided Datetime
  • Remarks (admin to enter reason for voiding user. Remark for system can be “User has left agency. Voided by system” )
• If the system has both internet and intranet users, store the information for internet and intranet separately.
• The system should provide an interface for admins to retrieve and view the void user report.
• The void user change report should contain the following fields:
  • Username of voided user
  • Voided By
  • Voided Datetime
  • Remarks
  • Environment (if applicable)