<tt><font size=2>> 1. There doesn't seem to be any non-global way to
prevent oauth accesskeys<br>
> from expiring.  We need delegation to last the (indefinite) lifetime
of the<br>
> heat stack, so the delegatation cannot expire.<br>
> 2. Most (all?) of the oauth interfaces are admin-only.  I'm not
clear if<br>
> this is a blocker, but it seems like it's the opposite of what we
currently<br>
> do with trusts, where a (non-admin) user can delegate a subset of
their<br>
> roles via a trust, which is created using their token.</font></tt>
<br>
<br><font size=2 face="sans-serif">For issue #2, I think you're right,
we should probably make the oauth interfaces </font><a href=https://github.com/openstack/keystone/blob/master/etc/policy.json#L109..L114><font size=2 face="sans-serif">https://github.com/openstack/keystone/blob/master/etc/policy.json#L109..L114</font></a><font size=2 face="sans-serif">
have the same policy as the trust ones, (user_id:%(trust.trustor_user_id)s).</font>
<br><font size=2 face="sans-serif"><br>
#1 is a bit more work, it would definitely be a new blueprint. </font>
<br>
<br><font size=2 face="sans-serif">I'll see what I can do about providing
a more realistic example.</font>
<br><font size=2 face="sans-serif"><br>
</font>
<br><font size=1 face="Arial">Regards,</font>
<br>
<br><font size=3 color=#8f8f8f face="Arial"><b>Steve Martinelli</b></font><font size=1 face="Arial"><br>
Software Developer - Openstack<br>
Keystone Core Member</font>
<table width=680 style="border-collapse:collapse;">
<tr height=8>
<td width=680 colspan=2 style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;">
<hr>
<tr valign=top height=8>
<td width=420 style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=1 color=#4181c0 face="Arial"><b>Phone:</b></font><font size=1 color=#5f5f5f face="Arial">
1-905-413-2851</font><font size=1 color=#4181c0 face="Arial"><b><br>
E-mail:</b></font><font size=1 color=#5f5f5f face="Arial"> </font><a href=mailto:stevemar@ca.ibm.com target=_blank><font size=1 color=#5f5f5f face="Arial"><u>stevemar@ca.ibm.com</u></font></a>
<td width=259 style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;">
<div align=right><font size=1 color=#5f5f5f face="Arial">8200 Warden Ave<br>
Markham, ON L6G 1C7<br>
Canada</font></div></table>
<br>
<br>
<br><tt><font size=2>Steven Hardy <shardy@redhat.com> wrote on 06/02/2014
06:41:48 AM:<br>
<br>
> From: Steven Hardy <shardy@redhat.com></font></tt>
<br><tt><font size=2>> To: "OpenStack Development Mailing List
(not for usage questions)" <br>
> <openstack-dev@lists.openstack.org>, </font></tt>
<br><tt><font size=2>> Date: 06/02/2014 06:43 AM</font></tt>
<br><tt><font size=2>> Subject: Re: [openstack-dev] [solum] [mistral]
[heat] keystone <br>
> chained trusts / oauth</font></tt>
<br><tt><font size=2>> <br>
> Hi Angus,<br>
> <br>
> On Wed, May 28, 2014 at 12:56:52AM +0000, Angus Salkeld wrote:<br>
> > -----BEGIN PGP SIGNED MESSAGE-----<br>
> > Hash: SHA1<br>
> > <br>
> > Hi all<br>
> > <br>
> > During our Solum meeting it was felt we should make sure that
all three<br>
> > team are on the same page wrt $subject.<br>
> > <br>
> > I'll describe the use case we are trying to solve and hopefully
get some<br>
> > guidance from the keystone team about the best way forward.<br>
> > <br>
> > Solum implements a ci/cd pipeline that we want to trigger based
on a git<br>
> > receive hook. What we do is generate a magic webhook (should
be<br>
> > ec2signed url - on the todo list) and when it is hit we want<br>
> > to call mistral-execution-create (which runs a workflow that
calls<br>
> > to other openstack services (heat is one of them).<br>
> > <br>
> > We currently use a trust token and that fails because both mistral
and<br>
> > heat want to create trust tokens as well :-O (trust tokens can't
be<br>
> > rescoped).<br>
> <br>
> So, I've been looking into this, and there are two issues:<br>
> <br>
> 1. On stack-create, heat needs to create a trust so it can do deferred<br>
> operation on behalf of the user.  To do this we will require
explicit<br>
> support for chained delegation in keystone, which does not currently
exist.<br>
> I've been speaking to ayoung about it, and plan to raise a spec for
this<br>
> work soon.  The best quick-fix is probably to always create a
stack when<br>
> the user calls Solum (even if it's an empty stack), using their<br>
> non-trust-scoped token.<br>
> <br>
> 2. Heat doesn't currently work (even for non-create operations) with
a<br>
> trust-scoped token.  The reason for this is primarily that keystoneclient<br>
> always tries to request a new token to populate the auth_ref (e.g
service<br>
> catalog etc), so there is no way to just validate the existing trust-scoped<br>
> token.  AFAICS this requires a new keystoneclient auth plugin,
which I'm<br>
> working on right now, I already posted a patch for the heat part of
the<br>
> fix:<br>
> <br>
> </font></tt><a href=https://review.openstack.org/#/c/96452/><tt><font size=2>https://review.openstack.org/#/c/96452/</font></tt></a><tt><font size=2><br>
> <br>
> > <br>
> > So what is the best mechanism for this? I spoke to Steven Hardy
at<br>
> > summit and he suggested (after talking to some keystone folks)
we all<br>
> > move to using the new oauth functionality in keystone.<br>
> > <br>
> > I believe there might be some limitations to oauth (are roles
supported?).<br>
> <br>
> I spent a bit of time digging into oauth last week, based on this
example<br>
> provided by Steve Martinelli:<br>
> <br>
> </font></tt><a href=https://review.openstack.org/#/c/80193/><tt><font size=2>https://review.openstack.org/#/c/80193/</font></tt></a><tt><font size=2><br>
> <br>
> Currently, I can't see how we can use this as a replacement for our
current<br>
> use-cases for trusts:<br>
> 1. There doesn't seem to be any non-global way to prevent oauth accesskeys<br>
> from expiring.  We need delegation to last the (indefinite) lifetime
of the<br>
> heat stack, so the delegatation cannot expire.<br>
> 2. Most (all?) of the oauth interfaces are admin-only.  I'm not
clear if<br>
> this is a blocker, but it seems like it's the opposite of what we
currently<br>
> do with trusts, where a (non-admin) user can delegate a subset of
their<br>
> roles via a trust, which is created using their token.<br>
> <br>
> What would be *really* helpful, is if we could work towards another<br>
> example, which demostrates something closer to the Solum/Heat use-case
for<br>
> delegation (as opposed to the current example which just shows an
admin<br>
> delegating their admin-ness).<br>
> <br>
> e.g (these users/roles exist by default in devstack deployments):<br>
> <br>
> 1. User "demo" delegates "heat_stack_owner" role
in project "demo" to the<br>
> "heat" service user.  The resulting delegation-secret
to be stored by heat<br>
> must not expire, and it must be possible for the "heat"
user to explicitly<br>
> impersonate user "demo".<br>
> <br>
> Until we can see how that use-case can be solved with oauth, I don't
think<br>
> we can make any progress on actually adopting it.<br>
> <br>
> The next part of the use-case would be working out how either a delegation<br>
> secret can be shared between services (e.g Solum/Heat), or how delegation<br>
> can be chained between services, but the first thing is working out
the<br>
> basic user->service delegation model IMO.<br>
> <br>
> Thanks,<br>
> <br>
> Steve<br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
</font></tt>