@dkocher commented

The change to the authentication context URL is currently a global configuration. Has the authentication protocol changed?

ac9ef7c commented

I don't believe the url has changed. It should be /auth/v1.0 for swauth. I do believe that the authentication context URL should not be a global variable.

In the meantime can you give a sample of the command to use to set the url to /auth/v1.0? I tried using the defaults command from the wiki but didn't have luck making it work.

@dkocher commented

Replying to [comment:2 devcamcar]:

I don't believe the url has changed. It should be /auth/v1.0 for swauth. I do believe that the authentication context URL should not be a global variable.

In the meantime can you give a sample of the command to use to set the url to /auth/v1.0? I tried using the defaults command from the wiki but didn't have luck making it work.

Using

defaults write ch.sudo.cyberduck cf.authentication.context /auth/v1.0

should work.

@dkocher commented

The need to change the authentiation context for swauth is documented in the OpenStack manual.

ac9ef7c commented

Thanks! I was able to get everything working using the correct defaults command.

I think it would be worth adding a customizable URL for the authentication endpoint though, since it can vary by swift installation.

@dkocher commented

I want the developers of Swift to provide a mean to remap or redirect authentication URLs handling this transparently. There should be no need for multiple possible URIs.

@dkocher commented

#5879 closed as duplicate.

@dkocher commented

#5892 closed as duplicate.

a28eae5 commented

I think this could potentially be an ongoing issue as other authentication backends are implemented for swift. It's very possible that any new auth backend could use a different auth endpoint. Until swauth (AFAIK), swift never even tried to perform any auth functions, relying on an external auth system and external token validation. I guess what I'm saying is that I don't feel that the auth URI is part of the swift protocol spec, and its location is completely arbitrary, and may vary on a per-provider basis.

I agree that it would be helpful to have a completely free-form auth URI, or at least the option to enter one.

Certainly not a criticism though, I do appreciate all your efforts.

@dkocher commented

Replying to [comment:10 rpedde]:

I think this could potentially be an ongoing issue as other authentication backends are implemented for swift. It's very possible that any new auth backend could use a different auth endpoint. Until swauth (AFAIK), swift never even tried to perform any auth functions, relying on an external auth system and external token validation. I guess what I'm saying is that I don't feel that the auth URI is part of the swift protocol spec, and its location is completely arbitrary, and may vary on a per-provider basis.

I agree that it would be helpful to have a completely free-form auth URI, or at least the option to enter one.

Certainly not a criticism though, I do appreciate all your efforts.

Thanks for your insights on this issue. If we want to support arbitrary authentication context paths, we will have to introduce another login prompt that allows to specify the path. But that would be quite a cumbersome login process for the average user.

@dkocher commented

We should also follow the developments of Keystone.

Matt (2) commented

FYI, Keystone can now be found at https://github.com/openstack/keystone

@dkocher commented

Replying to [comment:14 Matt (2)]:

FYI, Keystone can now be found at https://github.com/openstack/keystone

Now a ticket at #6330.

@dkocher commented

Looks like Keystone restores interoperability with the default authentication context path at /v1.0.