Configuring SAML Single Sign-On (SSO) with Okta

Configuring SSO for Okta requires setting up an Application within your Okta instance and a corresponding SSO configuration in Cerberus FTP Server. A few options must be mirrored between the two to establish trust, then some configuration must be added in Okta to sufficiently identify SSO users. 

Overview

1. Create an Okta Application Integration (Okta App)
2. Create the Cerberus SSO Configuration (SSO Config)
3. Synchronize SAML settings between the SSO Config and the Okta App
   • Audience URI (SP Entity ID)
   • Single sign-on URL
   • Attribute Statements
   • Group Attribute Statements
4. Save the Okta App configuration
5. Finish Cerberus SSO Config
   • SAML 2.0 Details
   • Signing Certificate
   • Default Mapping Configuration
   • Enable and Save
6. Enable SCIM Provisioning in the SSO Config
7. Enable Provisioning in the Okta App
   
8. Add Users and Groups to the Okta App
9. Test SSO

 

Create an Okta Application Integration (Okta App)

Begin by creating an Okta Application Integration (Okta App). Note you will stop at the point of configuring SAML options and switch to Cerberus FTP Server.

In the Okta administration console, browse to Applications > Applications and click Create App Integration

For the Sign-in method, choose SAML 2.0:

Choose an App name that fits your deployment scenario. This example uses the generic name “Cerberus FTP Server”:

At the Create SAML Integration step, switch to Cerberus FTP Server to generate a Single sign-on URL and other options.

 

Create the Cerberus SSO Configuration (SSO Config)

In the Cerberus Admin Console, create a new SSO configuration and synchronize values between it and the Okta App.

Begin by clicking SSO Users in the navigation bar, then the New SSO button

In the Identity Provider pull-down, choose Okta, then enter a descriptive name for the SSO configuration. This name will appear on the Cerberus login page, so choose a name that your end-users will understand.

In this example, we use the generic description, “Okta SSO”:

Synchronize SAML settings between the SSO Config and the Okta App

1. Audience URI
   The Audience URI is used to uniquely identify the Cerberus SSO Config during SAML message exchange. Conventionally, this is in a URI format, but may simply be a descriptive plain-text name. In this example, we’ll use a generic name “LocalhostCerberusFTPService”:
   
   
   Ensure this string matches the Audience URI (SP Entity ID) option in your Okta App
   
   
   
2. Single sign-on URL
   The Single sign-on URL informs the Okta App how to reach the Cerberus service for SSO messages. This must be created in the Cerberus SSO Config and synchronized in the Okta App
   
   Use the pull-down menu, Port option, and “plus” button to create a Single sign-on URL. Choose a hostname that is visible to your SSO end-users. In this example, we will use “localhost”, however production environments will typically use an externally-facing hostname.
   
   Synchronize this value with the Okta App’s Single sign-on URL
   

 

3. Set the Okta App Application username to “Okta username”. This is the default.
   
4. Attribute Statements

Attributes are used during SAML SSO message exchange to inform Cerberus of users’ attributes. By default, Cerberus looks for the following attributes:

For Cerberus to correctly identify SSO users, the Okta App must provide these attributes. The most important of these are Login Name and Email. Add all the attributes that your Okta schema supports

5. Group Attribute Statements
   Before Cerberus Group to Group policies can be used, Okta must inform Cerberus of the groups that an SSO user is a member of. To do so, the Okta App must provide Group Attribute Statements in the SAML SSO messages. Likewise, the Cerberus SSO Config must be told which attributes provide group membership details.
   
   In this example, we will configure only a single Group Attribute. If necessary, Cerberus can accept multiple Group Attributes.
   
   In the Okta App, add a Group Attribute as below:
   
   This instructs the Okta App to inform Cerberus of all in-scope groups the user is a member of.
   
   The Cerberus SSO Config is pre-configured with a “groups” attribute to match:
   
   Note: The Type property tells Cerberus what type of data to expect in the group membership attribute. Okta identifies groups through their display name. Other Identity Providers use a GUID. Leave this option set to Group Name for Okta.
   
   

Save the Okta App configuration

1. Click Next in the Okta App configuration
   
2. Click Finish
   Okta requests Feedback in the final step. For simplicity, choose “I’m an Okta customer adding an internal app” and “This is an internal app that we have created”
   

   

Finish Cerberus SSO Config

Once the Okta App is saved, we must retrieve a few properties to complete the Cerberus SSO Config

1. SAML 2.0 Details
   The Sign on URL, Sign out URL and Issuer values must be identical between the Okta App and the SSO Config
   
   Within the Okta App, choose the Sign On tab
   
   
   

Then browse to the SAML 2.0 section and expand the More details drop-down:

