Cyberduck Mountain Duck CLI

#5735 closed defect (wontfix)

Swift authentication fails for installations using "swauth"

Reported by: devcamcar Owned by: dkocher
Priority: normal Milestone: 4.2
Component: openstack Version: 3.8.1
Severity: major Keywords: swift, swauth
Cc: Architecture:
Platform:

Description (last modified by dkocher)

Cyberduck is unable to authenticate users against a Swift installation when the installation is using "swauth", Swift's new authentication system introduced in the 1.2 release.

There are instructions that describe how to work around the issue at http://trac.cyberduck.ch/wiki/help/en/howto/openstack:

Context Path

To change the context of the URL from the default /v1.0, use the  hidden configuration option defaults write ch.sudo.cyberduck cf.authentication.context <string>.

However, I was unable to make the authentication work using this method. Also, it is unclear if this affects Swift globally within Cyberduck, though I assume it does.

So first issue is that I can't make it work by attempting to point it to /auth/v1.0 (which is what swauth wants).

The second issue is that this should be a per connection configuration and should not be treated as a global setting, as this URL will vary from installation to installation.

Change History (17)

comment:1 Changed on Mar 1, 2011 at 1:15:33 PM by dkocher

  • Milestone set to 4.1

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

comment:2 follow-up: Changed on Mar 1, 2011 at 10:44:51 PM by 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.

comment:3 in reply to: ↑ 2 Changed on Mar 2, 2011 at 7:14:06 AM by dkocher

Replying to 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.

comment:4 Changed on Mar 2, 2011 at 1:29:26 PM by dkocher

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

comment:5 Changed on Mar 14, 2011 at 4:18:46 PM by devcamcar

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.

comment:6 Changed on Mar 15, 2011 at 8:28:16 PM by dkocher

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:7 Changed on Apr 7, 2011 at 6:42:52 PM by dkocher

  • Resolution wontfix deleted
  • Status changed from closed to reopened

#5879 closed as duplicate.

comment:8 Changed on Apr 10, 2011 at 9:16:49 PM by dkocher

  • Description modified (diff)

comment:9 Changed on Apr 10, 2011 at 9:19:42 PM by dkocher

#5892 closed as duplicate.

comment:10 follow-up: Changed on Jun 8, 2011 at 8:35:24 PM by 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.

comment:11 in reply to: ↑ 10 Changed on Jun 9, 2011 at 9:13:39 AM by dkocher

  • Milestone changed from 4.1 to 4.2

Replying to 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.

comment:12 Changed on Jun 14, 2011 at 7:27:04 AM by dkocher

We should also follow the developments of Keystone.

comment:13 Changed on Jul 26, 2011 at 1:40:18 PM by dkocher

  • Milestone 4.2 deleted

comment:14 follow-up: Changed on Oct 24, 2011 at 3:35:58 PM by Matt (2)

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

comment:15 in reply to: ↑ 14 Changed on Oct 27, 2011 at 7:21:13 AM by dkocher

Replying to Matt (2):

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

Now a ticket at #6330.

comment:16 Changed on Oct 27, 2011 at 7:22:24 AM by dkocher

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

comment:17 Changed on Nov 6, 2011 at 10:43:42 AM by dkocher

  • Milestone set to 4.1.4
  • Resolution set to wontfix
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.
swiss made software