<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1367022146;
mso-list-type:hybrid;
mso-list-template-ids:645939634 2015652986 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1955749497;
mso-list-template-ids:924229028;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2
{mso-list-id:2140100753;
mso-list-template-ids:10122938;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I’m jumping in this thread to understand whether there’s a chance KeyStone can implement some use cases around the concept of object ownership.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I apologise if this email turns out to be a bunch of nonsense; unfortunately I don’t have a strong AAA background </span><span style='font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>As pointed out several times in this thread, this is something which should be enforced in the service: once a request comes in, the AA middleware validates the token and retrieves user identity with Keystone, using it to verify whether the user owns the objects on which the request operates. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>However, sometimes requests operate on objects defined in different services; for instance in the Quantum service (L2 networking), the operation for plugging an interface on a port operate on the following resources:<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo3'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The network and the port, defined in quantum<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo3'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The interface being plugged, defined in nova<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The AA middleware needs to verify that the user ‘owns’ all these resources, in order to ensure, for instance, that a tenant does not plug another tenant’s interface in his own network.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>As this process involves resources defined in two distinct services, I was wondering whether Keystone could help in any way, by exposing APIs for registering/unregistering/listing object ownership relationships.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>These relationships could be stored in the form <service-name>:<object-uuid> and associated to the appropriate Keystone object, tenant or user. AA middleware in services such as Quantum could query Keystone for the list of objects owned by a given user/tenant in a service or for establishing whether a user/tenant owns specific object(s). <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Would it be reasonable to expect to have something like that in Keystone? <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Salvatore<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> openstack-bounces+salvatore.orlando=eu.citrix.com@lists.launchpad.net [mailto:openstack-bounces+salvatore.orlando=eu.citrix.com@lists.launchpad.net] <b>On Behalf Of </b>Ziad Sawalha<br><b>Sent:</b> 13 July 2011 05:45<br><b>To:</b> Rouault, Jason (Cloud Services); andi abes<br><b>Cc:</b> openstack@lists.launchpad.net<br><b>Subject:</b> Re: [Openstack] OpenStack Identity: Keystone API Proposal<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>Here's a possible use case we can implement to address this:<o:p></o:p></span></p></div><ol start=1 type=1><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>A service 'registers' itself with Keystone and reserves a name (Ex. Swift, or nova). Keystone will guarantee uniqueness.<o:p></o:p></span></li><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>Registered services can then create roles for the service (Ex. swift:admin or nova:netadmin) or tuples as suggested below (nova:delete:volume)<o:p></o:p></span></li><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>On token validation, Keystone returns these roles and a service can apply it's own policies based on them.<o:p></o:p></span></li></ol><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>This is super-simplified and we can expand on it.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>Other benefits:<o:p></o:p></span></p></div><ul type=disc><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo2'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>Registration would also be handy to allow services to add and manage endpoints as well.<o:p></o:p></span></li><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo2'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>We can also tie this with the concept of a ClientID so services can identify themselves as well with a long-lived token (see <a href="https://github.com/rackspace/keystone/issues/84">https://github.com/rackspace/keystone/issues/84</a>)<o:p></o:p></span></li><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo2'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>Common names for services could be implemented as shareable among different implementations (Ex: compute:admin)<o:p></o:p></span></li></ul><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>Thoughts?<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>And comments inline </span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:#00970A'>ZNS>></span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p></div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>From: </span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>"Rouault, Jason (Cloud Services)" <<a href="mailto:jason.rouault@hp.com">jason.rouault@hp.com</a>><br><b>Date: </b>Thu, 16 Jun 2011 19:54:22 +0000<br><b>To: </b>andi abes <<a href="mailto:andi.abes@gmail.com">andi.abes@gmail.com</a>><br><b>Cc: </b>Ziad Sawalha <<a href="mailto:ziad.sawalha@rackspace.com">ziad.sawalha@rackspace.com</a>>, "<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>" <<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>><br><b>Subject: </b>RE: [Openstack] OpenStack Identity: Keystone API Proposal<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p></div><div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>See inline…</span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Jason</span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'> andi abes [<a href="mailto:andi.abes@gmail.com">mailto:andi.abes@gmail.com</a>] <br><b>Sent:</b> Wednesday, June 15, 2011 5:04 PM<br><b>To:</b> Rouault, Jason (Cloud Services)<br><b>Cc:</b> Ziad Sawalha; <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br><b>Subject:</b> Re: [Openstack] OpenStack Identity: Keystone API Proposal</span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:black'>Jason, <o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-US style='color:black'> Sounds like the model you're proposing could be achieved by something like this:<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'>On Keystone:<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'>- Roles are identified by name and contain tuples in the form of:<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> -- the service to which this permission applies (e.g. service nova, swift). Including the service is meant to side track attempts to normalize actions across very different types of services<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> -- the type of target this action applies to - e.g. volume, network port etc.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> -- action this permission allows - e.g. start vm, create volume.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'>- An authorize API call which accepts: <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> - the service requesting the authorization<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> - user token (from a previous authentication) <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> - tenant ID (to resolve the realm of the user token)<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> - a target type<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> - the attempted action.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> This API would lookup the token, and if its present combine a set of the relevant permissions from all the roles the token is referencing. If the requested tuple exists in this combine set, the request is authorized.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p><div><div><div><div><div><div><div><p class=MsoNormal><span lang=EN-US style='color:black'>A few caveats remain:<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'>a) the above description doesn't include Resource Groups... as Ziad mentioned, that is currently differed. When those are introduced, the service should probably pass the instance-id of the target, and Keystone would have to take that into account.</span><span lang=EN-US style='color:#1F497D'><br>JLR>> I think there are a number of ways to account for this if we leveraged a hierarchical (URI) structure and allowed for wild carding. </span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:#00970A'>ZNS>> We start to get in the world of policies here (lookup XACML)</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div></div></div></div></div></div></div></div></div></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p></div><div><div><div><div><div><div><div><div><div><div><p class=MsoNormal><span lang=EN-US style='color:black'>b) the current API's in keystone allows a service to perform actions on multiple instances across tenants (containers) efficiently - a service could obtain a list of accessible tenants and cache it. If only the 'authorize' API is available, the service would need to perform a check with keystone for every instance <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>JLR>> Please explain the model for Tenant, Accounts, Projects, Groups, Roles…. I have not been able to discern how tenant will map to accounts and projects. In any case, there are things that can be done to improve the potential overhead of authorization calls… however, you will not eliminate it completely. That is the price you pay for increased security. If authorization is pluggable, operators can determine if and how they want to use it.</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:#00970A'>ZNS>>tenants are the same as account in swift and project in Nova. The term tenant is not as overloaded as account, so we chose it.</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div></div></div></div></div></div></div></div></div></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p></div><div><div><div><div><div><div><div><div><div><div><p class=MsoNormal><span lang=EN-US style='color:black'>c) In this model it is required to populate role definitions into keystone, for all services. Since keystone should be independent of other services, the set of actions/targets should probably be considered as ""data"" for it - requiring a deployment step of sorts to make keystone aware of these roles.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'>This could be avoided if the authorization decision is looked at as 2 separate steps:<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> 1. figure out what roles a user posses. <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> 2. expand the set of roles to set of actions allowed<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> 3. determine if the action attempted is allowed<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>JLR>> Each service would need to document its target structure and actions (this would be very similar to their published API’s). I think there would be a default set of roles and permissions pre-populated to satisfy the base set of use cases. </span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:#00970A'>ZNS>>Maybe there are some built-in or reserved ones for Keystone and/or OpenStack (Ex keystone:admin and compute:admin). I'd suggest they were configurable if we did do that… but would help simplify a fast install and canonical deployment of OpenStack.</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div></div></div></div></div></div></div></div></div></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p></div><div><div><div><div><div><div><div><div><div><div><p class=MsoNormal><span lang=EN-US style='color:black'>it is obviously debatable where keystone ends and the services begin. In the model above, keystone is responsible for all 3 steps via the authorize API. I *think* the current API provides a very similar model, with the line drawn at 1 - i.e. keystone provides to roles, and there is a separate middleware piece to perform 2 & 3, executing in the request pipleline of the service. Where this middleware executes (i.e. what is the API boundary to keystone) doesn't necessarily change the overall model. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br>JLR>> Without a pluggable authorization system, operators will never be able to provide fine-grained access control without mucking with hardcoding in the API layer. That is not a good path</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:#00970A'>>>ZNS: Indeed. A slippery slope. We want to provide core functionality out of the box, but we don't want to end up writing a complete IDM solution…</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div></div></div></div></div></div></div></div></div></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p></div><div><div><div><div><div><div><div><div><div><div><p class=MsoNormal><span lang=EN-US style='color:black'>I *think*.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US style='color:black'> <o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-US style='color:black'>On Wed, Jun 15, 2011 at 11:52 AM, Rouault, Jason (Cloud Services) <<a href="mailto:jason.rouault@hp.com" target="_blank">jason.rouault@hp.com</a>> wrote:<o:p></o:p></span></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;color:#1F497D'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;color:#1F497D'>In my opinion the services (and their developers) should not need to interpret roles thus resulting in varying semantics. Roles should be defined by a set of configurable privileges to perform certain <u>actions</u> on specific <u>targets</u> for particular <u>services</u>. The API should only need to know to check with an authorization subsystem whether the incoming request is allowed based on the who is making the request and the 3-tuple mentioned previously. </span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;color:#1F497D'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;color:#1F497D'>Jason</span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;color:#1F497D'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;color:#1F497D'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=EN-US style='font-size:10.0pt;color:black'>From:</span></b><span lang=EN-US style='font-size:10.0pt;color:black'> andi abes [mailto:<a href="mailto:andi.abes@gmail.com" target="_blank">andi.abes@gmail.com</a>] <br><b>Sent:</b> Wednesday, June 15, 2011 9:18 AM<br><b>To:</b> Rouault, Jason (Cloud Services)<br><b>Cc:</b> Ziad Sawalha; <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br><b>Subject:</b> Re: [Openstack] OpenStack Identity: Keystone API Proposal</span><span lang=EN-US style='color:black'><o:p></o:p></span></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:black'> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:black'>I would expect that the API of each service would have to interpret the role assigned to a user in the context of that service - roles for swift nova glance quantum etc would probably carry very different semantics.<o:p></o:p></span></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:black'>So, to my understanding, key stone provides authentication and user information - what tenants the user has access to, and what roles the user is assigned. The mapping of these to what the user can do on what instances in each service are left for the service to determine.<o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><span lang=EN-US style='color:black'> <o:p></o:p></span></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:black'>On Wed, Jun 15, 2011 at 10:32 AM, Rouault, Jason (Cloud Services) <<a href="mailto:jason.rouault@hp.com" target="_blank">jason.rouault@hp.com</a>> wrote:<o:p></o:p></span></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;color:#1F497D'>Is there a plan to also have Keystone be the centralizing framework around authorization? Right now it looks like policy enforcement is left to the API layer.</span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;color:#1F497D'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;color:#1F497D'>Thanks,<br><br>Jason</span><span lang=EN-US style='color:black'><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;color:#1F497D'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=EN-US style='font-size:10.0pt;color:black'>From:</span></b><span lang=EN-US style='font-size:10.0pt;color:black'> openstack-bounces+jason.rouault=<a href="http://hp.com" target="_blank">hp.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a> [mailto:<a href="mailto:openstack-bounces%2Bjason.rouault" target="_blank">openstack-bounces+jason.rouault</a>=<a href="http://hp.com" target="_blank">hp.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a>] <b>On Behalf Of </b>Ziad Sawalha<br><b>Sent:</b> Friday, June 10, 2011 5:24 PM<br><b>To:</b> <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br><b>Subject:</b> [Openstack] OpenStack Identity: Keystone API Proposal</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:black'> <o:p></o:p></span></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'>Time flies! It's June 10th already. In my last email to this community I had proposed today as the day to lock down the Keystone API so we can finalize implementation by Diablo-D2 (June 30th).</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'>We've been working on this feverishly over the past couple of weeks and have just pushed out a proposed API here: <a href="https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf" target="_blank">https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf</a></span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'>For any and all interested, the original source and code is on Github (<a href="https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf" target="_blank">https://github.com/rackspace/keystone</a>), along with the current implementation of Keystone, examples, sample data, tests, instructions, and all the goodies we could muster to put together. The project also lives on Launchpad at <a href="http://launchpad.net/keystone" target="_blank">http://launchpad.net/keystone</a>.</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'>The API we just put out there is still a proposal. We're going to be focusing on the implementation, but would still love to get community input, feedback, and participation.</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'>Have a great weekend and regards to all,</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'>Ziad</span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.5pt;color:black'> </span><span lang=EN-US style='color:black'><o:p></o:p></span></p></div><pre><span lang=EN-US style='color:black'> <o:p></o:p></span></pre><pre><span lang=EN-US style='color:black'>Confidentiality Notice: This e-mail message (including any attached or<o:p></o:p></span></pre><pre><span lang=EN-US style='color:black'>embedded documents) is intended for the exclusive and confidential use of the<o:p></o:p></span></pre><pre><span lang=EN-US style='color:black'>individual or entity to which this message is addressed, and unless otherwise<o:p></o:p></span></pre><pre><span lang=EN-US style='color:black'>expressly indicated, is confidential and privileged information of Rackspace.<o:p></o:p></span></pre><pre><span lang=EN-US style='color:black'>Any dissemination, distribution or copying of the enclosed material is prohibited.<o:p></o:p></span></pre><pre><span lang=EN-US style='color:black'>If you receive this transmission in error, please notify us immediately by e-mail<o:p></o:p></span></pre><pre><span lang=EN-US style='color:black'>at <a href="mailto:abuse@rackspace.com" target="_blank">abuse@rackspace.com</a>, and delete the original message.<o:p></o:p></span></pre><pre><span lang=EN-US style='color:black'>Your cooperation is appreciated.<o:p></o:p></span></pre></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><span lang=EN-US style='color:black'><br>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><o:p></o:p></span></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div></div></div></div></div></div><p class=MsoNormal><span lang=EN-US style='color:black'> <o:p></o:p></span></p></div></div></div></div></div></div></div></div></div></div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Courier New";color:black'>This email may include confidential information. If you received it in error, please delete it.</span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p></o:p></span></p></div></div></body></html>