IT:AD:Non-Functional Requirements:Security

• (UP)
• See also:

  • IT:AD:Non-Functional Requirements:Qualities

The following requirements are broken down into:

• Functional Requirements/
• Technical Requirements/

• [NFR:8mr34:MUST] Records of Session activity (Session Start, LastAccess, Logout, and UserAgent IP) must be kept for auditing purposes (see [NFR:8mr38]).

  • Rational: (Auditability/)

• [NFR:8mr38:MUST] Session activity (see [NFR:8mr34]) will be kept for a minimum of 7 years.
  • Rational: (Auditability/)
• [NFR:8os3m:MUST] The Audit entries must not contain a record of the user's Login name, Password, or Email address.

  • Rational: in case your database is breached, it should not disclose information that may be valuable on other sites, such as user's username, which often is the same on many sites.

  • An entry can contain a reference to the Primary Key of a User table entry.

• [NFR:8pvf8:SHOULD] Each operation performed should increment a counter.
  • <div nav>
• (UP)

  • IT:AD:Non-Functional Requirements:Compliance
  • IT:AD:Non-Functional Requirements:Full List
    • IT:AD:Non-Functional Requirements:Full List:Import
    • IT:AD:non-functional_requirements:Full List:Safe Copy
    • IT:AD:non-functional_requirements:full_list:Editable
    • IT:AD:non-functional_requirements:full_list:Searchable
    • IT:AD:non-functional_requirements:full_list:Test
  • IT:AD:Non-Functional Requirements:Localisation
  • IT:AD:Non-Functional Requirements:System Requirements
  • IT:AD:Non-Functional Requirements:UX
    • IT:AD:Non-Functional Requirements:UX:Web
    • IT:AD:Non-Functional Requirements:UX:Web Server
  • IT:AD:Non-Functional Requirements:APIs
  • IT:AD:Non-Functional Requirements:Data Migration
  • IT:AD:Non-Functional Requirements:Data Storage
  • IT:AD:Non-Functional Requirements:Documentation
  • IT:AD:Non-Functional Requirements:Maintainability
  • IT:AD:Non-Functional Requirements:Monitoring
  • IT:AD:Non-Functional Requirements:Qualities
  • IT:AD:Non-Functional Requirements:Security
  • IT:AD:Non-Functional Requirements:Technical Requirements
• <div nav>
• [NFR:8pvf9:SHOULD] If the number of operations performed during a session (see [NFR:8pvf8]) reaches specified thresholds, sysadmins should be notified, or begin specific workflows (see [NFR:8mr36]).
• [NFR:8mr36:MUST] System Administrators must be able to force users offline.

  • Rational: if improper activity is spotted while the user is still logged in, any potential damage caused by operations made by the user should be minimized.

  • Note that technically this can be easily be achieved as long as Sessions are being managed not by cookie duration, but by Server information.

  • Note that this is only be automated if Operations/Session (see [NFR:8pvf8]) are being counted.

• [NFR:8mr2z:SHOULD] Application should use an external identity service to authenticate identities.

  • Rational:(Security/).

