Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add opaque Bearer Token to approved authentication methods #398

Merged
merged 13 commits into from
Mar 6, 2018
+14 −4
Merged

add opaque Bearer Token to approved authentication methods #398

Changes from 12 commits
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
3f51ecd
add opaque Bearer Token to approved authentication methods
Dec 19, 2017
22face4
rework the bearer token as a follow on to the original authentication…
Dec 19, 2017
bc5d9f8
use alternate wording for 'required' and 'must'
Jan 5, 2018
d207c2e
removed opaque token text, added some clarifications around authentic…
Jan 23, 2018
42766cc
review fixes
Jan 24, 2018
a3e900a
Beginning a section on platform-specific authentication mechanisms
arschles Jan 25, 2018
0585bd5
Use the same header for auth section as the spec
avade Jan 26, 2018
844e71e
Update ToC with new auth seciton
avade Jan 26, 2018
99c458a
Adding text to direct to the auth wiki page
arschles Feb 6, 2018
2619553
Adding language regarding the TLS certificates
arschles Feb 7, 2018
df3cdd2
removing platform to service broker auth section
arschles Feb 8, 2018
ed95067
fix lint issues
Feb 8, 2018
4aaf6e9
spelling: communications
Feb 27, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 14 additions & 4 deletions spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@
- [Change Policy](#change-policy)
- [Changes Since v2.12](#changes-since-v212)
- [API Version Header](#api-version-header)
- [Authentication](#authentication)
- [Platform to Service Broker Authentication](#platform-to-service-broker-authentication)
- [URL Properties](#url-properties)
- [Originating Identity](#originating-identity)
- [Service Broker Errors](#service-broker-errors)
Expand Down Expand Up @@ -151,7 +151,7 @@ Service Broker MAY reject the request with `412 Precondition Failed` and
provide a message that informs the operator of the API version that is to be
used instead.

## Authentication
## Platform to Service Broker Authentication

While the communication between a Platform and Service Broker MAY be unsecure,
it is RECOMMENDED that all communications between a Platform and a Service
Expand All @@ -163,9 +163,19 @@ Service Broker using HTTP basic authentication (the `Authorization:` header)
on every request. This specification does not specify how Platform and Service
Brokers agree on other methods of authentication.

Platforms and Service Brokers MAY agree on an authentication mechanism other
than basic authentication, but the specific agreements are not covered by this
specification. Please see the
[Platform Features authentication mechanisms wiki document](https://github.com/openservicebrokerapi/servicebroker/wiki/Platform-Features)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why this isn't in the spec, but I'm happy with this for now.

for details on these mechanisms.

If authentication is used, the Service Broker MUST authenticate the request
using the predetermined authentication mechanism and MUST return a `401
Unauthorized` response if the authentication fails.
using the predetermined authentication mechanism, and MUST return a `401 Unauthorized`
response if the authentication fails.

Additionally, the Service Broker MUST secure communucations with TLS. The Platform
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

communucations -> communications

and Service Broker SHOULD agree whether the Service Broker will use a root-signed
certificate or a self-signed certificate.

Note: Using an authentication mechanism that is agreed to via out of band
communications could lead to interoperability issues with other Platforms.
Expand Down