Unable to auth against nova with keystone enabled novaclient ...

305 Use Proxy is what the middleware returns if it gets a call without an
auth token.

Sounds like nova client is making an auth call (POST /tokens) to Nova
(instead of Keystone)?

Z

On 8/8/11 12:39 PM, "SandyWalsh"
<email address hidden>
 wrote:

>keystone is running (listening on 0.0.0.0). Using 2.6.0 of novaclient,
>which has keystone auth support.
>
>novaclient error:
>
>http://paste.openstack.org/show/2120/
>
>----
>Nova configuration, as per keystone readme
>
>swalsh@novadev:~/openstack/v1.1_novaclient$ less ../nova.conf
>--verbose
>--nodaemon
>--connection_type=fake
>--scheduler_driver=nova.scheduler.host_filter.HostFilterScheduler
>--sql_connection=mysql://root:nova@192.168.2.109/nova
>--s3_host=192.168.2.109
>--network_manager=nova.network.manager.FlatManager
>--flat_network_bridge=xenbr0
>--allow_admin_api=true
>--image_service=nova.image.glance.GlanceImageService
>--enable_zone_routing=true
>--rescue_timeout=86400
>--xenapi_inject_image=false
>--use_ipv6=false
>--flat_injected=true
>--ipv6_backend=account_identifier
>--ca_path=./nova/CA
>--build_plan_encryption_key=c286696d887c9aa0611bbb3e2025a45a
>--api_paste_config=/home/swalsh/github/keystone/examples/paste/nova-api-pa
>ste.ini
>
>--
>Reply to this email directly or view it on GitHub:
>https://github.com/rackspace/keystone/issues/130

This email may include confidential information. If you received it in error, please delete it.

Observation: the request has an "X-Auth-Key" but no "X-Auth-Token"

(Didn't mean to close!)

Ah, of course ... where do I set the redirect management URL? somewhere in .../etc/keystone.conf?

Hmm, actually, wouldn't it be easier to have the nova middleware redirect me to the keystone auth server if it doesn't see a token? It knows where keystone lives from the middleware, no? That way we don't have to change novarc.

The 305 proxy should return the URL to Keystone...

On 8/8/11 1:43 PM, "SandyWalsh"
<email address hidden>
 wrote:

>Hmm, actually, wouldn't it be easier to have the nova middleware redirect
>me to the keystone auth server if it doesn't see a token? It knows where
>keystone lives from the middleware, no? That way we don't have to change
>novarc.
>
>--
>Reply to this email directly or view it on GitHub:
>https://github.com/rackspace/keystone/issues/130#issuecomment-1756840

This email may include confidential information. If you received it in error, please delete it.

ah, nice ... actually I think that was addressed in a pending novaclient pull request, I'll get that in there.

(sorry for the n00b questions, still wrapping my head around it)

Cool. BTW, that might change... see http://etherpad.openstack.org/KeystoneV2API. Particularly:

Use cases:
1. I have a Nova endpoint and don't know what credentials to use:
    A. GET returns either a 305 or 401.
            305 if it supports Rackspace Token Auth
            401 if it does not
            in either case, it also returns WWW-Authenticate headers indicating supported protocols:
                WWW-Authenticate: Basic realm="xxxx"
                WWW-Authenticate: Keystone uri="https://identity.rackspace.com:8080"
                NOTE: URI is version agnostic and version list not reutrned - query Keystone for versions.
    B. Choose authentication method and follow that method's protocol.
    NOTE: we implement this on the middleware.
    NOTE: This follows HTTP standards, is browser friendly, and backwards compatible with current Rackspace cloud protocol which responds with 305.

2. I now have the URI for Keystone, and I want to find out what credentials to use:
GET / returns verion list
GET /v# returns version info
GET /v#/extensions returns extensions which may include:
    - OAUTH
    - SAML
    - ec2 Creds
    - Rackspace API Key creds
NOTE: Keystone always supports Token Auth with passwordCredentials (this is core)

n00b or not, thanks for digging in, integrating, and asking the questions :-)

one last question, where do I tell keystone where the nova server resides?

I get the proxy redirect and it points me to keystone, but how does keystone know which management-url to return?

So I added the redirect handling code to novaclient and I get the same error as hitting keystone directly

404 error

http://paste.openstack.org/show/2124/

The redirect is giving 127.0.0.1:5001 ... which is asking for GET / ... which I assume has no route.

Should we be fixing up the URL on the client side, or assume what we get from the 305 to be gospel?

Handling
"WWW-Authenticate: Keystone uri="https://identity.rackspace.com:8080"
                NOTE: URI is version agnostic and version list not reutrned - query Keystone for versions.
and Choose authentication method and follow that method's protocol."
implemented in novaclient `discover` feature: https://review.openstack.org/#change,1825

Can this be closed, Kevin?

I think we have the headers and responses coded correctly now in auth_token. If there is any change needed, we'd have to make sure nova client (or python-keystoneclient) support it. We could move this bug to there...

I think this particular bug can be closed.