Open Stack

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.

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).


-Dolph



On Fri, Dec 14, 2012 at 11:47 AM, Mark Washenberger <
mark.washenberger at markwash.net> wrote:

> I was definitely under the mistaken impression that adminURL was
> intended to support public. Thanks for clearing things up.
>
> Is it just a terrible idea to support administrative CRUD over public
> networks? It seems like some of the previous talk about decentralizing
> user and tenant administration would eventually lead to a feature
> request to make adminURL publicly accessible.
>
> (As a bonus, if you're only interested in auth validation, the PKI
> token validation seems great for achieving this decentralization.)
>
> On Fri, Dec 14, 2012 at 9:32 AM, Dolph Mathews <dolph.mathews at gmail.com>
> wrote:
> > Side note -- "service" is an overloaded term here-- I was using it to
> > contrast with "administrative," not to refer to the clients that are
> > consuming it on behalf of other web services.
> >
> > Your impression is entirely accurate.
> >
> > Background: Identity API v2 defines both a "service API" and "admin API."
> > The "service API" is architected such that it can be deployed publicly on
> > the Internet and exposes nothing but auth. The "admin API" is, with one
> > exception, a superset of the "service API" and also exposes auth
> validation
> > and administrative CRUD operations for things like users, tenants, etc.
> It
> > was intended to be deployed on a secure network.
> >
> > So, in terms of the "public", "internal" and "admin" endpoints published
> in
> > the service catalog by keystone, the "service API" is expected to be
> > available as both the "public" and "internal" endpoints. The "admin API"
> > obviously falls into the "admin" endpoint, which is assumed/implied to be
> > internal.
> >
> > You asked about support for an "internal admin" interface type, but
> that's
> > exactly what "admin" is intended to be... I wanted to clarify that we
> > *don't* have a use case for the inverse, "public admin", since (I'm
> > assuming) you were thinking that's what "admin" was?
> >
> >
> > -Dolph
> >
> >
> >
> > On Fri, Dec 14, 2012 at 11:10 AM, Mark Washenberger
> > <mark.washenberger at markwash.net> wrote:
> >>
> >> Oh, perhaps not? I was under the (hopefully mistaken!) impression that
> >> keystone administration and service-level actions required use of the
> >> admin interface. For example, tenant administration and (UUID) token
> >> validation. I reassured myself that this was the case with some manual
> >> tests in a devstack deployment, but please let me know if I've made
> >> some mistake.
> >>
> >> Thanks
> >>
> >> On Thu, Dec 13, 2012 at 6:00 PM, Dolph Mathews <dolph.mathews at gmail.com
> >
> >> wrote:
> >> > Is there an API that needs to distinguish between "public service" and
> >> > "public administrative" interfaces? (in addition to "internal service"
> >> > and
> >> > "internal administrative")
> >> >
> >> >
> >> > -Dolph
> >> >
> >> >
> >> >
> >> > On Thu, Dec 13, 2012 at 6:50 PM, Mark Washenberger
> >> > <mark.washenberger at markwash.net> wrote:
> >> >>
> >> >> I guess my question then becomes, should we support an
> external/public
> >> >> admin use case?
> >> >>
> >> >> Thanks!
> >> >>
> >> >> On Thu, Dec 13, 2012 at 1:05 PM, Dolph Mathews
> >> >> <dolph.mathews at gmail.com>
> >> >> wrote:
> >> >> > I think it's meant to be implied that the "admin" endpoint is also
> >> >> > internal.
> >> >> >
> >> >> > auth_token should certainly consume the service catalog (via
> >> >> > keystoneclient,
> >> >> > ideally). Moving auth_token into keystoneclient itself was a first
> >> >> > step
> >> >> > in
> >> >> > that direction, IMO.
> >> >> >
> >> >> >
> >> >> > On Thursday, December 13, 2012, Mark Washenberger wrote:
> >> >> >>
> >> >> >> Hi keystone folks,
> >> >> >>
> >> >> >> When I do keystone help endpoint-create, I see
> >> >> >>
> >> >> >>   --publicurl <public-url>
> >> >> >>                         Public URL endpoint
> >> >> >>   --adminurl <admin-url>
> >> >> >>                         Admin URL endpoint
> >> >> >>   --internalurl <internal-url>
> >> >> >>                         Internal URL endpoint
> >> >> >>
> >> >> >> Is there any reason why we don't support an internal admin use
> case?
> >> >> >>
> >> >> >> If we did, we might be able to make the auth_token middleware use
> >> >> >> its
> >> >> >> own service catalog instead of a configured default for validating
> >> >> >> (uuid) tokens, which I would imagine could help out with some
> >> >> >> deployer
> >> >> >> migration scenarios.
> >> >> >>
> >> >> >> Any thoughts? Should I write up a brief blueprint?
> >> >> >>
> >> >> >> markwash
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> OpenStack-dev mailing list
> >> >> >> OpenStack-dev at lists.openstack.org
> >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> >
> >> >> > -Dolph
> >> >> >
> >> >> > _______________________________________________
> >> >> > OpenStack-dev mailing list
> >> >> > OpenStack-dev at lists.openstack.org
> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >> >
> >> >>
> >> >> _______________________________________________
> >> >> OpenStack-dev mailing list
> >> >> OpenStack-dev at lists.openstack.org
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121214/21613558/attachment.html>