search

nasa / utm-apis

The collection of APIs for NASA's UTM project in the form of OpenAPI documents.
55 stars 35 forks source link

Require current_timestamp in /token request? #176

Closed rebekah-cna closed 4 years ago

rebekah-cna commented 4 years ago

https://github.com/nasa/utm-apis/blob/4260051071f0f7b5d8dfc6bd3d4a0b30c869fdfb/fimsauthz-api/fims-authz.yaml#L73

The timestamp field is currently optional in /token. This will allow reuse of old signed token requests (https://github.com/nasa/utm-apis/pull/171#discussion_r418314053). To help combat token reuse/replay, should this field be required?

The authorization server would then need to specify a time range for which the request is valid.

nasajoey commented 4 years ago

This is a great catch. I know that we were uncertain for a little while in initial discussions if one or both of "salt" and "current_timestamp" should be required. We must not have gone back and codified the decision.

I think my understanding is exactly as @rebekah-cna describes... current_timestamp is to be required, while salt is current optional. For implementation purposes, salt isn't used in any direct way by the FIMS auth server. but current_timestamp may be used to deflect replays.

@issmith1 and @arkits lets make the field required AND also add a little documentation on how the timestamp will be used. We can make that another ticket if needed. It will be important that the two FIMS auth implementations use the same business rules for that timestamp.

issmith1 commented 4 years ago

FAA's implementation: Math.abs(now.getTime() - t.getTime()) < 5000 ms Where now is a javascript Date of the current time on the fims_server and t is a Date of the request.current_timestamp (edited)

nasajoey commented 4 years ago

@issmith1 can you confirm the units for the "5000" in your note above? I'm assuming ms but want to be clear.

I'm worried that due to lack of requirements for time synchronization within the USS Network and inherent latencies that we may have issues with this check in production if only 5 seconds.

We saw many issues when comparing timestamps across servers in TCL1-3.

issmith1 commented 4 years ago

NASA's implementation - recommend externalizing/parameterizing the 5 second time definition.

issmith1 commented 4 years ago

fixed as per next comment

issmith1 commented 4 years ago

Token Request’s current-timestamp https://github.com/nasa/utm-apis/issues/176 spec is closed service is open https://atmjira.arc.nasa.gov/browse/UAMX3-466