GET MAY return creds unable to be used #517

MHBauer · 2018-05-15T15:01:23Z

resolves #516

cfdreddbot · 2018-05-15T15:01:25Z

Hey MHBauer!

Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you and the commit authors have already signed the CLA.

duglin · 2018-05-15T18:29:49Z

spec.md

@@ -1374,7 +1374,7 @@ For success responses, the following fields are defined:

 | Response Field | Type | Description |
 | --- | --- | --- |
-| credentials | object | A free-form hash of credentials that can be used by applications or users to access the service. |
+| credentials | object | A free-form hash of credentials that can be used by applications or users to access the service. If credentials have been stored in a format that does not allow retrieval of a usable result (e.g. a salted and hashed password), the broker MAY omit the field from `credentials`. This can result in a return value that is not usable to access the service. |


s/from credentials//
I assume they should just skip the entire "credentials" field, and not just certain items in it. Returning a partial list of creds could be very misleading so I think it should be all or nothing.

duglin · 2018-05-15T21:23:34Z

LGTM

n3wscott · 2018-05-16T17:24:28Z

spec.md

@@ -1374,7 +1374,7 @@ For success responses, the following fields are defined:

 | Response Field | Type | Description |
 | --- | --- | --- |
-| credentials | object | A free-form hash of credentials that can be used by applications or users to access the service. |
+| credentials | object | A free-form hash of credentials that can be used by applications or users to access the service. If credentials have been stored in a format that does not allow retrieval of a usable result (e.g. a salted and hashed password), the broker MAY omit this field. This can result in a return value that is not usable to access the service. |


This can result in a return value that is not usable to access the service.

That statement seems ambiguous. Are you saying the response that lacks a credentials field will result in a value that is unable to access the service or the fact that returning a salted+hashed password results in not being able to use it.

This addition reads to me as a way to allow a broker to never allow access to a service. How would such a service perform an async bind?

I would suggest we just remove that sentence.

re: async-binding... perhaps we need to add something else here to make it clear that each GET can decide when to return the credentials. Meaning, the first GET might do so, but then subsequent GETs may not because they're stored in a hash. This allows for a one-time-only retrieval so async bindings work, but after that things remain secure. But, in the case of async it MUST support at least one GET of the creds.

Is removing that sentence acceptable?

With a password based service like that, it looks like it would be best to not support async bind, or a broker specific implementation that returns the credentials only for a certain limit (time, number of attempts, a combination, new credentials each time, etc).

I am not sure how this would interact with other token/cert/other based access. It is probably similar privileged key-like material that needs to be guarded in a similar manner.

Not sure how to encode this intent beyond the given example.

Is removing that sentence acceptable?

I've added this today's agenda - I think some real-time discussions might help

If credentials have been stored in a format that does not allow retrieval of a usable result the broker MAY omit this field.
@n3wscott @mattmcneeney Is only that sentence being added acceptable? I feel like it makes things murkier rather than clearer without the example.

duglin · 2018-05-22T14:00:22Z

@MHBauer did you want to address @n3wscott's comment?

MHBauer · 2018-05-22T23:16:01Z

@mattmcneeney During the call today, you took specific issue with the given example. I do not recall the exact context, but I feel like it adds one specific intent without restricting it to solely that case. I'll work with @duglin on alternative phrases and positions.

mattmcneeney · 2018-05-23T07:13:20Z

Sounds good, thanks @MHBauer. My only concern with the current text is that it suggests the fact a credential is hashed/salted is a reason not to return it, but from a broker author's perspective, their concern really is security.

Maybe something like this:

A free-form hash of credentials that can be used by applications or users to access the Service Instance. This field MAY be omitted if the Service Broker either cannot return the credentials or does not want to for security reasons.

duglin · 2018-05-23T16:44:05Z

How about a minor addition:

A free-form hash of credentials that can be used by applications or users to access
the Service Instance. This field MAY be omitted if the Service Broker either cannot
return the credentials or does not want to for security reasons. Note that during
an asynchronous bind operation the Service Broker MUST include this field in at least
the first response after the Service Binding has been successfully created, otherwise
the Platform will not have the credentials to pass along to the application/user.

MHBauer · 2018-05-23T17:33:26Z

Does it all just go into one giant line? Seems to render fine, but looks terrible in plaintext.

MHBauer · 2018-05-23T17:34:04Z

spec.md

@@ -1374,7 +1374,7 @@ For success responses, the following fields are defined:

 | Response Field | Type | Description |
 | --- | --- | --- |
