Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Refactor credentials from auth bootstrap data

Description

New Description:
The plan is here - https://openlmis.atlassian.net/wiki/display/OP/Make+Auth+dynamically+retrieve+list+of+registered+OpenLMIS+services

Acceptance Criteria

  • implement the plan

Old Description

The auth bootstrap data here: https://github.com/OpenLMIS/openlmis-auth/blob/master/src/main/resources/db/migration/20170214123932959__initial_bootstrap_data.sql has sensitive "root access" credentials that will need to be generated for each implementation and should not be in public source control.

We need to make a plan on how this stuff will be refactored out of this file and done more securely and dynamically.

Acceptance criteria

  • A plan document on how the above will be done (have Team ILL review/approve the Plan)

  • Either file a ticket for implementing this plan, or go ahead and implement it

QAlity Plus - Test Management

Checklists

Activity

Show:

Lucyna Laska June 27, 2017 at 12:24 PM

I tested all issues described by and it worked correctly.

Paweł Nawrocki June 27, 2017 at 9:05 AM
Edited

Plase verify that this feature works, meaning:

  • When we register an another service in Consul, tagged as 'openlmis-service' (or whatever the .env setting says), auth automatically adds that to its OAuth2 clients resources (can check in database, or just try to connect with auth from that newly added service).

  • Same thing, when you remove a service, it should be reflected in clients' resources.

  • Services not tagged as 'openlmis-service' should be ignored.

NOTE: auth updates this each 60 seconds, so you might want to wait a minute before checking, since the changes may not be updated instantly.

Paweł Nawrocki June 26, 2017 at 3:45 PM
Edited

I've set the service to fetch new data every minute (it also calls once immediately after start). Do you think this is fine, or shall we change this, or maybe make configurable?

Chongsun Ahn February 8, 2017 at 9:54 PM

The security risk is small, as we would tell implementers to change the credentials for deployment, and since we are the implementer for Malawi, we will make sure to do that. We will need to do this, but we don't need to do it for 3.0; perhaps soon after 3.0.

Brandon Bowersox-Johnson February 8, 2017 at 7:34 PM

Because this ticket says "make a plan", we need to evaluate. What is the security risk or importance if we don't do this for 3.0?

Done
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Story Points

Original estimate

Time tracking

1d 4h 30m logged7h 30m remaining

Components

Sprint

Fix versions

Priority

Time Assistant

Created December 16, 2016 at 11:58 PM
Updated September 21, 2017 at 12:47 AM
Resolved June 27, 2017 at 12:24 PM