Versions Compared

Old Version 4

changes.mady.by.user Aiyan Jiang

Saved on

compared with

New Version Current

changes.mady.by.user Aiyan Jiang

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
languagejson
{
  "sub": "<username>",
  "role": "<user_role">,
  "context": "<hashed_cookie_context">,
  "iat": "<issue_date">,
  "exp": "<expiration_date">
}

Variable

Description

<username>

The username of the authorized user.

<user_role>

The role of the user.

<hashed_cookie_context>

The hashed context of the session. This will be compared to a sent cookie.

See the “Potential Vulnerabilities” section for more details.

<issue_date>

(Built-in to JWT) The date the token was issued.

Note that the date is the number of seconds since Jan 1 1970. This is the equivalent of the Javascript Date.now() * 1000.

<expiration_date>

The date the token expires.

Token Attainment

The method by which the token will be securely obtained by the Safe Places web app.

...

Scope

  • The Safe Places backend will not be handling the management of the user pool.

    I.E

    .

    there will be no /login endpoint that accepts a username and password and performs a local database lookup.

Token attainment will largely depend on the health authority. They may implement their own system for issuing JSON Web Token that we will have to adapt to.They may also control a separate user pool that the backend has to perform API calls on. This would mean issuing tokens would be within the Safe Places scope.To accommodate common methods of identity management, the Safe Places backend will enable compatibility with Lightweight Directory Access Protocol (LDAP) and/or Active Directory (AD).

  1. SPL Web App sends the username and password to SPL Backend.

  2. SPL Backend uses DN resolution based on the sent username.

  3. LDAP Server responds with the distinguished name (DN) of the user.

  4. SPL Backend runs the bind command to validate the DN and password.

  5. LDAP Server responds with either success or failure.

  6. If successful, SPL Backend issues a JSON Web Token with appropriate permissions to the client.

Gliffy
imageAttachmentIdatt81070414
baseUrlhttps://pathcheck.atlassian.net/wiki
macroId63b49637-55ad-4dda-ad10-ca4a4153f6c3
namespl_auth
diagramAttachmentIdatt81135274
containerId81134291
timestamp1590499574155

Potential Vulnerabilities

...

An attacker may steal the token from the authorized user and use it for nefarious purposes. To mitigate this attack, we will employ token contextualization.

  1. We generate a random string during the authentication phase and send it to the client as a cookie.

    1. The cookie must have the flags HttpOnly, Secure, and SameSite.

  2. We store a SHA256 hash of the random string in the token as context.

During token validation, we hash compare the token context in the token and compare it with the sent cookie. If they are different, then reject the request.

...