otio-llc / security

Advanced security solutions for custom enterprise web applications

TAS Security Stack

Advanced security solutions for custom enterprise web applications

Technologies

Quantum Protection

Protection provided by QuSecure

Multi-Factor Authentication

Authentication provided by iValt

Packages

• @trans-stat/node-mfa - Node.js ESM and CommonJS compatible wrappers for a variety of multifactor authentication methods.
• @trans-stat/auth-components - Web Components for user authentication UX patterns.

security's Issues

prototype sending authentication results to the frontend via websockets

Feature Request

Because of the async nature of users responding to auth notifications on their phone, we do not know when a request will be authenticated. In order to reduce network traffic, the server needs a way to send the response back to the client without the client constantly polling the server with requests.

This needs to be accomplished in a framework agnostic way as much as possible so that it can be integrated with as many application stacks as possible.

Expected Behavior

Current Behavior

Currently, the frontend needs to keep sending requests to the backend to see if there is a result of the biometric request. The backend also needs to keep sending requests to iValt's API, so whatever solutin we come up with will be to primarily mitigate the extra network traffic between the client and server using this library.

Possible Solution

On the frontend the browser websocket API is a good candidate. On the backend, a lightweight websocket library will most likely need to be used.

Context

Examples

fix: expiry notification in app not received on iPhone

Bug Report

Notifications do not expire as is common with many MFA solutions today?

Repro or Code Sample

Expected Behavior

Is this by design? What should be the expected behavior?

If a user taps on a notification that has passed the expiration time, the app should tell them that it is no longer valid, or the app could just remove the notifications for any expired requests.

Current Behavior

If requests do expire, it is not clear from a user's perspective using the app. Based on testing however, notifications that were at least an hour old could still be authenticated.

Possible Solution

Could this be a configuration option for branded apps, or organizations?
relates to #6

Context

Your Environment

• OS & Device: [e.g. MacOS, iOS, Windows, Linux] on [iPhone 7, PC]
• Browser [e.g. Microsoft Edge, Google Chrome, Apple Safari, Mozilla FireFox]
• Version [e.g. 1.8.0]

feat: add passkey item component

Feature Request

Expected Behavior

Current Behavior

Possible Solution

Context

Examples

add scaffolding to this source repository

### Tasks
- [x] add typescript
- [ ] add rollup
- [x] configure for monorepo using workspaces
- [x] setup build process
- [ ] add unit testing

prototype iValt implementation

### Code Tasks
- [x] Prototype backend API implementation
- [x] Add frontend FAST components
- [ ] Prototype frontend service layer (If any. Needs investigation on proper approach.)

### Research Tasks
- [x] Find out the best method for passing iValt API key to the backend class instance.
- [x] Determine how the UI elements are going to communicate with the backend in a generic, framework agnostic way.

Engineering Notes

The iValt implementation will be it's own package split into a backend component and frontend elements.

The backend component will be a simple javascript class wrapping the iValt API that can be instantiated. This will allow us to keep the implementation free of any framework opinions and able to be integrated into a wide variety of applications. Investigation needs to be done on how access to the iValt API key will be handled, but the two options currently are: passing the key to the class instance or adding the key to a .env file where the class instance can find it.

The frontend component will have a service class that can be instantiated or injected through a frameworks DI implementation if available. This class will handle the communication with the backend component. Another option here is to just document the API and provide code examples of communicating with the backend component in a couple of scenarios. The frontend component will also export a mini library of FAST components for displaying MFA UI.

The exact architecture of both the backend and frontend components might change once implementation is underway.

add issue templates to this source repository

Let's add the new issues to this source repository since it's public they should be based on what may be coming in from anywhere. I think our existing templates may work very well here as a starting point. Then we can modify for this scenario a bit more.

fix: user is unable to pre-validate before biometric test creating a potential vulnerability

Bug Overview

Investigate if new requests include a notification that confirms the device user’s intent to biometrically authenticate.

Bug Details

In the event that a bad actor gains access to a user's credentials and attempts to login as the user, it is possible for the user to accidentally approve of the authentication request in the iValt app because the app immediately tries to use the users' phone biometrics to authenticate. To mitigate this scenario, the app should first ask the user if they want to approve or deny the request before trying to authenticate with biometrics.

Steps to replicate

Tap on any biometric request notification from the iValt app to open the app and see that it tries to authenticate without any user input.

feat: add scripted data models to testing

Feature Request

We will have a new UX Pattern delivered as a Web Component that will easily onboard user front-end so consumers don't have to reinvent the wheel.

Seems logical that we may also provide a data model and api to hook into the Web Component that wires up any requirements thay may come from Security and Privacy Compliance perspective.

Expected Behavior

TBD

Current Behavior

Does not exist

Possible Solution

TBD

Context

Deliver a complete end to end security solution for identity management and the users access experience.

Examples

feat: how should we manage app user configuration defaults

In the event that a user does not have a mobile device with biometric sensors, they have other preferred methods of multi-factor authentication, or they want extra layers of security and fallback methods with which to authenticate, we need to come up with a list of other services or capabilities in order to provide user choice in applications that implement this package.

What level of app user configuration should be supported to opt-in to MFA?

• 1F: Username/Password option available through API (not an option with Otio as requires 2FA w/Veroway)
• 2FA: Username/Password option with text or email verification
• MFA: Username/password option with MFA using biometrics

Ideally, iVault includes API to support all of these opt-in options for users and/or based on application configuration with graceful fallback if necessary.

### iValt Tasks
- [ ] Work with iValt on existing capability.
- [ ] Work with iValt on any new capability.
- [ ] Work with iValt to improve existing product documentation and / or engineering docs.
- [ ] Associate this work item or tasks with iValt issues if approved by iValt on roadmap.

### TAS Tasks
- [ ] Update documentation around each of the above task
- [ ] Create example scenarios for each option
- [ ] Create wrapper capability for each scenario

feat: add frontend loader/waiting component for when a request is sent but not authenticated

Feature Request

A frontend component is needed to communicate with users that the application is waiting for them to authenticate via the iValt app, or other external MFA solution.

Expected Behavior

The loader should clearly communicate authentication status to both sighted and AT users.

Current Behavior

Possible Solution

Should be pretty simple and straightforward. The component needs to be configurable through slotted content and user existing components from AWC. Additionally, in order to make the loader component support good interop with other component libraries and frontend frameworks it should utilize the pending-task community protocol. FAST already supports this in fast-element

Context

Examples