Skip navigation
All Places > Products > RSA SecurID Access > Blog > 2015 > October


What is this Howto about?

This guide will show you how to get Salesforce and SecurID Access configured in a way that makes SFDC a external identity provider to SecurID Access. This enables users to login to the Via Access portal using existing SFDC credentials.



  • SFDC instance with full admin access
  • SecurID Access instance with admin access
  • Shared user IDs (email addresses) between SFDC and Via Access
  • The logon ID format that Via Access expects must be what SFDC is configured to return e.g. eMail address)

IDP configuration on the Salesforce Side

Log into SFDC with an admin account.In the lower left corner you'll then see a menu called "Administration Setup".(If that doesn't show up click on "Setup" on the upper right corner)

Bare-bone IDP setup

Select "Security Controls"->"Identity Provider"SFDC_as_IDP_25.pngYou need to click on "Enable Identity Provider".In the following screen select "Create a new Certificate..."SFDC_as_IDP_26.pngGive the certificate a meaningful nameSFDC_as_IDP_3.pngHit "Save" and you'll see a screen with the details of the newly created certificate.You should download it by clicking "Download Certificate" - we'll need it later.SFDC_as_IDP_4.pngNow comes a strange step... either to back to the "Identity Provider" section like before or click "Back to List" on the certificate detail screen.Either way... you'll need to click again on "Enable Identity Provider" and this time select the certificate you just created.SFDC_as_IDP_5.pngOnce you clicked "Save" on that screen you are finished with the bare-bone IDP setup. You'll see a summary screen similar to the one below:SFDC_as_IDP_1.png

Setting up the Connected App (aka SP) definition at SFDC

From now on it's a good idea to have a separate browser window or tab open in the Via Access admin console.This part jumps a bit between Via Access and SFDC so be patient and pay attention.On your Identity Provider Setup screen click on the "Service Providers are now created via Connected Apps. Click here." link - or go to "App Setup"->"Create" ->"Apps" and then click "New" in the "Connected Apps" section of the screen.... I never said it's going to be easy.You'll see a screen like this:SFDC_as_IDP_27.pngFill in what you know or can make up on your own already:Names, email addresses etc.Provide your IDR portal URL for the "Start URL" in the "Web App Settings" sectionClick on "Enable SAML" in the "Web App Settings" just below the "Start URL" field.SFDC_as_IDP_28.pngNow we need to switch over to Via Access

Adding a SAML 2.0 IDP definition in Via Access

In RSA Via Access to to “users”→”Identity Providers” and click “Add an Identity Provider”.SFDC_as_IDP_8.pngClick "Add" for the "SAML 2.0 IDP"SFDC_as_IDP_9.pngGive it a meaningful name:SFDC_as_IDP_10.pngClick "Next Step"... the "Connection Profile Section" appears.

Let there be "Copy & Paste" - copying information from SFDC to Via Access and vice versa

This is the screen that has the info that you need to either fill in from the SFDC screen or that you need to copy over to SFDC.

Leave the Audience ID as it is and the Audience URL too.

  • Copy the Audience ID from Via Access and paste it into the SFDC screen under “Entity ID”
  • Copy the Audience URL from Via Access and paste it into the SFDC screen under “ACS URL”.
  • Copy the Issuer from SFDC into Via Access “Issuer ID”.
  • Copy the “SingleSignOnService” HTTP-Post binding URL from the SFDC Metadata file to the Issuer URL in Via Access
  • Upload the Certificate you downloaded earlier from SFDC by hitting “Select File” in the “Certificate” section of RSA Via Access and selecting the downloaded file.
  • Note on the SFDC side "Subject Type" was left at the default "Username". As username in SFDC is the email address you need to make sure Via Access is configured to accept the email address for logon. This is done in the "User store" section in the Via Access admin GUI. The "User Tag" must be "mail" (or email... depending on your LDAP schema). If you have it configured to accept sAMAccountName and you then use SFDC which sends eMails by default, you will be logged in but the user can't do anything.




