The management of Authentication, Authorization, and Auditing of Users and Organisations is fundamental.
The following requirements are broken down into:
Rational: (Auditability/)
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.
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.
Rational:(Security/).
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:
The reason for using a Sequential Guid, custom generated, has been demonstrated elsewhere.
* [ ] [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.
* [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 4)
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 ###
User table has it's own autoincrementing Identifier, 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.
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.
Session and SessionLog are kept separate (SOC/).Session is temporal and prunable, whereas SessionLog being permanent.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 = nullRecordsUpdated=0, then the session is no longer valid.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.
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.
Due to the length of time the records are kept, it must be light in terms of storage requirements.
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.
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:
## Resources ## * Class Diagrams