-| credentials | object | A free-form hash of credentials that can be used by applications or users to access the service. |
+| credentials | object | A free-form hash of credentials that can be used by applications or users to access the Service Instance. This field MAY be omitted if the Service Broker either cannot return the credentials or does not want to for security reasons. Note that during an asynchronous bind operation the Service Broker MUST include this field in at least the first response after the Service Binding has been successfully created, otherwise the Platform will not have the credentials to pass along to the application/user. |


@n3wscott does this address the async bind case?

It's a little weird to have async bind information in this PR since it may be submitted before #334

@mattmcneeney does that mean you want it back out and a reminder in #334 ?

This addition introduces an inconstancy. If we allow the omission of the credentials here, we also have to allow the omission for the same reasons when a binding is (re-)created with the identical parameters (status code 200 OK).

@MHBauer please make similar edits to the create per Florian's suggestion - then we'll discuss at the f2f

I disagree. The door shuts eventually, but that doesn't mean it's shut from the start.

For synchronous binding the credentials can be returned the once before becoming irretrievable.

For async binding we have to preserve the response for only so long.

@MHBauer this is about the case where a replayed create comes in, at that point its like a GET when the params are the same so the broker can then be free to not include the creds. I agree that a non-replayed create should return the creds

I feel like this is very much in conflict with stateless-ness. It seems like it would now be saying "must be preserved forever". Being able to do this now implies that the credential generation is deterministic. I'm not sure this is clarifying anything anymore.

What's the equivalent of MUST include this field in at least the first response? We now appear to be saying, "MUST include forever".

duglin · 2018-05-29T12:25:08Z

LGTM

fmui · 2018-05-29T15:07:31Z

LGTM

MHBauer · 2018-05-29T15:38:20Z

Decision in 2018-05-29 meeting is hold on merge until merge of #334.

duglin · 2018-05-29T15:39:33Z

Please review but adding DO NOT MERGE since we need the async PR to go in first.

duglin · 2018-07-03T23:58:10Z

spec.md

@@ -1280,7 +1280,7 @@ For success responses, the following fields are defined:

 | Response Field | Type | Description |
 | --- | --- | --- |
-| credentials | object | A free-form hash of credentials that can be used by applications or users to access the service. |
+| credentials | object | A free-form hash of credentials that can be used by applications or users to access the Service Instance. This field MAY be omitted if the Service Broker either cannot return the credentials or does not want to for security reasons. Note that during an asynchronous bind operation the Service Broker MUST include this field in at least the first response after the Service Binding has been successfully created, otherwise the Platform will not have the credentials to pass along to the application/user. |


I think the "This field MAY be omitted..." sentence needs to be prefixed with "If a 200 is returned..." or something like that.

mattmcneeney · 2018-07-12T17:26:52Z

spec.md

@@ -1360,7 +1360,7 @@ For `200 OK` and `201 Created` response codes, the following fields are defined:

 | Response Field | Type | Description |
 | --- | --- | --- |
-| credentials | object | A free-form hash of credentials that can be used by applications or users to access the service. MUST be returned if the Service Broker supports generation of credentials. |
+| credentials | object | A free-form hash of credentials that can be used by applications or users to access the Service Instance. This field MAY be omitted if the Service Broker either cannot return the credentials or does not want to for security reasons. Note that during an asynchronous bind operation the Service Broker MUST include this field in at least the first response after the Service Binding has been successfully created, otherwise the Platform will not have the credentials to pass along to the application/user. |


s/application/Application

And who is the 'user'?

I don't think the sentence starting with Note that during an asynchronous bind operation should be in this table.

mattmcneeney · 2018-07-12T17:26:57Z

spec.md

@@ -1459,7 +1459,7 @@ For success responses, the following fields are defined:

 | Response Field | Type | Description |
 | --- | --- | --- |
-| credentials | object | A free-form hash of credentials that can be used by applications or users to access the service. MUST be returned if the Service Broker supports generation of credentials and the Service Binding was provisioned asynchronously. |
+| credentials | object | A free-form hash of credentials that can be used by applications or users to access the Service Instance. This field MAY be omitted if the Service Broker either cannot return the credentials or does not want to for security reasons. Note that during an asynchronous bind operation the Service Broker MUST include this field in at least the first response after the Service Binding has been successfully created, otherwise the Platform will not have the credentials to pass along to the application/user. |


s/application/Application

And who is the 'user'?

This is a GET endpoint, so I'm not sure it makes sense to talk about 'during an asyhnchronous bind operation'.

mattmcneeney · 2018-07-12T17:34:44Z

spec.md

@@ -1195,6 +1195,12 @@ utilize the Service Instance. Credentials SHOULD be unique whenever possible, so
 access can be revoked for each binding without affecting consumers of other
 bindings for the Service Instance.