The next screenshot is just FYI. It shows the user store setup of Via Access. Note the "mail" as the User Tag. If you have done that previously you are all set. If not... change it to "mail". The alternative is to configure SFDC to send the content of e.g. sAMAcountName - but that of course requires that this information is in SFDC. This could be e.g. the federationID or a custom attribute in SFDC. For this exercise we just assume everybody uses email as the login ID - which is common now.




Just for clarity... here is a screenshot of my SFDC IDP metadata XML file. Look at the URL I highlighted. That's the ACS (assertion consumption service) URL of SDFC. SFDC supports both POST and redirect binding for AuthNRequests - Via Access supports one POST so you have to copy that one.



In SFDC you now need to grant permissions to the appropriate user profiles to be able to access the "Via Access" Connected App. Without this SFDC will deny access (and with that outbound federation) every time.


On the "Connected  App" screen of "Via Access" scroll down to the "Profiles" section and click on "Manage Profiles":



Now you need to select the user profiles you want to be able to federate out to Via Access. In my case I selected both "System Administrator" and "Standard Platform User". This might be different in your environment. Standard Platform Users are the "normal" users and should work for most. The test user I used is an administrator so I had to select that profile too.




Click "Save" and then head back to Via Access.


Configuring the Authentication sources for Via Access


Now you need to add the newly defined SFDC IDP to the Authentication Sources of Via Access.

Click on “Access” → “Authentication Sources” and hit “Add”. Select “Salesforce” and hit “Save”


Now it should look something like this:


Publish the changes to the IDRs.

Then head over to the IDR portal

How the login into the IDR portal looks and behaves now

If you access the portal you'll see a new link at the bottom of the logon box that points to your SFDC IDP


Click it and you'll be redirected to SFDC



You can customize this page (left and right side) in the configuration screen of your custom domain. If you don't have a custom domain the standard SFDC login page will be shown.


Once you logged in you'll be redirected back to Via Access and see your portal page for the user you logged into at SFDC:



-> Success!

We were testing out deploying an IDR in vCloud Air to ensure the setup and configuration worked without any issues. Here is the process we ran through to successfully deploy an IDR in vCloud Air.


Import IDR OVA into vCloud Air Catalog


After you login into you vCloud Air Private Cloud you can create a VM within your VDC (Virtual Data Center). You can click on the Virtual Machines Tab and you will see the following:


Click on Create your first virtual machine and you will see the new vm wizard:


If you click on My Catalog it might be empty:


At this point you can click on Create My Virtual Machine from Scratch and it will take your vCloud instance:


From here you can upload the OVA into the default-catalog  (this inside vCloud Director under Catalogs -> default_catalog -> Upload) so you can use it as a template for multiple deployments:


Create a SNAT in vCloud Air

By default, most of the traffic is blocked and no NAT is configured so you can't reach the external network. To fix this first let's get a public IP. In vCloud air go to Gateways -> GATEWAY ON VDC1 -> Public IPs and initially it will look like this:


Then click on Add IP Address and it will warn you about getting charged and after that it will allocate the IP. Now let's create the SNAT, so any machine can reach the internet. Go to Gateways -> GATEWAY ON VDC1 -> NAT Rules -> Add a NAT Rule and fill out the following (make sure it matches your environment):


The firewall is pretty restrictive as well, so go to Gateways -> GATEWAY ON VDC1 -> Firewall Rules and the following basic rules:


Adding a second Organization Network

vCloud Director offers many different networking options, most of them are covered in vApp Design Considerations . By default there is Direct – External Organization Virtual Datacenter Network (Routed) network created, from the same page: Direct – External Organization Virtual Datacenter Network (Routed)
If the same example vApp with three virtual machines is connected to an organization virtual datacenter network that has a routed connection to an external network, the vApp is connected to an organization virtual datacenter network and is deployed there with the organization virtual datacenter network’s IP addressing. The Edge Gateway device then provides a routed connection between the organization virtual datacenter network and the external network. This scenario is shown in the following figure.

