UC1::Logon
Overview
This use-case describes the sequence of events necessary to logon to the system
Document History
  1. Current Version1.8
  2. 1.1odlingsmee; 01 Jan 2006 ; Initial Revision
  3. 1.2odlingsmee; 23 May 2006 ; Upgraded to version 0.2
  4. 1.2odlingsmee; 07 Aug 2006 ; Added new alternate flow for scenario where max attempts has been exceeded.
  5. 1.4odlingsmee; 19 Mar 2007 ; Upgraded to version 0.3
  6. 1.6odlingsmee; 29 Sep 2009 ; Fixed condition for exhausted attempts alternate flow.
  7. 1.7odlingsmee; 17 Jan 2010 ; Assigned to release-1
Properties
  • TriggerThe actor wishes to access the web application
  • GoalFor users to gain legitimate access to the system
  • Primary ActorUser
  • Pre-RequisitesThe user shall be previously registered with the system such that appropriate security credentials are held by the system.
  • Success OutcomeThe user will have logged on and be granted access permissions as dictated by the configuration in the system.
  • Failure OutcomeThe user will not have been granted access to the system - a security administrator will have been informed of repeated failures.
  • Priority1
  • Complexity1
  • target release release-1
  • Packagesecurity
Basic Flow
  1. The user navigates to the [RQ13] web logon screen.
  2. The system [RQ3] challenges the user for a [RQ1] username and [RQ2] password.
    3. odlingsmee;; 2006-01-21
  3. The user enters their credentials and submits them to the system.
  4. The system validates that the username and password credentials match those stored.
  5. The system loads up the set of [RQ7] privileges appropriate to the user.
  6. The system presents the homepage to the user.
  7. The use-case ends.
Alternative Flows
Accessing a protected page directly

At step 1 of the Main flow when The user attempts to access a protected resource but is not logged on or their session has expired

  1. The user navigates directly to a screen within the system website
  2. The system re-directs the user to the logon screen.
  3. The flow of events continues from step 2 of the Main flow.
Invalid Credentials

At step 4 of the Main flow when Credentials supplied are not valid

  1. The system determines that the user is still within their [RQ5] permitted logon attempts
  2. The system re-directs the user to the logon screen.
  3. The flow of events continues from step 2 of the Main flow.
Invalid Credentials - number of attempts exceeded

At step 4 of the Main flow when Credentials supplied are not valid and permissible number of attempts exceeded

  1. The system determines that the user has exhausted their [RQ5] permitted logon attempts
  2. The system re-directs the user to an authentication failure screen.
  3. The system alerts the administrator of the failed logon attempts.
  4. The use-case ends.
Specific Requirements
  • [RQ13] Web UI:The user interface shall be a web based ( HTTP ) user interface to ease deployment and accesibility. (agreed)
  • [RQ3] Authentication:shall be established based on the correct username and password combination. (agreed)
  • [RQ1] Unique Username:The system shall identify users via a unique username. (yes)
  • [RQ2] Password:The system shall store passwords against each username. (agreed)
  • [RQ6] SSL Encryption:The system's website should support SSL Encryption to prevent data being sniffed by malicious parties. (proposed)
  • [RQ7] Authorisation:The system shall store permissions against each user such that their level of access to the system can be controlled. (agreed)
  • [RQ5] Failed Logons:If a logon attempt is unsuccesful the system shall inform the user, however specfic reasons for the failure shall not be communicated as this information can prove useful for malicious authentication attempts. (agreed)
Activity Diagram