Copy Sign on URL, Sign out URL, and Issuer from here to their corresponding places in the Cerberus SSO Config (Note that these items appear in different order in the SSO Config):

2. Signing Certificate
   Retrieve the signing certificate from Okta App and upload to the SSO Config
   The next section of the SAML 2.0 details is the Signing Certificate. Click Download and save the certificate to file:
   
   Now in the Cerberus SSO Config click the Upload button:
   
   By default, Okta Apps sign both the Response and Assertion parts of the SAML message. If your environment is different, update the Signing pull-down to duplicate your Okta App settings. Signing behavior for Okta can be viewed under the General tab and the SAML Settings panel:
   
   
   
3. Default Mapping Configuration
   The last section of the SSO Config describes the default file access policies applied to all users who authenticate through this configuration. In this example, all SSO users will be treated as members of the IT Group, receiving all permissions and virtual directories assigned to this group:

In your environment, these settings should be customized for your users.

4. Enable and Save
   Back at the top of the SSO Config click the Enable button and then the Save button:
   

Enable SCIM Provisioning in the SSO Config

Before Cerberus can be used to set user and group based policies, Okta must be instructed to provision users and groups to Cerberus.

 

First, configure Cerberus to listen for provisioning messages from Okta. In the SSO Config, click the SCIM Provisioning tab:

 

Use the Build Tenant URL controls to populate the Tenant URL with an externally-facing hostname and URL:

 

Click the Generate Password Button:

Finally, Enable and Save. The Tenant URL and Secret Token generated here will be used to configure provisioning in the Okta App.

Enable Provisioning in the Okta App

In the Okta App browse to the General tab, the App Settings panel, and click the Edit button. Enable the Provisioning checkbox and Save.

A new Provisioning tab will appear in the Okta App. Navigate to this tab and click the Edit button. 

1. Copy the Tenant URL value from the Cerberus SSO Config (under the SCIM Provisioning tab) into the SCIM connector base URL field.
2. Enter the text “userName” in the Unique identifier field for users item
3. Under Supported provisioning actions check
   1. Push New Users
   2. Push Profile Updates
   3. Push Groups
4. Change the Authentication Mode option to “HTTP Header”
5. Copy the Secret Token   from the Cerberus SSO Config (under the SCIM Provisioning tab) into the Authorization Bearer field.

When done, the SCIM Connection panel will look similar to this:

Click the Test Connector Configuration button. The next dialog should display the following upon success:

Troubleshooting and resolving 'unable to find valid certification path to requested target' error.

Should you encounter the error in this screenshot:

Check the certificate you have installed in Cerberus at 'Server Manager' > 'Security' > 'General' into the server certificate and to see if you need to split out the intermediate certificates, and then install the intermediate certs into the 'CA Certificate Path' field in the SSL configuration in Cerberus.

Once you have a successful test, click Close, then Save

Finally, Click the Provisioning tab, then the To App link and the Edit link to enable provisioning for Create Users, Update User Attributes, and Deactivate Users:

 

Click the Save button

Add Users and Groups to the Okta App

Users will not be able to SSO into Cerberus until they’ve been assigned to the Okta App. Additionally, Cerberus FTP Server is unable to see group membership unless the user’s groups have been assigned to the Okta App. 

For this example, assign one user and one group to the Okta App, confirm that the users were provisioned to Cerberus, and then test SSO.

Browse to the Okta App page through the Applications page. Select the application representing Cerberus FTP Server (“Cerberus FTP Server” in this example). Click the Assign drop-down and choose Assign to People:

 

In the next dialog, add the user “test_one@redwood.com” and click the Assign button:

 

Then click Save and Go Back:

Next we will add a test group by clicking the Assign drop-down and choose Assign to Groups:

 

Add a test group named IT and Assign:

 

When finished, both the initial user and all members of IT are assigned to the application:

 

You may need to explicitly push groups from the Okta App to the Cerberus SSO Config. To do so, click the Push Groups tab of the Okta App, then the + Push Groups button:

 

In the example, try finding the group by name. The group does not yet exist in the Cerberus SSO Config, so the Create Group option is expected to appear. Click Save to push the group to the SSO Config:

 

At this point, you should be able to confirm that the SSO Config has had the users and groups provisioned by checking the SCIM Provisioning tab:

 

Test SSO

Now that all Users and Groups have been both assigned to the Okta App and provisioned to the SSO Config you can test Single Sign On.

Browse to the external HTTP Listener (Web Client) that will be used by your SSO users. The SSO button should appear, displaying your SSO Config:

Click the SSO login button and you should be redirected to Okta for authentication:

Once successfully authenticated, the user will be redirected to the Cerberus Web Client:

Once the user has authenticated with Okta, they will be able to SSO to the Cerberus Web Client without being required to provide username and password.