AWS Storage Blog

Using Okta as an identity provider with AWS Transfer for SFTP

AWS Transfer for SFTP (AWS SFTP) is a fully managed service that enables you to move file transfer workloads to AWS when they use the Secure Shell File Transfer Protocol (SFTP). Enterprises and startups across a range of industries can use AWS SFTP without needing to modify applications or manage any SFTP servers.

Data uploaded or downloaded over SFTP is available in your Amazon S3 bucket, and can be used for archiving or processing in AWS. The service supports two ways of managing end users who can exchange files through your AWS managed SFTP server:

Last month, we showed you how to integrate AWS Secrets Manager to enable password authentication. In this post, I demonstrate how you can integrate Okta as your IdP for AWS SFTP, using Okta’s Authentication API.

According to Okta’s website, “The Okta Authentication API provides operations to authenticate users, perform multi-factor enrollment and verification, recover forgotten passwords, and unlock accounts. It can be used as a standalone API to provide the identity layer on top of your existing application.”

Custom IdP primer

When you create an SFTP server, you can integrate your existing IdP into the service using an Amazon API Gateway method with a RESTful interface, backed by an AWS Lambda function. This IdP can be Microsoft Active Directory, Okta, or any custom datastore that you use as a part of an overall access provisioning system. When using the IdP mode with AWS SFTP, you supply the API Gateway method. AWS SFTP invokes this method to authenticate your SFTP users.

The following diagram and description summarizes the overall workflow of this solution:

 

  1. Using the provided AWS CloudFormation template provided below, set up an API using API Gateway and the corresponding Lambda function for authentication with the Okta Authentication API.
  2. Next, use the API Gateway URL during AWS SFTP server creation. Steps 1 and 2 are one-time efforts required during set up.
  3. An end user attempts to log in, supplying the Okta user name and password.
  4. AWS SFTP passes these credentials to the API Gateway endpoint that you provided when you created the server (step 1). The API is integrated with a Lambda function.
  5. The AWS SFTP server uses the API Gateway URL backed by the Lambda function to query Okta and validate the end user’s credentials.
  6. The response from API Gateway authorizes the end user and grants access to your S3 bucket.

Okta setup

To begin, you need an Okta org. For this post, I created a demo Okta account and a few Okta users. I use these test users later in this post when I log in to the AWS SFTP server using an SFTP client.

For your setup, note the following:

  • Okta Authorization API URL (such as https://<YOUR-OKTA-ENDPOINT>/api/v1/authn)
  • Domain part of user’s sign-in for Okta (For example, for janedoe@amazon.com, the domain is amazon.com.)

IAM roles, Lambda function, and API Gateway setup

You need an Amazon S3 bucket, so create a bucket or use an existing bucket and note its name. You use it later in this post.

Create a new AWS CloudFormation stack by downloading the CloudFormation template.

The CloudFormation template creates the required IAM roles for access, and the Lambda function and API Gateway. When the CloudFormation stack has completed creating successfully, note the outputs such as the API Gateway URL and invocation role, which allows the service to invoke your API Gateway endpoint.

AWS SFTP setup

  • Open the AWS SFTP
  • Under New SFTP server, choose Create Server and enter the following values:
    • For Endpoint type, choose Public.
    • For Identity provider type, choose Custom.
    • For Custom provider, enter a value of TransferIdentityProviderUrl (the output of the CloudFormation template used earlier).
    • For Invocation Role, select a role that has TransferIdentityProviderRole in the name.
    • For Logging Role, select a role that has TransferSFTPCloudWatchLogsWriteLogs in the name.
  • Choose Create server and note the Server ID value for later use.
  • Make sure that the State column says Online for the newly created SFTP server.

Testing

To test the above configuration, you can use TestIdentityProvider API. Provide the AWS SFTP server’s endpoint, your Okta username, and password. Verify you can log in and access your home directory. You can also use any SFTP client to validate your access.

The following code is an example of calling the TestIdentityProvider API, using the AWS CLI.

aws transfer test-identity-provider —server-id <SFTP Transfer Server ID> —user-name <Okta User Name> —user-password <Okta User Password>

The command returns following fields:

  • Message (string)—The result of the authorization test as a message.
  • StatusCode (integer) —The HTTP status code that is the response from API Gateway.
  • Url (string) —The endpoint of the service used to authenticate a user.

The following screenshot shows an example of a successful login.

A failed login would have an empty Message field, as in the following screenshot.

At this point, you can test your AWS SFTP server’s integration with Okta using an SFTP client like Cyberduck or an OpenSSH client. When the tests are successful, you can point the API to your existing Okta org and set up the required access, so your end users can begin using the service.

Cleaning up

If you are just testing, don’t forget to delete your server and clean up any other resources. If you’re deploying to production, build on!

Summary

I demonstrated how you can integrate Okta as your IdP for AWS SFTP, using Okta’s Authentication API. With this solution you now have a fully managed, highly available SFTP service that uses Okta as the custom identity provider for your end-users. Thank you, and welcome onboard!