ecadlabs / auth Goto Github PK

Add the concept of "Service Accounts" that are used by other systems, tools or scripts to authenticate with the auth daemon. Upon succesfull authentication, the auth daemon would issue a typical JWT token. Downstream services that validate the JWT token with have little to no variation in how they process requests for a Service account or a User account.

Service accounts are similar to users account:

• They are assigned to a tenant
• They have roles and permissions
• They have a valid email address (for JWT consistency reason), but may not be expected to be active. ie. It isn't expected to receive or process email.
• They can authenticate through the login endpoint

The main difference with the user account is the that they don't have a password instead they can be authenticated by one of the following methods:

• They can be authenticated by whitelisted IP address
• They can have a never expiring JWT token which acts as an API key

Machine account can be managed by a regular user who has the permissions to do so.

Remove the following command line flags;

• base64_secret
• gen_secret
• bcrypt

We don't need these features, for password generation, it can be done outside of the auth deamon.

Enforce golint by adding it as a check to CI.

Add the concept of tenants which is basically a way to scope role and permissions for accounts

The main benefit of this will be to create multiple teams/organisation for a saas product for instance. While we don't want to force users to have a different account for each team they join, we also don't want to bloat JWT with roles from each different team a user belongs to. From the user perspective, it will allow them to login to multiple teams with the same login.

For this feature we want the auth API to issue JWT on a per-tenant basis.
One way we could do this is by returning a JWT for each tenant a user belongs to or support tenant-based login.

This also introduces the need for superuser which can manage tenants and users that does not belong to any other tenants. This could be implemented as a root tenant, for example.

NB: Users remain a global concept, but their permissions will now be scoped by tenants and a user can belong to multiple tenants

The main things to implement are

• Return a JWT per tenant for the /login endpoint
• Add a /tenants endpoint to manage tenants with basic CRUD operation
• Add a way to invite users to join a tenant
• Add a way for user to know which tenants he/she belongs to

The auth service and services that consume JWT tokens, must share a secret.

The auth daemon has a -secret command line flag that is used in dev/testing.

Add support to the auth daemon to use HashiCorps Vault to share secrets between vault and JWT token consumers, as well as rotating secrets.

https://github.com/hashicorp/vault

• Create a docker-compose-vault.yml file that starts a vault instance in developer mode, and configures auth daemon to use vault.
• Add config block to yaml config parser/structs for Vault.

As a NOC screen, I want to display a status page without logging in so that when I boot up, I load a URL and the desired page loads.

Add a command line param -permittedIPs "10.0.0.0/24,192.168.88.1/32" to the daemon.

If a GET or POST request to /login is received, check the source IP address against the permittedIPs list. If the source address falls within the CIDRs specified, then issue a JWT token with the role of iplogin

This functionality replaces the old /checkip kludge.

The duo.com API requires the following properties to authenticate an application

• Integration key
• Secret key
• API hostname

You can learn more about them here: https://duo.com/docs/authapi-guide

We would like to add it to our current config.yaml file under a property called duo_2fa
The schema could look like this

duo_2fa:
    integration_key: <INTEGRATION_KEY>
    secret_key: <SECRET_KEY>
    api_hostname: <API_HOSTNAME>

We might want to allow storing the secret using HashiCorp Vault when #7 is ready

In the deployment scenario where authd is the backend that issues JWT tokens for two or more distinct web properties.

Assume for this example we have two sites;

• siteA.com
• siteB.com

And each one uses a single authd as it's JWT issuer.

When a user logs into siteA, the JWT token should use siteA.com in the issuer (iss) field.
The frontend should use siteA.com for /refresh operations.

The same logic applies to a user visiting siteB.com

The sites may have different configuration requirements, therefore, we want to configure the following parameters on a site specific basis;

• SessionMaxAge/max_age
• ResetTokenMaxAge/reset_token_max_age
• TenantInviteMaxAge/tenant_invite_max_age
• EmailUpdateTokenMaxAge/email_token_max_age

https://codeclimate.com has a free offering for OSS projects, and provides good value. Set up codeclimate to run against the ecadlabs/auth project.

Add two factor authentication support to that auth daemon using Duo.com

Supporting documentation:

https://duo.com/docs/authapi-guide

• Duo support can be enabled/disabled using a config file flag.
• Enrollment flow that displays QR code. User is expected to install or already have installed the Duo mobile app.
• Ability for an existing user account to enable 2FA (Clarification of flow/policy needed)
• Add a duo_2fa property to config.yaml

duo_2fa:
    integration_key: <INTEGRATION_KEY>
    secret_key: <SECRET_KEY>
    api_hostname: <API_HOSTNAME>

We might want to allow storing the secret using HashiCorp Vault when #7 is ready

Unknowns/needs research

Can we manually add accounts in Duo, and they match up to users based on email address? There's an enroll endpoint allowing users to match their duo account with our (this) application.

As a developer
I want to be able to make richer query against the api
In order to have more control on the api results

Right now the api the result from the api is the intersection of each criteria. Some use case require to have union of each criteria, therefore it would be nice to have the api support a richer query language

We will use getpostman.co to manage our OpeanAPI v3 specs.

The service supports integration with github, see: https://learning.getpostman.com/docs/postman_pro/integrations/github/

Which should allow us to store the spec in github.

• Update to angular v7
• Address security warnings from npm audit
• Setup CI to build angular components
• Setup CI/CD to publish angular components
• Setup browser integration testing using [browserstack.com? / https://saucelabs.com/? / other?

• CI/CD docker builds
• CI/CD npm builds
• NPM security checks & update packages with security issues
• README
• License