Now that Platform has finally told us that generating the keys is our duty (and storing them in AWS Parameter Store) (thanks to Jeremy B.), we can continue with the technicals.
Tasks
[x] Send public JWK over to LH/api@va.gov
[x] Get client ID back from LH
[x] Make a cURL request (GET current PoA) using Sandbox user
Acceptance Criteria
[x] We will be able to hit LH's sandbox and test endpoint connectivity (via cURL)
Spike Braindump
There are several steps in making an API request. At a high level they are:
Create a JWT
Sign the JWT with your private key
Using the signed JWT (called a client assertion), request an access token from LH's token service
Take that access token and include in the Authorization header for Benefits-Claims API requests
Finally, take that access_token and put it inside the Authorization header of a Benefits-Claims API call. For example, to get the veteran's current Rep:
And that will return whatever response based on the endpoint we are using. For the call above, it would return:
{"data":{"id":null,"type":"claims_api_power_of_attorneys","attributes":{"status":"updated","date_request_accepted":"2022-01-11","representative":{"service_organization":{"first_name":null,"last_name":null,"organization_name":"074 - AMERICAN LEGION","phone_number":null,"poa_code":"074"}},"previous_poa":"095"}}}
Todo's / New Tickets
[ ] Store private RSA key in AWS Parameter Store and make DevOps PR to pull it into settings.local.yml for corresponding env(s) (staging.va.gov, prod, etc). Staging Example
[ ] create api client in vets-api
store configuration in vets-api settings.yml. example here
Duplicate Veterans Health API client and adjust for Benefits-Claims API. There are 3 files under lib/lighthouse/veterans_health/ so create a new folder lib/lighthouse/benefits_claims/ and copy client.rb configuration.rb and jwt_wrapper.rb over. Also copy the client spec spec/lib/lighthouse/veterans_health/client_spec.rb to similar location (spec/lib/lighthouse/benefits_claims/?) and adjust specs to hit new client class, such as Lighthouse::BenefitsClaims::Client. Then run the tests and begin to make them pass.
Background
Now that Platform has finally told us that generating the keys is our duty (and storing them in AWS Parameter Store) (thanks to Jeremy B.), we can continue with the technicals.
Tasks
Acceptance Criteria
Spike Braindump
There are several steps in making an API request. At a high level they are:
Authorization
header for Benefits-Claims API requestsThe above steps in more granularity
iss
,sub
,aud
,exp
,rsa_key = OpenSSL::PKey::RSA.new(File.read('/path/to/private_key.pem'))
That will return a response similar to this:
Finally, take that
access_token
and put it inside theAuthorization
header of a Benefits-Claims API call. For example, to get the veteran's current Rep:And that will return whatever response based on the endpoint we are using. For the call above, it would return:
Todo's / New Tickets
settings.local.yml
for corresponding env(s) (staging.va.gov, prod, etc). Staging Examplesettings.yml
. example herelib/lighthouse/veterans_health/
so create a new folderlib/lighthouse/benefits_claims/
and copyclient.rb configuration.rb and jwt_wrapper.rb
over. Also copy the client specspec/lib/lighthouse/veterans_health/client_spec.rb
to similar location (spec/lib/lighthouse/benefits_claims/
?) and adjust specs to hit new client class, such asLighthouse::BenefitsClaims::Client
. Then run the tests and begin to make them pass.