Open Stack

Thanks for the insight. Sounds like we are on the right track.

On Fri, Dec 14, 2012 at 10:21 AM, Dolph Mathews <dolph.mathews at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>