Figure 11. Direct Connection to a Routed External Organization Virtual Datacenter Network


And it looks like this in vCloud Director (Navigate to Administration -> Virtual Datacenters -> VCD1 -> Org VDC Networks):


So let's another routed network which will be our mgmt network (The IDR comes with two network interfaces, portal and mgmt). So click the green + and it will start the wizard. Choose the routed option:


I then added the following network details on the next page:


And after that you will have two networks:


I will use to be the portal/DMZ (defaulted-routed-network) network and as the mgmt/internal (routed-network-2) network.

DNAT for the Portal Interface

Since we want the portal to be reached external let's add a DNAT (or a port forward) from Public IP port 443 to the Internal portal IP port 443. So in vCloud Air navigate to Gateways -> GATEWAY ON VDC1 -> NAT Rules -> Add a NAT Rule and add the following DNAT:


On the next page if you are really organized you can also add a similar rule for 80:


Also don't forget to allow the firewall to access port 80 and 443 on the public IP and the internal network. I ended up created the following rules to allow that traffic:



Firewall and NAT Rules prior to Registration

As a sanity check here is a table of my NAT Rules:




Original IP

Original Port

Translated IP

Translated Port




The bottom one (DNAT from 8443 to MGMT_IP 443) is to allow access to the setup.jsp page and can be removed after registration. And the Firewall rules look like this:








