Identity API v3 rolls both of the existing API's under a single (consistent) umbrella, and makes it a deployment decision if you want to break it apart (just as it would be a deployment decision to decentralize user/tenant administration). For example, we might provide some optional middleware to whitelist authentication calls if you'd like to maintain parity with the current public API.<br>
<div><br></div><div>I personally think that auth validation should be available as a public, unauthenticated operation, since the token itself is a secret. If you already know the secret, why not provide the ability to validate (and perhaps revoke it) as well? With the implementation of v3, this will probably become a deployment option as well (in v2, nothing about the response is currently contextualized to the requestor, AFAIK).</div>
<div class="gmail_extra"><br clear="all"><div><div><br></div>-Dolph</div><br>
<br><br><div class="gmail_quote">On Fri, Dec 14, 2012 at 11:47 AM, Mark Washenberger <span dir="ltr"><<a href="mailto:mark.washenberger@markwash.net" target="_blank">mark.washenberger@markwash.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was definitely under the mistaken impression that adminURL was<br>
intended to support public. Thanks for clearing things up.<br>
<br>
Is it just a terrible idea to support administrative CRUD over public<br>
networks? It seems like some of the previous talk about decentralizing<br>
user and tenant administration would eventually lead to a feature<br>
request to make adminURL publicly accessible.<br>
<br>
(As a bonus, if you're only interested in auth validation, the PKI<br>
token validation seems great for achieving this decentralization.)<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Dec 14, 2012 at 9:32 AM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<br>
> Side note -- "service" is an overloaded term here-- I was using it to<br>
> contrast with "administrative," not to refer to the clients that are<br>
> consuming it on behalf of other web services.<br>
><br>
> Your impression is entirely accurate.<br>
><br>
> Background: Identity API v2 defines both a "service API" and "admin API."<br>
> The "service API" is architected such that it can be deployed publicly on<br>
> the Internet and exposes nothing but auth. The "admin API" is, with one<br>
> exception, a superset of the "service API" and also exposes auth validation<br>
> and administrative CRUD operations for things like users, tenants, etc. It<br>
> was intended to be deployed on a secure network.<br>
><br>
> So, in terms of the "public", "internal" and "admin" endpoints published in<br>
> the service catalog by keystone, the "service API" is expected to be<br>
> available as both the "public" and "internal" endpoints. The "admin API"<br>
> obviously falls into the "admin" endpoint, which is assumed/implied to be<br>
> internal.<br>
><br>
> You asked about support for an "internal admin" interface type, but that's<br>
> exactly what "admin" is intended to be... I wanted to clarify that we<br>
> *don't* have a use case for the inverse, "public admin", since (I'm<br>
> assuming) you were thinking that's what "admin" was?<br>
><br>
><br>
> -Dolph<br>
><br>
><br>
><br>
> On Fri, Dec 14, 2012 at 11:10 AM, Mark Washenberger<br>
> <<a href="mailto:mark.washenberger@markwash.net">mark.washenberger@markwash.net</a>> wrote:<br>
>><br>
>> Oh, perhaps not? I was under the (hopefully mistaken!) impression that<br>
>> keystone administration and service-level actions required use of the<br>
>> admin interface. For example, tenant administration and (UUID) token<br>
>> validation. I reassured myself that this was the case with some manual<br>
>> tests in a devstack deployment, but please let me know if I've made<br>
>> some mistake.<br>
>><br>
>> Thanks<br>
>><br>
>> On Thu, Dec 13, 2012 at 6:00 PM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>><br>
>> wrote:<br>
>> > Is there an API that needs to distinguish between "public service" and<br>
>> > "public administrative" interfaces? (in addition to "internal service"<br>
>> > and<br>
>> > "internal administrative")<br>
>> ><br>
>> ><br>
>> > -Dolph<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Thu, Dec 13, 2012 at 6:50 PM, Mark Washenberger<br>
>> > <<a href="mailto:mark.washenberger@markwash.net">mark.washenberger@markwash.net</a>> wrote:<br>
>> >><br>
>> >> I guess my question then becomes, should we support an external/public<br>
>> >> admin use case?<br>
>> >><br>
>> >> Thanks!<br>
>> >><br>
>> >> On Thu, Dec 13, 2012 at 1:05 PM, Dolph Mathews<br>
>> >> <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > I think it's meant to be implied that the "admin" endpoint is also<br>
>> >> > internal.<br>
>> >> ><br>
>> >> > auth_token should certainly consume the service catalog (via<br>
>> >> > keystoneclient,<br>
>> >> > ideally). Moving auth_token into keystoneclient itself was a first<br>
>> >> > step<br>
>> >> > in<br>
>> >> > that direction, IMO.<br>
>> >> ><br>
>> >> ><br>
>> >> > On Thursday, December 13, 2012, Mark Washenberger wrote:<br>
>> >> >><br>
>> >> >> Hi keystone folks,<br>
>> >> >><br>
>> >> >> When I do keystone help endpoint-create, I see<br>
>> >> >><br>
>> >> >> --publicurl <public-url><br>
>> >> >> Public URL endpoint<br>
>> >> >> --adminurl <admin-url><br>
>> >> >> Admin URL endpoint<br>
>> >> >> --internalurl <internal-url><br>
>> >> >> Internal URL endpoint<br>
>> >> >><br>
>> >> >> Is there any reason why we don't support an internal admin use case?<br>
>> >> >><br>
>> >> >> If we did, we might be able to make the auth_token middleware use<br>
>> >> >> its<br>
>> >> >> own service catalog instead of a configured default for validating<br>
>> >> >> (uuid) tokens, which I would imagine could help out with some<br>
>> >> >> deployer<br>
>> >> >> migration scenarios.<br>
>> >> >><br>
>> >> >> Any thoughts? Should I write up a brief blueprint?<br>
>> >> >><br>
>> >> >> markwash<br>
>> >> >><br>
>> >> >> _______________________________________________<br>
>> >> >> OpenStack-dev mailing list<br>
>> >> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> ><br>
>> >> > -Dolph<br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > OpenStack-dev mailing list<br>
>> >> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> OpenStack-dev mailing list<br>
>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > OpenStack-dev mailing list<br>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>