Skip to content

Commit

Permalink
allow Kerberos, fix #38, fix #39
Browse files Browse the repository at this point in the history
  • Loading branch information
@michielbdejong
michielbdejong committed May 5, 2014
1 parent 060d309 commit 8cce1d2
Show file tree
Hide file tree
Showing 3 changed files with 24 additions and 9 deletions.
1 change: 1 addition & 0 deletions CHANGELOG.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@

## Breaking for clients:
* Servers MAY now expire access tokens, in line with the OAuth spec.
* Servers MAY now use Kerberos instead of OAuth.

## non-breaking:
* The option to offer a manual way to create access tokens is now mentioned
Expand Down
Binary file modified draft-dejong-remotestorage-03.txt
View file
Binary file not shown.
32 changes: 23 additions & 9 deletions source.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -369,9 +369,10 @@ Table of Contents

As a special exceptions, GET requests to a document (but not a
folder) whose path starts with '/public/' are always allowed. They,
as well as OPTIONS requests, can be made without a bearer token. All
other requests should present a bearer token with sufficient access
scope, using a header of the following form (no double quotes here):
as well as OPTIONS requests, can be made without a bearer token.
Unless [KERBEROS] is used (see section 10 below), all other requests
SHOULD present a bearer token with sufficient access scope, using a
header of the following form (no double quotes here):

Authorization: Bearer <access_token>

Expand All @@ -398,11 +399,21 @@ Table of Contents
}

Here <storage_root> and <storage_api> are as per "Session
description" above, and <auth-dialog> SHOULD be a URL where an
OAuth 2.0 implicit-grant flow dialog [OAUTH] is presented, so the
user can supply their credentials (how, is out of scope), and allow
or reject a request by the connecting application to obtain a bearer
token for a certain list of access scopes.
description" above, and <auth-dialog> SHOULD be eihter the boolean
value false or a URL where an OAuth 2.0 implicit-grant flow dialog
[OAUTH] is presented.

If <auth-dialog> is a URL, the user can supply their credentials
there (how, is out of scope), and allow or reject a request by the
connecting application to obtain a bearer token for a certain list
of access scopes.

If <auth-dialog> is false, the client will not have a way to obtain
an access token, and SHOULD send all requests without Authorization
header, and rely on Kerberos [KERBEROS] instead for requests that
would normally be sent with a bearer token, but servers SHOULD NOT
impose any such access barriers for resources that would normally
not require an access token.

The <query-param> variable SHOULD have the boolean value true if
the server supports passing the bearer token in the URI query
Expand Down Expand Up @@ -834,7 +845,10 @@ ge.io/spec/modules/myfavoritedrinks/drink"}
Bearer Token Usage", RFC6750,
http://tools.ietf.org/html/rfc6750#section-2.3, October 2012.


[KERBEROS]
C. Neuman et al., "The Kerberos Network Authentication Service
(V5)", RFC4120,
https://tools.ietf.org/html/rfc4120

18. Authors' addresses

Expand Down

2 comments on commit 8cce1d2

@vanrein
Copy link

Choose a reason for hiding this comment

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

I would call this overspecification (of one particular mechanism, namely Kerberos) and, at the same time, underspecification (because it does not detail how Kerberos is used). I demonstrated Kerberos, but only as one possible mechanism that can be used outside the scope of JavaScript code like remoteStorage. As I've repeatedly said, X.509 certificates are another option, and there are TLS specifications that have not met wide adoption that could do similar things (OpenPGP, SRP, and who knows what people will invent).

May I suggest that you reformulate into something like this:

 as well as OPTIONS requests, can be made without a bearer token.
+    Unless transport-level security mechanisms are used (see section 10 below), all other requests
+    SHOULD present a bearer token with sufficient access scope, using a
+    header of the following form (no double quotes here):

and

     Here <storage_root> and <storage_api> are as per "Session
+    description" above, and <auth-dialog> SHOULD be either the boolean
+    value false or a URL where an OAuth 2.0 implicit-grant flow dialog
+    [OAUTH] is presented.
+
+    If <auth-dialog> is a URL, the user can supply their credentials
+    there (how, is out of scope), and allow or reject a request by the
+    connecting application to obtain a bearer token for a certain list
+    of access scopes.
+
+    If <auth-dialog> is false, the HTTP client will not have a way to obtain
+    an access token, and SHOULD send all requests without Authorization
+    header, and rely on security mechanisms as part of HTTP or lower transport
+    layers instead for requests that
+    would normally be sent with a bearer token, but servers SHOULD NOT
+    impose any such access barriers for resources that would normally
+    not require an access token.

I would not actually mention Kerberos at all; it will only raise lots of detailed questions when you do, which is not very useful since the whole idea is to avoid having to deal with authentication/authorisation yourself. This is why I called it implied or implicit mode.

@michielbdejong
Copy link
Member Author

Choose a reason for hiding this comment

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

good point, i'll have a look at that.

Please sign in to comment.