Connect to S3 with web identity federation

The latest versions of Cyberduck & Mountain Duck now allow to connect to S3 by authenticating with an OpenID Connect (OIDC) identity provider.

Connections to S3 with web identity federation use AWS Security Token Service (STS) API to obtain temporary security credentials to authenticate with S3.

With web identity federation, you don’t need to (…) manage your own user identities. Instead, users of your app can sign in using a well-known external OpenID Connect (OIDC)-compatible IdP. They can receive an authentication token, and then exchange that token for temporary security credentials in AWS that map to an IAM role with permissions to use the resources in your AWS account. Using an IdP helps you keep your AWS account secure, because you don’t users to have long-term security credentials.

Default connection profiles for Google and Azure

Default connection profiles are provided to use Google or Azure AD as an identity provider in conjunction with AWS.

These default profiles will prompt users for the Role ARN configured in AWS IAM referencing the trust relationship configured with the identity provider. Assigned by AWS this has a format similar to arn:aws:iam::930717317329:role/my-role-name.

Configuration in AWS IAM

  1. Add an identity provider in IAM. Refer to the documentation from AWS.
  2. Assign a role. The role is crucial as it contains both the trust relationship with the identity provider and permission policy:
  • The trust policy restricts access to users authenticated with a specific identity provider and allows to filter for specific users in the Condition statement with access to the JSON Web Token (JWT) claims that can be matched.
  • With the permission policy attached it limits access to a predefined set of buckets or keys.

Refer to the AWS documentation on Creating a role for web identity or OpenID Connect Federation.

The role that your application assumes must trust the identity provider that is associated with the identity token. In other words, the identity provider must be specified in the role’s trust policy. The call to AssumeRoleWithWebIdentity should include the ARN of the role that is specific to the provider through which the user signed in.

Custom Integration

We have made available documentation to write your own connection profile for different combinations of S3/STS and identity provider such as MinIO S3 authenticating with MinIO STS and Keycloak (OIDC).

Documentation

Refer to our S3 documentation.

SMB Protocol Support

SMB (Server Message Block) is used to access Windows File Shares or a Samba Linux Server. Cyberduck 8.7.0 adds support to access SMB shares as an light-weight, performant alternative to built-in support in macOS and Windows. Support in Mountain Duck is forthcoming in version 5.

Connecting to SMB

To connect to your SMB (formerly known as CIFS (Common Internet File System) server such as a NAS (Network Attached Storage) using NTLM authentication, select SMB (Server Message Block) in Open Connection or the Bookmark configuration. The default domain name is set to “WORKGROUP” and can be changed to meet the username format requirement depending on the server setup.

SMB Share

You will provided with a list of available shares from the server or alternatively if not supported prompted to input the share name manually. Specify the share name as a Path in the bookmark to avoid connect to a single share.

Up-to-date information about SMB interoperability can be found in out documentation.

Alternative to the official Dropbox client

Dropbox recently adopted the File Provider API available on macOS to be used as the exclusive way to synchronize files with their own app. The most prominent change from a user perspective is the limitation to store all synchronized files in ~/Library/CloudStorage as required by the File Provider API. Many users with large data sets preferred to set a custom location on an external disk previously which is no longer an option.

Use Mountain Duck instead of the official Dropbox client

Mountain Duck is a viable alternative to the official Dropbox client. It allows to connect to and synchronize your files in Dropbox without any additional bloat. In Mountain Duck Preferences, you can change your cache location to a different folder or even to an external drive.

Connecting to Dropbox

Mounting your Dropbox in Finder is straight forward using Mountain Duck:

  • Select Open Connection within the Mountain Duck dropdown menu
  • A new bookmark window will pop up
  • Select Dropbox from the protocol section on the top and choose Connect
  • Your web browser will open leading you through the authentication and authorization flow

Once successfully connected, your files from Dropbox will open in Finder. To connect to a single folder instead of the root, add a path to your bookmark configuration. Without adding a Path to the bookmark configuration, you will be connected to the root of your Dropbox.

Connect to multiple accounts

Connect to and work with multiple Dropbox accounts simultaneously. Repeat the above steps to connect to an additional Dropbox account you may have access. Open a new bookmark and login to the other Dropbox account in your web browser when authorizing access for Mountain Duck.

Use Cyberduck to retrieve files from Dropbox without syncing

Alternatively, use Cyberduck to browse your Dropbox without syncing the files to your computer.

Box

Cyberduck 8.2 and Mountain Duck 4.10.0 introduce support for accessing Box not only through their FTP or WebDAV gateway but using the native Box API. This should not only improve performance but additionally allow enabling two-factor authentication (2FA) for the account. The new implementation allows to create download and upload shares of files or folders for people who are not Box users by using File → Share…in Cybereduck or Create Download Share or Create Upload Share from the Mountain Duck context menu respectively.

Download Mountain Duck as an alternative to Box Drive.

🏠 Moving to GitHub

We previously only had mirror repository for Cyberduck on GitHub and managed pull requests for changes on our own Git server and mirrored all changes to a SVN repository which was used to display a timeline of changes in Trac.

We are now using the repository on GitHub as the primary source root and accept pull requests at the same place. Previous milestone history has been preserved. This will make contributions more straightforward and simplify the development setup for many.

Issues

We now use Github as well to manage all issues containing bug reports or feature requests. We have migrated all previous 11919 tickets opened in Trac since 2005 to GitHub.

Documentation

Additionally we will also retire the current documentation in the Wiki and move it to docs.cyberduck.io. Contributions to the documentation written in Markdown are welcome can be made by opening a pull request.