<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Origianlly respoded just to Christopher. Forwarding this on to a
the main list. <br>
<br>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
First of all, let me say thanks to everyone participating in the
discussion. This is the only way we are going to identify all of the
issues and come up with a decent implementation. I knew this would
be a touchy subject when we first started designing it, and
suspected that it would take some form of commit before the
discussion hit the majority of the community.<br>
<br>
<br>
On 08/02/2012 02:20 PM, Christopher MacGown wrote:
<blockquote
cite="mid:0614C10B76D443999B39EAC20C0EE413@pistoncloud.com"
type="cite">
<div><span style="color: rgb(160, 160, 168); ">On Thursday, August
2, 2012 at 6:59 AM, Adam Young wrote:</span></div>
<blockquote type="cite"
style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span>
<div>
<div><br>
So, let me put the onus on you: make the argument for
rapid revocation of tokens.<br>
</div>
</div>
</span></blockquote>
<div>If you are deploying OpenStack and providing access to third
parties, and for whatever reason you terminate a relationship
with that third party — whether they cancel, you've banned them,
you've removed a user from a tenant/project — you want that
third party to immediately lose access to whatever capability
they had prior to that termination. Leaving non-affiliated users
with access to resources is a serious security risk that would
make OpenStack unusable in a regulated environment.</div>
</blockquote>
<br>
In those cases, you probably want to continue on with online token
checking, regardless of UUID/PKI. That ability will not go away.
We probably do need a configuration option for auth_token that
indicates whether it should verify with PKI or not, but my guess is
that the real policy will be dictated by keystone. Perhaps what we
really need is for the remote services to query this value from the
keystone server. It could do the check when it origianally fetches
certificates. The certificates themselves could be shorter lived
(say 24 hours) and refreshed when they expire.<br>
<br>
Automatic Management of the certificates probably should also be
configurable, with many organizations preferring to use Puppet etc.<br>
<br>
I suspect that we are going to want a more nuanced policy/mechanism
long term, something along the lines of:<br>
<br>
Tenant specific PKI tickets are short lived, say 5 minutes.<br>
Non-tenant specific tickets are used to get tenant specific tickets.<br>
Long running tasks will call back to Keystone to verify ticket
validity using UUID tokens.<br>
<br>
<br>
If we start doing something along the lines of Federation as I've
started <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://blueprints.launchpad.net/keystone/+spec/federation">https://blueprints.launchpad.net/keystone/+spec/federation</a><br>
You would also have the option of revoking the signing certificate
for a whole domain, which would be an effective way to deny access
to a swath of people, say on a breach of contract.<br>
<br>
In large organziations, there is always going to be some non-zero
delay between the decision to revocation authorization and the
implementation of that decision. With LDAP replication, at a
minimum you have the replication delay. The question is what that
acceptable delay is in a given scenario. It may not be the same
even for all use cases even in a large organization.<br>
<br>
<br>
<br>
<blockquote
cite="mid:0614C10B76D443999B39EAC20C0EE413@pistoncloud.com"
type="cite">
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div>-- </div>
<div>Christopher MacGown, CTO</div>
<div><span style="font-size: 13px; ">
<div style="border-collapse: separate; color: rgb(0, 0,
0); font-family: Helvetica; font-style: normal;
font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal;
text-transform: none; white-space: normal; word-spacing:
0px; -webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; word-wrap: break-word;
-webkit-nbsp-mode: space; -webkit-line-break:
after-white-space; font-size: 13px; ">Piston Cloud
Computing, Inc.<br>
w: (650) 24-CLOUD</div>
<div style="border-collapse: separate; color: rgb(0, 0,
0); font-family: Helvetica; font-style: normal;
font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal;
text-transform: none; white-space: normal; word-spacing:
0px; -webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; word-wrap: break-word;
-webkit-nbsp-mode: space; -webkit-line-break:
after-white-space; font-size: 13px; ">m: (415) 300-0944<br>
<a moz-do-not-send="true"
href="http://www.pistoncloud.com" style="color: rgb(0,
106, 227); ">http://www.pistoncloud.com</a></div>
</span></div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
<br>
</body>
</html>