• [NFR:8mr37:MUST] Be able to count how many online users (ie, within timeout period, and not yet logged out).

  • Note that this is only possible if * [NFR:8mr39:MUST] Organisation must have Attributes associated to it. * [NFR:8mr3a:MUST] User must have Attributes associated to it.

    ### Unsorted ##

    To go through and classify or discard:

    • [NFR:8qq5:MUST] All Authentication Attempts must be Audited.
    • [ ] [NFR:w2hu:MUST] Authentication Attempts Audits must contain:

      • AuthenticationAudit.Id (Custom Sequential Guid)

        • The reason for using a Sequential Guid, custom generated, has been demonstrated elsewhere.

      • AuthenticationAudit.CreationTimeInUTC (Time the Authentication Attempt occurred, in Utc)
      • AuthenticationAudit.UserAgentIP (IP of user's client).
      • AuthenticationAudit.SSOProtocol (OAuth, SAML, etc.)
      • AuthenticationAudit.SSOService (Google, Facebook, Corp, etc.)
      • AuthenticationAudit.Success (true|false)

      * [ ] [NFR:tuex:MUST] Time of Session start must be audited.

    ## Technical Design Requirements ##

    ### Security ### * [NFR:8ov5e:MUST:] Session Tokens must not contain authentication information directly.

    • Rational: cookies can be intercepted. Given enough and benefit, and time, the contained within may be read. It should not contain the user's username, password – only the Session Id, which is used to retrieve the Session record, from which the User can be retrieved.

    * [TS:8orzb:SHOULD] The Session Token Cookie should be Session based, unless specified otherwise.

    • Browsers no longer automatically destroy Session cookies in the same way as they used to. If the chrome://chrome/settings/ for “Continue where I left off” is set, cookies are not destroyed when a browser is closed in order to provide a seamless restart. ^{1)2) 3)}

    * [TS:8orzc:MUST] If a Remember Me function is to be offered, it is not to be done by converting the Session Token Cookie from a Session Cookie (see [TS:8orzb]) to a short expiry cookie. * [] If a Remember Me function is to be offered, it is as a second cookie, with 'secure' and 'http ⁴⁾

    • The RememberMe cookie is used to issue a new Session Cookie

    • The RememberMe cookie is to issued for as short as practical duration (eg: 7 days): the longer the expiration window, the larger the attach opportunity

    * [TS:8os23:MUST] When using an SSO to sign in, and a “Remember Me” feature, the “Remember Me” option must be selected before the user clicks the provided link to the SSO Authority.

    • Rational: if the application does not have an indication of what type of Cookie to create when returning from the SSO, the Application Session Token Cookie will always be a Session based cookie.

    * [TS:8os24:MUST] If a Remember Me feature is offered, the logged in user's dashboard must offer an Action to log out of the remote SSO Authority.

    • Rational: if this is not the case, and the SSO Authority upon seeing a Session Cookie from its own domain automatically redirects users back to the application without showing them an Authentication Form, the user will not be able to change Identity for a duration equal to the validity of the SSO Authority's Session Token.

    ### X ###

    • [TS:8mr3b:MUST] User Attributes (Claims) are stored in an external SSO/ solution.
    • [TS:8mr3c:MUST] In-Application User record is permanent, therefore must be small to not take up too much space over time.
    • [TS:8mr3d:MUST] The User table has it's own autoincrementing Identifier,
    • [TS:8mr3d:COULD] The User table should also keep a copy of the SSO's Reference Id.

      • This may be used when using SSO/ to sign in to another server.

    • [TS:8mr43:COULD] The User table should keep the last known Email address and user name, retrieved from the Session IIdentity.

      • Having a name and email of other users than oneself (which one could retrieve from the Session Identity) to display on the screen is important for UX reasons.

      • Having a Preferred Contact Method (Ext. Cell, etc. and Preferred Contact Info is also useful to quickly get in touch with someone – but not all apps have that kind of information available. And it is a security concern that needs to be weighed.

    • [TS:8mr3e:MUST] Session and SessionLog are kept separate (SOC/).

      • Session is temporal and prunable, whereas SessionLog being permanent.
      • The LastActiviyDateTime is checked and optionally updated at the begining of each request as follows:
        • SessionLog.LastActivyDateTime is updated using pseudo code similar to the following:
          • UPDATE SessionLog SET LastActivityDate=? WHERE UserFK=? AND AND LastActivityDate > GETDATE(-20minutes) AND LoggedOut = null
          • if the returned RecordsUpdated=0, then the session is no longer valid.
          • if it is, and the Application IIdentity Cache is empty, it retrieves it from the Session table.

      * [TS:8mr3f:MUST] In-Application Session record, containing the serialized IIdentity/, so that it can be used in other load balanced servers and tiers. As per general caching strategies, it is serialized in the shape closest to final use – the IIdentity.

    • [TS:8mr3g:MUST] The session information must be prune-able to reduce data requirements.

      • If the Session and SesionAudit table are combined, the Session's Identity column can be cleared.

      • If the tables are separate, the Session table can be pruned of stale records as needed.

    • [TS:8mr3h:MUST] Auditing of login information must be permanent (+7 years),

      • Due to the length of time the records are kept, it must be light in terms of storage requirements.

    • [TS:8mr3i:MUST] Application must provide for reporting purposes information (numbers, and where possible capabilities) of the User Agent/ used to access the application.
    • [TS:8mr3j:SHOULD] Be able to be use Sharding/.

      • Under hi loads, session tables – specifically both the preferences and referential integrity on the User.Id – become a bottle neck to applications, and need to be sharded. That's a discussion unto itself.

    • [TS:8mr3k:COULD] UserPreferences table schema can be simple – or capable enough for the concerns addressed in XActLib/'s UserPreferences services.
    • [TS:8mr3l:MUST] Organisation must have Attributes associated to it, that do not need a schema change to add/remove settings.
    • [TS:8mr3m:MUST] User must have Attributes associated to it, that do not need a schema change to add/remove settings.
    • [TS:8mr3n:MUST] User table records will never be removed.

      • Removing records from the User table would cause LoginLog records to point to missing user (or worse, trigger a cascading delete, if implemented).

    An example of the entities required to fulfil the above requirements:

    SVG | PNG | TXT

    ## Resources ## * Class Diagrams