Keystone/Trusts - Revision history

Andersonvom: /* To enumerated the trusts */ Fix headers of HTTP calls

2013-11-01T14:36:45Z

‎To enumerated the trusts: Fix headers of HTTP calls

Andersonvom: /* To enumerated the trusts */ Fix lists and HTTP calls

2013-11-01T14:25:14Z

‎To enumerated the trusts: Fix lists and HTTP calls

Andersonvom: /* Rules */ Reword and fix typo

2013-11-01T14:20:15Z

‎Rules: Reword and fix typo

Ryan Lane: Text replace - "NOTOC" to ""

2013-02-17T23:30:22Z

Text replace - "__NOTOC__" to ""

Ryan Lane: Text replace - "<>" to "TOC"

2013-02-17T23:22:05Z

Text replace - "<<TableOfContents()>>" to "__TOC__"

Admiyo at 14:58, 4 December 2012

2012-12-04T14:58:10Z

Admiyo at 04:16, 4 December 2012

2012-12-04T04:16:41Z

Admiyo at 04:14, 4 December 2012

2012-12-04T04:14:01Z

David at 21:18, 3 December 2012

2012-12-03T21:18:08Z

Admiyo at 16:29, 3 December 2012

2012-12-03T16:29:34Z

@@ Line 60: / Line 60: @@
 * The second is a list of trusts for which the user is the trustee
+=== To enumerate the list of trustees for trusts that the user has created: ===
 GET /user/<id>/trustees
@@ Line 69: / Line 67: @@
 * Only the trustor will be able to access this URL.  Any other user will get a 403 (Forbidden).
+=== To enumerate the set of trustors that have nominated the user as the trustee: ===
 GET /user/<id>/trustors

@@ Line 54: / Line 54: @@
 === To enumerated the trusts ===
-* GET /trusts/
+GET /trusts/
-* This will return a document with two lists.
-** The first is the list of trusts for which the user is the trustor
+This will return a document with two lists:
-** The second is a list of trusts for which the user is the trustee
+* The first is the list of trusts for which the user is the trustor
 To enumerate the list of trustees for trusts that the user has created:
-* GET /user/<id>/trustees
+GET /user/<id>/trustees
 * Which will return a list of trustee user ids, each of which is associated with a list of URLS for the associated trusts.
 * This will view active trusts. disabled trusts will require an additional paramater (disabled)
 * Only the trustor will be able to access this URL.  Any other user will get a 403 (Forbidden).
 To enumerate the set of trustors that have nominated the user as the trustee:
-* GET /user/<id>/trustors
+GET /user/<id>/trustors
 * Which will return a list of trustor user ids, each of which is associated with a list of URLS for the associated trusts.
 * This will view active trusts. disabled trusts will require an additional paramater (disabled)

@@ Line 32: / Line 32: @@
 ** A value of 'inf'  means  that the delegation is infinitely recursive.
 * There is also a list of  endpoints associated with the delegation.
-** This further restricts the delegation to only the endpointsspecified .
+** This further restricts the delegation to the specified endpoints only.
 ** If the endpoints are missing, then the delegation is useless.
 ** A special value of 'all_endpoints' allows the trust to be used by  all endpoints associated with the delegated tenant.

← Older revision		Revision as of 23:30, 17 February 2013
Line 1:		Line 1:
−	~~__NOTOC__~~	+
	__TOC__		__TOC__

@@ Line 1: / Line 1: @@
 __NOTOC__
-<<[[TableOfContents]]()>>
+__TOC__
 = Trusts =

@@ Line 47: / Line 47: @@
 * roles
 * endpoints
-* duration as a timedelta (optional)
+* trust start time (optional, defaults to submission time)
 * delegation depth (optional)

@@ Line 89: / Line 89: @@
 == Token Format Changes ==
-Each token created from a Trust will have a '''trustee''' field.
+Each token created from a Trust will have two additional fields.
 When performing recursive delegation, there needs to be a record of the delegation chain, not least so that  the trustor can understand how the new trustee has been added to the  token.   Thus,  each token will have a '''trusts '''field. This will be a list with the name of each trustee in the chain, ordered from the original trustee to the trustee that requested the token.

@@ Line 47: / Line 47: @@
 * roles
 * endpoints
-* and optionally the duration and delegation depth <added by David>
+* duration as a timedelta (optional)
 The trustor ID is implied from the creating users ID.
@@ Line 77: / Line 78: @@
 === To deactivate a trust ===
-* GET /trusts/{trustID}  <David - I think this should be DELETE not GET>
+* DELETE /trusts/{trustID}
 * This sets the trust status to disabled.
 * Only the trustor will be able to access this URL.  Any other user will get a 403 (Forbidden).
@@ Line 86: / Line 87: @@
 == Implementation ==
 Implemented in two phases.
 Phase 1
@@ Line 96: / Line 102: @@
 # Modify the token architecture to allow arbitrary sets of attributes.
 # Modify the trust architecture to specify arbitrary sets of attributes to be used in a token.

@@ Line 21: / Line 21: @@
 Right now, a user delegates in a short term fashion using tokens. Once a token has been granted to a user, he hands that off to another (service) user in order to prove his identity and authorization to perform some set of actions.  In addition, since tokens are not scoped to a specific endpoint, they are currently passed on from one endpoint to another.  This is not a secure approach.  If any endpoint along the way is compromised, all the tokens in that endpoint are usable against any other service that accepts tokens. So  we limit the scope of tokens to only that single endpoint, and we remove the attack.  As a result, we also remove the ability of the remote service user  to request additional operations from additional remote services on behalf of the original user.  This is a problem that the trusts are designed to serve.
 * A trust is a promise to allow delegation at some point in the future.  The actual delegation is performed in the token.  The trust is used to get the token.
 * The data for the delegation itself is simply the uuid user_ids for the trustor and trustee, along with the privileges that are being delegated.
@@ Line 37: / Line 38: @@
 == APIs ==
-To create a trust
+=== To create a trust ===
 POST /trusts
@@ Line 50: / Line 50: @@
 The trustor ID is implied from the creating users ID.
-To enumerated the trusts
+=== To enumerated the trusts ===
 * GET /trusts/
 * This will return a document with two lists.
 ** The first is the list of trusts for which the user is the trustor
 ** The second is a list of trusts for which the user is the trustee
 To enumerate the list of trustees for trusts that the user has created:
@@ Line 83: / Line 70: @@
 * Only the trustor will be able to access this URL.  Any other user will get a 403 (Forbidden)
-TrustID
+=== To view a trust ===
 The trust id is a blob, and for the first implementation, will be a UUID.  It should be  useless to anyone but the trustor and the trustee.  No other user should be  able to view it.  The user should be able to enumerate her  preauthentications, in order to view, modify, and delete them. /users/preauthentications
@@ Line 90: / Line 86: @@
 Implemented in two phases.
-.  Trusts get implemented today "hard wired" with the attributes that are currently exposed in a token:  (trustor) user, tenant, roles, endpoints. 2.  Tokens that get generated from the trusts will look just like normal tokens.  They will have an additional field "trustee".  This will allow the current consumers of tokens to continue to use a trust token just like they do now.
+Phase 1
-Phase 2. 1.  Modify the token architecture to allow arbitrary sets of attributes. 2.  Modify the trust architecture to specify arbitrary sets of attributes to be used in a token.
+# Modify the token architecture to allow arbitrary sets of attributes.