The auth from trustbloc

Implement SSO - Single Sign On as authentication service

~~service must return same identifier when same user login.~~

Service must return the same identifier for the user/client combination. The user's identifier remains stable for each client but is different among clients.
Service successfully authenticates user to a client only for as long as the user has consented to it (or is it of one time use?)

OIDC Implementation - Handle the callback for Google provider

Initiate bootstrap service on login

BDD tests with Hydra

Could not be added at this time because Hydra is not set up in the BDD tests.

setup UI endpoint to serve the UI

PR #37 is adding the UI stuff but not actually serving it.

This is a followup for task #19 : need to redirect the user to the UI endpoint when finished handling the OIDC callback. The redirectURL should contain a handle of some sort that can be used by the UI to fetch the user's bootstrap info and offer it to the wallet via CHAPI.

Implement OIDC request as per different OIDC provide

(ie. use a different client_id, etc.)

Bootstrap: Add storage provider command line flags

Validate OIDC client making the request

During the /login flow, need to ensure the relying party wallet has been registered.

Setup Auth service - Open ID Connect

https://wiki.securekey.com/display/BLOC/Authentication+server+-+Open+ID+Design

Create mock login UI

just proper request and respnse, but mock the response to be success always,

Bootstrap: Add client that can be used in other projects

support multiple OIDC providers

Update to Go 1.15

OIDC implementation for GitHub

Handle the login request
- id token the sub inside the token should be stable per client id atleast
Handle the callback

Validate oidc request scope

prepare bootstrap data

hydra configuration script

The exit code for the hydra command invocation is not checked, therefore the hydra configuration script always succeeds whether the command failed or not.

To aid troubleshooing, we should check the exit code and fail properly.

Make TLS optional

If the cert/key path are not passed to the container, it intermittently fails without a clear cause. Breaks the expectation of the cert/key parameters being optional.

Error: open : no such file or directory

make session cookies max age configurable

Similar to trustbloc/wallet#388

Setup Vue project

Release v0.1.6

Bootstrap: Add "retrieve profile" endpoint

Enable oidc client registration in hub-auth

Hub-auth will act as oidc provider as well where the client like kms will registerr the application
Before using hub-auth with your application, you must register your application with the service. This is done through a registration form in the “developer” or “API” portion of the service’s website, where you will provide the following information (and probably details about your application):

Application Name
Application Website
Redirect URI or Callback URL

Once your application is registered, the service will issue “client credentials” in the form of a client identifier and a client secret.

Bootstrap: Create store on startup

configure cookie auth and enc keys

Accept plain OAuth2 Bearer Tokens, not base64-encoded

I still believe that RFC6750 mandates the base64-encoding of the access_token in the Authorization header but after further research into it I've realized that many if not all vendors process the token in plain form (more precisely, in the same format, byte-for-byte, as was delivered in the access token response (RFC6749 section 4.1.4)).

Client components impacted by this change are:

https://github.com/trustbloc/hub-auth/blob/413a3517d5d5a373780c7f55d7f866456db5a31a/pkg/restapi/operation/operations.go#L806-L833

Setup Configuration API

Instead of starting the one oidc client , this api will provide the crud operation to create the multiple oidc clients .. like google . apple, twitter etc

User devices store

Followup to PR #57 .

We need a new store for the user's devices. The user's devices are not part of their bootstrap data.

When a user logs in using their device ("wallet unlock"), the user's device info will serve to locate the user's bootstrap profile, which will be served back to the wallet.

Expiration on access_tokens

Implement a configurable policy for access_token TTLs.

OIDC implementation for Microsoft

Handle the login request
- id token the sub inside the token should be stable per client id atleast
Handle the callback

Customizable log level using edge-core logging

Setup Hydra to implement authorization code OIDC Flow

Integrate Hydra OathKeeper into flow

hydra login handler

part of #49

Add a /login endpoint to handle Hydra's login request challenge.

Project setup

Support Wallet Login & Lock/Unlock

hub-auth resources

View

resource	type	sensitive?	served?	usage
key server URLs	list of URLs	no	yes	edge-agent Vue.js sets up key stores, then initializes wallet
sds server URLs	list of URLs	no	yes	edge-agent Vue.js sets up vaults, then initializes wallet
keyStoreIDs	list of IDs	yes	yes	edge-agent aries-framework-go KMS
SDS vault IDs	list of IDs	yes	yes	edge-agent aries-framework-go storage
user devices info	list of tuples {AAGUID publicKey, x509_cert}	yes	no	when unlocking: validate if device is registered and to which user before giving access to bootstrap resources (primary key is wiped from devices when locked, needs to be fetched from network)
locations of user primary key shares	list of SDS locations of the user's primary key shares (split w/SSS)	yes	yes	a) when unlocking: edge-agent Vue.js needs location + authZ to fetch those shares; b) key server needs locations + authZ to fetch those shares to unlock the user's key store and do crypto operations
authorized wallet callback URIs	list of URIs	no	no	configuration: helps restrict processing of authZ requests to authorized wallets