The bottom ALLOW_INTERNAL_HTTPS_IN rule can be changed after registration to only allow 443 to the portal interface network ( and not any internal IP. And the Bottom rule can also be removed, since that allows for the port forward from 8443 to the MGMT_IP 443 , if setup.jsp access is no longer required.

Configure IPs on the IDR

First let's assign the vNics of the VM to the appropriate networks (management to default-routed-network and portal to routed-network-2). Click on the VM and then go to Networks:


Then click Add a Network and assign the NICs accordingly:


Then go back to the main VM screen and power on the IDR VM :


Then click on the VM and it will take you the properties page of the VM and you can click on Open Virtual Machine Console:



After applying the network settings I was able to access reach the 8443 port without problems:


Establishing the IPSec Tunnel To Local Environment

There is a pretty good KB on the process from VMware: Configuring IPsec VPN within VMware vCloud Air to a remote network and there is a pretty good diagram that represents all the networks:


My local networks is the mgmt network which is the network and my peer networks is the network which allow access to the AD in my internal network. So to start this configuration from vCloud Air go to  Gateways -> GATEWAY ON VDC1, then click on Manage in vCloud director:


Once in vCloud Director to Administration -> Virtual Datacenters -> VCD1 -> Edge Gateways and right click on the default GW to choose Edge Gateway Services:


Then go to the VPN tab and click Enable VPN and then Add:


After clicking Add, the wizard will start and you can configure your VPN settings. The settings depend on your environment, but here are the options broken down:






Local Network10.10.10.0/24This is the vCloud network (Mgmt Network) we want the remote site to have access to
Peer Networks10.210.0.0/16This is the network we want to access at the remote site
Local Endpoint107.189.120.76 (drop down)This is the Public IP of the Local End Point
Local ID107.189.120.76This can be anything, but it helps to set the IP to keep track of the configuration
Peer ID10.210.0.248This can be anything as well, but they recommend to either set it to the Public IP of the Remote End Point or the Private IP of the Remote End Point
Peer IPX.X.X.XThis is the Public IP of the Remote End Point
Encryption ProtocolAESYou can use AES 256, 3DES, or AES
Shared KeyLeft it as the generated oneWe will have to use that key on the remote VPN side to ensure we can authenticate with each end point to establish the VPN Tunnel
MTU1500Left the Default

Firewall Configuration in vCloud for VPN Connections

I ended up adding the following rules to ensure the VPN connection is established and to allow traffic from and to the internal networks across the VPN tunnel:








ALLOW_IP_SEC_ESP_AH_UDPX.X.X.X/32:Any107.189.120.76/32:AnyANYThis is so we can establish the IPSec Tunnel between the two endpoints
The following is necessary:
  • IP Protocol ID 50 (ESP)
  • IP Protocol ID 51 (AH)
  • UDP Port 500 (IKE)
  • UDP Port 4500

Since the only IP protocol allowed in the vCloud UI is ICMP, I decided to use Any to make sure I cover all of the above

ALLOW_VPN_TRAFFIC_L_TO_R10.210.0.0/16:Any10.10.10.0/24:AnyANYThis might be overkill but I am allowing anything from the Internal network to the vCloud MGMT network.
ALLOW_VPN_TRAFFIC_R_TO_L10.10.10.0/24:Any10.210.0.0/16:80ANYThis might be overkill but I am allowing anything from the vCloud MGMT network to the Remote Internal network. For my test, I could've just allowed 389 for the AD connection. But if you are planning to connect to internal webapps then 80 and 443 should be added here


After all the above is done, if you go back to vCloud Director you will see the VPN connection is good:

vcd-vpn-established (1).png

After all the above settings, we were able to connect to the AD server and login into the web portal issues.

Dropbox Setup

Looking over the documentation of dropbox it mentions that after setting Required mode for the SSO configuration, Rich Clients (like Desktop clients and Mobile Clients) should still work (What happens when I add a new user to the Business account?):

If you've turned on SSO in required mode, you'll need to make sure that the new user's email address is registered with your identity provider. Otherwise, the user will not be able to sign in and access Dropbox. In optional mode, the user will be asked to create a Dropbox password and can sign in with it as usual.

To make sure we are only using SSO and not the standard dropbox password let's make sure Dropbox is set for Required mode.

Confirm Required Mode is enabled

I logged into dropbox as the Administrator, navigated to Authentication, and confirmed that Required mode is enabled:


Initial Registration

After an administrator invites you to dropbox, you will receive an email:


Upon clicking on the link you can enter your email address and it will take you to the IdP:


And then you will be forwarded back to dropbox:


Desktop Client

Login to dropbox and click on YOUR_NAME -> Install:


And it will allow you to download the client:


Download it and start the installer:


After the installer was finished, the application launched, and I saw the following:


I just entered my email for the username, left the password blank, and clicked "Sign In". It figured out that I have SSO enabled and I saw the following:


Then upon clicking Get your link code a web browser opened up to the IdP:


We also had step-up enabled so I had to go through that:


After I was authenticated and authorized at the IdP side, it forwarded me to dropbox which showed me the link code:


I then copied that and pasted it back at the Dropbox Rich Client and it congratulated me on a successful setup:


Then I clicked "Open my Dropbox folder" and it showed me the contents:


So it worked out quite well. Once the link is established we won't be able to use step up again, so it's a one time setup and then dropbox doesn't have to re-login to the IdP. From the same page (What's the difference between optional mode and required mode?):

Users' existing desktop and mobile clients will remain linked to their accounts. This includes any desktop or mobile client that was connected to their account before they joined Dropbox for Business. All new desktop and mobile clients must use single sign-on.

Mobile Client

Now let's try the same thing on a mobile device. First let's install the app:


After it's installed, launch the app and you will see the initial page:


I then click on Sign In and on the sign-in page I only entered the email and no password:


At this point it forwarded me to a browser and I logged into my IdP:


After I logged in and showed me the step-up page:


After going through the step-up successfully, it forwarded me back to dropbox, and asked me if I wanted to complete the sign in:


After clicking Allow, the app was able to showed the dropbox content:


And I saw my files:


Same thing with this app, after you login and use step-up you won't do it again, unless you unlink the device.

Linked Device Emails

Throughout my testing, I kept receiving email of successfully linking devices:


and here is the android phone one:


Filter Blog

By date: By tag: