Open Stack

Thanks Dolph, Chmouel.

The entry for 'default_domain_id' was commented out in my
keystone.conf. I put it back in and left it set to 'default'. As
expected the database already has a domain in it with the id 'default'
and name 'Default'. I successfully retrieved a token using this,

{
    "auth": {
        "identity": {
            "methods": [
                "password"
            ],
            "password": {
                "user": {
                    "domain": {
                        "name": "Default"
                    },
                    "name": "admin",
                    "password": "secrete"
                }
            }
        }
    }
}

Using Chmouel's script the request was,

$ ks3.py -A http://<host>:5000/v3 -d Default -t demo -u admin -p secrete

Adrian


On 1 May 2013 21:59, Dolph Mathews <dolph.mathews at gmail.com> wrote:
> Unless the keystone.conf's default_domain_id points to a domain with a name
> of 'demo', then those credentials won't work on v2.0 at all, as non-default
> domain users are not visible to the v2.0 API.
>
>
> -Dolph
>
>
> On Wed, May 1, 2013 at 2:30 PM, Adrian Smith <adrian_f_smith at dell.com>
> wrote:
>>
>> The problem I have it actually retrieving a token from Keystone using
>> the v3 API. I'm POSTing a request to /v3/auth/tokens with a body like
>> this,
>>
>> {
>>     "auth": {
>>         "identity": {
>>             "methods": [
>>                 "password"
>>             ],
>>             "password": {
>>                 "user": {
>>                     "domain": {
>>                         "name": "demo"
>>                     },
>>                     "name": "admin",
>>                     "password": "secrete"
>>                 }
>>             }
>>         }
>>     }
>> }
>>
>> .. but receive an unauthorized response. I can successfully
>> authenticate using these credentials in v2.
>>
>> Adrian
>>
>>
>> On 1 May 2013 20:11, Dolph Mathews <dolph.mathews at gmail.com> wrote:
>> > This isn't something I've tested myself, but you should be able to get a
>> > v3
>> > token for a user and project in the default domain and have the
>> > keystoneclient middleware validate the token either offline or against
>> > the
>> > v2.0 API. What's the issue you're running into?
>> >
>> >
>> > -Dolph
>> >
>> >
>> > On Wed, May 1, 2013 at 1:29 PM, Adrian Smith <adrian_f_smith at dell.com>
>> > wrote:
>> >>
>> >> Assuming a user has retrieved a token from Keystone using the v3 API
>> >> can that token be consumed by Swift?
>> >>
>> >> Looking at the auth_token [1] middleware I presume it can but I'm
>> >> having trouble testing it in my environment.
>> >>
>> >> Are there any restrictions or gotchas to be aware of when using Swift
>> >> ACLs with Keystone v3?
>> >>
>> >> Thanks
>> >> Adrian
>> >>
>> >> [1]
>> >>
>> >> https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py
>> >>
>> >> _______________________________________________
>> >> 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
>