+This field MAY be omitted if the Service Broker either cannot return the credentials
+or does not want to for security reasons. During an asynchronous bind 
+operation the Service Broker MUST include this field in at least the first response


first GET response (with link)

link to what?

MHBauer · 2018-07-12T17:41:03Z

spec.md

+operation the Service Broker MUST include this field in at least the first response
+after the Service Binding has been successfully created, otherwise the Platform will
+not have the credentials to pass along. 
+


Dug suggested

Note: some brokers (due to security concerns... blah blah) MAY choose to only return the credentials for a binding once even though there could be replayed binding requests or GETs of the binding resource.

MHBauer · 2018-07-12T17:45:03Z

What's next to move this forward? Going back to some comment in each table? Or keep the guidance on the description of a credentials binding?

fmui · 2018-07-12T18:35:01Z

LGTM

duglin · 2018-07-12T18:40:47Z

LGTM

zrob · 2018-07-12T18:42:31Z

lgtm

tinygrasshopper · 2018-07-12T18:52:31Z

In my mind this conflicts with the MUST on the binding response for credentials

| credentials | object | A free-form hash of credentials that can be used by applications or users to access the service. MUST be returned if the Service Broker supports generation of credentials and the Service Binding was provisioned asynchronously. |

Should we change the response description for fetch binding to reflect this optionality?

GET may return creds unable to be used

e755cf2

duglin reviewed May 15, 2018

View reviewed changes

all or nothing on credentials.

a859d31

n3wscott reviewed May 16, 2018

View reviewed changes

duglin added the openQuestions label May 22, 2018

proposed wording that addresses asynchronous bind

94beff6

MHBauer commented May 23, 2018

View reviewed changes

duglin added the do not merge label May 29, 2018

duglin removed the openQuestions label Jun 5, 2018

MHBauer added 3 commits July 3, 2018 15:28

add same text to binding create

d3f3d3d

accidental word wrapping

f296861

accidental deletion

0094af7

duglin reviewed Jul 3, 2018

View reviewed changes

fmui mentioned this pull request Jul 4, 2018

Fix incompatible change in v2.12 #540

Merged

Merge branch 'master' into get-no-creds

3868de4

duglin removed the do not merge label Jul 12, 2018

MHBauer added 2 commits July 12, 2018 10:21

add to split response?

430cea4

oops.

41513fd

mattmcneeney suggested changes Jul 12, 2018

View reviewed changes

move to new location

5979f6e

mattmcneeney reviewed Jul 12, 2018

View reviewed changes

MHBauer commented Jul 12, 2018

View reviewed changes

make sure we're in a GET response

9f70b38

MHBauer added 3 commits July 12, 2018 11:03

dug's suggested wording

67bdcd8

remove old text

2fb4952

move to overall binding block

c86b130

zrob approved these changes Jul 12, 2018

View reviewed changes

mattmcneeney added the 3 - reviewing PR label Jul 12, 2018

hard 80 col wrap

2ad9c34

n3wscott approved these changes Jul 12, 2018

View reviewed changes

mattmcneeney approved these changes Jul 12, 2018

View reviewed changes

fmui approved these changes Jul 12, 2018

View reviewed changes

mattmcneeney merged commit 7efb233 into openservicebrokerapi:master Jul 12, 2018

teddyking mentioned this pull request Mar 13, 2020

Add support for OSBAPI 2.14 kubernetes-retired/go-open-service-broker-client#144

Closed

GET MAY return creds unable to be used #517

GET MAY return creds unable to be used #517

Conversation

MHBauer commented May 15, 2018

cfdreddbot commented May 15, 2018

Choose a reason for hiding this comment

duglin commented May 15, 2018 • edited by avade Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

duglin commented May 22, 2018

MHBauer commented May 22, 2018

mattmcneeney commented May 23, 2018

duglin commented May 23, 2018

MHBauer commented May 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

duglin commented May 29, 2018 • edited by avade Loading

fmui commented May 29, 2018 • edited by avade Loading

MHBauer commented May 29, 2018

duglin commented May 29, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MHBauer commented Jul 12, 2018

fmui commented Jul 12, 2018 • edited by avade Loading

duglin commented Jul 12, 2018 • edited by avade Loading

zrob commented Jul 12, 2018 • edited by avade Loading

tinygrasshopper commented Jul 12, 2018

duglin commented May 15, 2018 •

edited by avade

Loading

duglin commented May 29, 2018 •

edited by avade

Loading

fmui commented May 29, 2018 •

edited by avade

Loading

fmui commented Jul 12, 2018 •

edited by avade

Loading

duglin commented Jul 12, 2018 •

edited by avade

Loading

zrob commented Jul 12, 2018 •

edited by avade

Loading