Affects Version/s: None
Fix Version/s: Morphic 1.4.0
This ticket will add the ability to get access tokens from the Cloud Flowmanager using a username/password login. Operation of the endpoint will be similar to the `/access_token` endpoint that is used with a `gpiiKey`. The access token retrieved from this operation will have higher privileges than that of an access_token acquired with a gpiiKey. This ticket will build upon initial work in GPII-2966.
A username/password acquired access_token will allow the user to:
- Read all preference sets in the users safe. (as compared to gpiiKey's which are tied to a single preference set)
- Write/update/add preferences sets in the users safe.
- Add and remove gpiiKey's.
- Add, change, and remove username/password credentials on the users safe.
Writing the preference sets should go through the usual validation using the GSS schemas derived from the solutions registry.
This applies to all the other documents, gpiiKey's etc, should be properly validated.
A logout mechanism should also be added to explicitly invalidate the access token (rather than waiting for it to expire).
Some questions and design decisions that need to be made:
- Should writing settings/preferences be restricted to some set of rules similar to client credentials, ie: Only certain generic prefs and application settings can be saved. Ideally my vote would be no, since the point of full username/password logins is to allow full safe management. However, we do need to contend with the fact that only a small subset of solutions have actually been tested. Adding/saving lots of preferences could result in a disaster when they are applied to a machine. Perhaps there could be some other limiting mechanism for machines applying settings.
Some implementation possibilities. I see the solution falling in to one of three categories:
- Working the new access_token endpoint in to the existing gpii-oauth2 module in universal. The username and password would still be checked against the gpii-express-user library, but the resulting access_token would be stored next to existing access_tokens, except it might have some extra property giving it more permissions since it resulted from a username/password login. This would make it easy for access tokens created from a username/password login to also be used by the existing GET and PUT settings endpoints.
- Create another set of endpoints outside of gpii-oauth2 for logging in, creating and managing either an access_token or session key, still using the gpii-express-user utilities already implemented in GPII-2966 to create and unlock passwords.
- Some combination of 2, but trying to use some of the existing REST endpoints inside of gpii-express-user to the maximum extent possible. This seems like a good idea. This usage may mostly be REST based, and not using the handlebars frontend, but those could be mounted as well. It just depends if we want to start serving HTML interfaces from the flowmanager.
After using whichever above mechanism to authenticate with a username/password, retrieving an access token or session id, the following outline of endpoints will be available:
GET preference safe
PUT/POST preferences safe <- Should we allow updating an entire preferences safe document, or require a seperate request for each preference set being operated upon?
GET/PUT/POST preferences sets
GET gpiiKeys list
GET/PUT/POST/DELETE gpiiKey by ID (or create a new one)
GET username/credentials list (mostly metadata with username, hashed password info not sent as part of this)
GET/PUT/POST/DELETE credential, including a custom method to change the password