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

Whenever working with HTTP-Federation (H-Fed) applications, Key Chains always come into play. For every H-Fed application a user has a corresponding Key Chain with the credentials for that application. There are rare times when populating the Key Chains automatically is helpful/necessary, although this is not the only use case for the Key Chain CLI. Here are some other use cases that come to mind for the Key Chain CLI:


  • Populating Users' Keychains for H-Fed Applications automatically
  • Creating a "Snapshot" of Users' Keychains (This is not a backup, passwords are not exported)
  • Migrate Users' Key Chains (If the user's Username has changed for some reason)
  • Creating Usage Reports (Listing and counting configured H-Fed applications and Key Chains)


So let's try out the Key Chain CLI on a Windows Machine and a Linux Machine.

Key Chain CLI Prerequisites

There are a couple of prerequisites that are worth mentioning in order to successfully use the Key Chain CLI. Here is a small, and may not be comprehensive, list:


  • The CLI needs to run against the IDR's management interface, not the portal interface
    • This means the machine that is running the CLI needs to have access to the Management Interface of the IDR
  • The CLI uses HTTPS to connect to the IDR
  • The CLI requires Java version 1.7 or higher

Get the SDK Files

The Key Chain CLI is part of the SDK zip archive, you can download the SDK zip from RSA Via Access - Application Portal Integration API. After downloading the zip file, extract the contents to an easily accessible directory. I will refer to this as the SWS_SDK_HOME Directory.

Windows - Configure Environment Variables

In my testing I had Java 1.8:


C:\>java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) Client VM (build 25.66-b18, mixed mode, sharing)


To ease the sourcing of the Environment variables I like to create a script. On my windows machine here is the script:


C:\>type c:\SWSSDK\key_cli.bat
@echo off
set JAVA_HOME=C:\Program Files (x86)\Java\jre1.8.0_66
::The SWS_SERVER is the management IP Address of the IDR

Now we can just run the following to set and confirm all the environment variables:


C:\>set SWS

Lastly we can make sure the idr.cmd command is in your path (any commands are appended with .cmd by default so you don't have to type out the full command):


C:\>idr.cmd --version

Linux - Configure Environment Variables

In my below example I will put the SWS_SDK_HOME directory under /tmp, but I would recommend installing it into a directory dedicated for software installs (ie, /usr/local or /opt). So let's create a dedicated folder for our testing:


me@admin:~>cd /tmp
me@admin:/tmp>mkdir SWSSDK
me@admin:/tmp>mv ~/ SWSSDK/.
me@admin:/tmp>cd SWSSDK
me@admin:/tmp/SWSSDK> unzip

Now let's create a file to ease the setup of the environment variables let's call it  /tmp/SWSSDK/ Here are the contents of the script:


export JAVA_HOME=/opt/jre
export SWS_KEYFILE=/tmp/SWSSDK/key.txt
export SWS_SERVER=  #This should be the management IP Address for the IDR
export PATH=/tmp/SWSSDK/bin:$PATH

After that's ready, you can source your script and your variables will be configured. Here is what you can run to source the setup script:


Note: that there is a space between the "." and ""

After it's finished you can confirm that the environment variables are configured:


me@admin:~> env | grep -E "JAVA|SWS"

Create a Dedicated API user for the Key Chain CLI

Login into the RSA Via Access Console as a Customer Super Administrator and create another user with API functionality enabled (My Account > Administrators > Add an Administrator):



The Allowed Networks specifies the remote network that will be making the remote CLI calls (in my above example I allow the internal network Don't forget to publish after creating the user (this will push the settings onto the IDR). Next we need to create the key.txt file and populate it with the Access ID and Access Key Values. We can run the following to create the key file:


# for Windows
C:\> echo key=0da0fe339b202fb96b7f5317153f402c78a561bc/fabe1b20d2d47813d4131fe98c2a8b1ef064221f > c:\SWSSDK\key.txt
# for Linux
me@admin:~> echo "key=0da0fe339b202fb96b7f5317153f402c78a561bc/fabe1b20d2d47813d4131fe98c2a8b1ef064221f" > /tmp/SWSSDK/key.txt

The format of the file is the following:


#AccessID and AccessKey values can be found from RSA Via Access Console > My Account > Administrators > "Your_Designated_API_USER" -> Edit

Test KeyChain CLI Commands

As a quick test make sure the following commands work:

Username    Application Name   Credentials
karim       Evernote           username, password
karim       Sharepoint 2013    username, password
karim       Concur             userid, password
dave        Evernote           username, password
dave        Sharepoint 2013    username, password
dave        Concur             userid, password
dpeterson   <none>             <none>
nancy       Sharepoint 2013    username, password
nancy       Concur             userid, password
nancy       Twitter            username, password
jason       Evernote           username, password
jason       Sharepoint 2013    username, password
jason       Concur             userid, password


On Linux you can run the same:


me@admin:~> idr-describe-keychains
Username        Application Name   Credentials
Administrator   <none>             <none>
devuser         <none>             <none>


The above just shows the current Key Chains that are configured.

Import Key Chain Data Using a CSV File

If we need to batch import a bunch of H-Fed Credentials we can create a CSV file in the following format:

Username,Application Name,CredentialName1,CredentialValue1,CredentialName2,CredentialValue2

To figure out the Application Name and Credential Names we can use the idr-describe-applications command. For example here is output from that command:


Application Name   Portal URL                        Portal Text     Enable Keychain Edit   Credentials
Concur      Concur            true                 userid,  password
Evernote   Evernote          true                 username,  password
Sharepoint 2013     Sharepoint 2013   true                 username,  password
Twitter               Twitter           true                 username,  password

So let's say I wanted to populate the Key Chain credentials for some users for the Sharepoint 2013 Application. I would then create a CSV file with the following contents:


me@admin:~> cat users.csv
Username,Application Name,CredentialName1,CredentialValue1,CredentialName2,CredentialValue2
user1,Sharepoint 2013,username,,password,password1
user2,Sharepoint 2013,username,,password,password2
user3,Sharepoint 2013,username,,password,password3
user4,Sharepoint 2013,username,,password,password4
user5,Sharepoint 2013,username,,password,password5
user6,Sharepoint 2013,username,,password,password6
user7,Sharepoint 2013,username,,password,password7
user8,Sharepoint 2013,username,,password,password8

Then you can use the idr-update-keychains command to import that CSV file:


me@admin:~>idr-update-keychains -f users.csv
A total of 8 keychains were updated.
C:\>idr-update-keychains -f c:\SWSSDK\users.csv
A total of 8 keychains were updated.

And you can confirm the Key Chain Data with the idr-describe-keychains command just like we did above.

Export User Key Chains as CSV

Another cool side note is that you can also export Key Chain Data as CSV but the password will not be available (they will be left blank):


C:\>idr-describe-keychains -f csv
Username,Application Name,CredentialName1,CredentialValue1,CredentialName2,CredentialValue2
user1,Sharepoint 2013,username,,password,********
user2,Sharepoint 2013,username,,password,********
user3,Sharepoint 2013,username,,password,********
user4,Sharepoint 2013,username,,password,********
user5,Sharepoint 2013,username,,password,********
user6,Sharepoint 2013,username,,password,********
user7,Sharepoint 2013,username,,password,********
user8,Sharepoint 2013,username,,password,********


A full list of all the keychain CLI commands will be available soon and I will definitely link to it as soon as it's available.

Exchanging SAML metadata is an easy way to make sure that the Service Provider and Identity Provider have compatible configurations.  If your IdP doesn’t support the use of metadata, though, admins are left to manually configure everything, and that introduces human error.  Imagine if you were to receive metadata like this from a Service Provider, and had to figure out what that meant in terms of a corresponding IdP configuration?:


<?xml version="1.0" encoding="UTF-8"?><md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="" entityID="" validUntil="2025-07-22T01:50:13.184Z"><md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><md:KeyDescriptor use="signing"><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIICujCCAaKgAwIBAgIGAVG3rVFIMA0GCSqGSIb3DQEBCwUAMB4xHDAaBgNVBAMT














erAbsPSqkUHpn1yd+NAlUs/2qr5LoNg9Hit12Nvk</ds:X509Certificate></ds:X509Data></ds:KeyInfo></md:KeyDescriptor><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="" index="0" isDefault="true"/></md:SPSSODescriptor></md:EntityDescriptor>



Sure, it’s possible to do — maybe run it through an XML formatter to make it a little easier to read, then copy and paste the certificate into a file that you can upload, figure out exactly what each field really means, copy and paste those values to the right places in your config, check the right checkboxes, etc. etc. 



...Or you could just use an Identity Provider that supports importing SAML metadata, in the first place.



In RSA Via Access, for example, you can import SAML metadata into any SAML application configuration, whether you’re setting up an application from the catalog, or using the SAML template.  Just click the Import Metadata button on the Connection Profile page, specify the metadata file you want to use, and check out all the settings that will be applied, before saving:


After you've imported the SP metadata, you can still review the overall configuration and make any special adjustments you might need (like selecting which of your AD attributes you want to use for the NameID), before saving the application and publishing your changes.

We spend a lot of time talking about Active Directory, but a lot of companies have a variety of identity repositories.  For example, employees might be managed in AD, while partner identities might be in an OpenDJ LDAP directory.  What if both groups of users need to log into the same instance of a SAML application, but that SAML application can only federate with a single Identity Provider?



Fortunately, RSA Via Access can act as that Identity Provider.  By connecting to both identity sources, we can provide SAML access for users in both repositories.  To set this up, the admin first needs to configure the Identity Routers to connect to the Active Directory and the LDAP servers by configuring both in the Identity Sources (a.k.a. User Stores).  For the sake of this example, we’ll call these Identity Sources, “Corp AD” and “Partner LDAP,” respectively.  Each user who will be accessing this system will just need to have a unique ‘mail’ attribute configured.



Once the Identity Sources are set up, the admin can then configure the SAML application.  When specifying the User Identity details such as the NameID and any extended attributes, use the Attribute Hunting option to enable the ability to search across multiple Identity Sources.  For example, if the SAML app needs the NameID to be the email address, you could pull it from Corp AD ‘mail’ and also look at Partner LDAP ‘mail’.  If the application also requires an extended attribute called FirstName, with Attribute Hunting enabled, you can click the pencil icon to manage the configuration and pull the attribute from the Corp AD ‘givenName’ attribute, or the Partner LDAP ‘userFirstName’ attribute (assuming that’s the name of the attribute holding the user’s first name).



Similarly, when configuring the access policy, the admin can check both the Corp AD and Partner LDAP sources in step 2, and then be able to construct Access Rules using attributes from both identity sources.  For example, you could craft a ruleset for users whose ‘mail’ attributes contain ‘’ to deny access, and another ruleset for employees who are a memberOf the CN=IT-Admins,OU=Groups,DC=example,DC=com group to require step-up authentication when they’re coming from outside the corporate network.  In the rule editor, the admin doesn’t select a specific identity source from which to pull the attribute, so if both sources have the same attribute names, the rule will automatically handle users logging in from either directory.

Integrated Windows Authentication

A lot of the times we configure IWA to allow seamless login into the RSA SecurID Access Web Portal. Instructions on how to install and configure IWA are located in Install the Integrated Windows Authentication Connector and the installer itself is located at RSA Via Access IWA Connector Installer. IWA uses kerberos capabilities (SPNEGO) for authentication, therefore browser configuration is necessary to trust the IWA server and ease the login process.


Internet Explorer

If you are on a windows machine the first you can do is confirm that kerberos tickets have been assigned to the logged in user. This can be done by using the klist command:



Current LogonId is 0:0x31ae6
Cached Tickets: (2)

#0>     Client: devuser @ ELATOV.NET
        Server: krbtgt/ELATOV.NET @ ELATOV.NET
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 9/24/2015 12:58:21 (local)
        End Time:   9/24/2015 22:58:21 (local)
        Renew Time: 10/1/2015 12:58:21 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96

#1>     Client: devuser @ ELATOV.NET
        Server: LDAP/ @ ELATOV.NET
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
        Start Time: 9/24/2015 12:58:51 (local)
        End Time:   9/24/2015 22:58:21 (local)
        Renew Time: 10/1/2015 12:58:21 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96


We can see that we have a valid kerberos ticket for the domain. As long as my IWA Server's hostname is within that domain (ie. then we can proceed configuring the browser to trust the domain. If look under the Internet Explorer Settings (Tools -> Internet Options -> Security -> Local Intranet -> Custom Level), you will notice that automatic login is allowed for sites that are in the Intranet Zone by default:


Now all that we have to do is add our domain into the Local Intranet Zone in Internet Explorer and we will be all set. This is accomplished by going to Tools -> Internet Options -> Security -> Local intranet -> Sites -> Advanced and add the following for the site: https://* :



After that if you visit your portal and you if have configured it as per the instructions laid out in Enable Automatic Integrated Windows Authentication you will be automatically logged in the portal with Internet Explorer.




A similar mechanism exists for Firefox. From Mozilla's Integrated Authentication page:


Mozilla currently supports a whitelist of sites that are permitted to engage in SPNEGO authentication with the browser. This list is intended to be configured by an IT department prior to distributing Mozilla to end-users.

The preferences are:

pref("network.negotiate-auth.trusted-uris", site-list); 
pref("network.negotiate-auth.delegation-uris", site-list);
pref("network.automatic-ntlm-auth.trusted-uris", site-list);

where, site-list is a comma-separated list of URL prefixes or domains of the form:

site-list = ","

network.negotiate-auth.trusted-uris lists the sites that are permitted to engage in SPNEGO authentication with the browser, and
network.negotiate-auth.delegation-uris lists the sites for which the browser may delegate user authorization to the server.
network.automatic-ntlm-auth.trusted-uris lists the trusted sites to use NTLM authentification.

To modify these settings we start firefox in the address we can enter about:config and modify just the top two options to include our domain (




Chrome for windows is actually pretty easy, from Chromium's HTTP authentication page:


In Windows only, if the AuthServerWhitelist setting is not specified, the permitted list consists of those servers in the Local Machine or Local Intranet security zone (for example, when the host in the URL includes a "." character it is outside the Local Intranet security zone), which is the behavior present in IE. Treating servers that bypass proxies as being in the intranet zone is not currently supported.

So if we configure the Local Intranet Security Zone appropriately in Internet Explorer then Chrome will use those settings as well.


Mac OS X

As long as the Mac OS X system is joined to the domain (I will talk more about that below) and has a valid kerberos ticket then you can launch chrome with the following command:


$ open -a 'Google Chrome' --args --auth-server-whitelist="*" --auth-negotiate-delegate-whitelist="*"


Or you can set the following setting permanently:


$ defaults write AuthServerWhitelist "*"
$ defaults write AuthNegotiateDelegateWhitelist "*"



As long as the Linux Machine is able to get a kerberos ticket (I will talk more about that later), then you can launch from with the following parameters:


$ google-chrome-stable --auth-server-whitelist="*" --auth-negotiate-delegate-whitelist="*"


If you want to make it permanent, create a file with the following settings:


$ cat /etc/opt/chrome/policies/managed/policies.json
    "AuthServerWhitelist": "*",
    "AuthNegotiateDelegateWhitelist": "*"


And then just launch Google Chrome as you would normally do. You can also confirm the policy settings by going to chrome://policy in the address bar of the Chrome Browser:



Safari and Mac OS X


Safari by default supports IWA, from Best Practices for Integrating OS X with Active Directory :


Apple and Microsoft both support Kerberos to provide a secure single sign-on environment. When integrated into an Active Directory environment, OS X uses Kerberos exclusively for all authentication activities. The use of Microsoft’s NT LAN Manager (NTLM) suite of protocols, including both NTLMv1 and NTLMv2, can be prohibited on the network as needed, without effecting Mac computers or services provided by OS X Server within the Active Directory environment.

When a user logs in to a Mac using an Active Directory account, the Active Directory domain controller automatically issues a Kerberos Ticket Granting Ticket (TGT). When the user attempts to use any service on the domain that supports Kerberos authentication, the TGT generates a ticket for that service without requiring the user to authenticate again.

You can use the Kerberos administration tools on a Mac to view currently issued tickets both from the command line, where klist displays the current

tickets, or by using the graphical Ticket Viewer utility located at /System/Library/CoreServices/Ticket


As long as klist shows something similar to this, Safari will work by default:


Ticket cache: KCM:01C347AC-5C1C-46E4-B9BC-6260049FCB2B
Default principal:

Valid starting                 Expires                        Service principal
09/24/2015 12:27:37  09/24/2015 22:27:37  krbtgt/ELATOV.NET@ELATOV.NET
09/24/2015 12:29:37  09/24/2015 22:27:37  HTTP/


Authenticating with Kerberos with Linux


I was testing this out with an Ubuntu Machine and it worked out for me. In order to get a kerberos ticket you first have to install the kerberos tools:


$ sudo apt-get install krb5-user


Then we need to create the Realm/Domain information, I ended up creating this simple file (Capitalization is important):


$ cat /etc/krb5.conf
  default_realm =
  krb4_config = /etc/krb.conf
  krb4_realms = /etc/krb.realms
  kdc_timesync = 1
  ccache_type = 4
  forwardable = true
  proxiable = true

  kdc =
  admin_server =
[domain_realm] = ELATOV.NET = ELATOV.NET

  krb4_convert = true
  krb4_get_tickets = false


Then authenticate your self to get a ticket:


$ kinit devuser@ELATOV.NET
Password for devuser@ELATOV.NET: 


If that's successful, you will see your ticket:


$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: devuser@ELATOV.NET

Valid starting       Expires              Service principal
09/24/2015 16:03:58  09/25/2015 02:03:58  krbtgt/ELATOV.NET@ELATOV.NET
  renew until 09/25/2015 16:03:53


Then after configuring Firefox (or Google Chrome) as per the above instructions, I visited the portal and was automatically logged in. Checking the kerberos tickets I saw a new one:


$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: devuser@ELATOV.NET

Valid starting       Expires              Service principal
09/24/2015 16:03:58  09/25/2015 02:03:58  krbtgt/ELATOV.NET@ELATOV.NET
  renew until 09/25/2015 16:03:53
09/24/2015 16:08:43  09/25/2015 02:03:58  HTTP/
  renew until 09/25/2015 16:03:53


That should be it!

Filter Blog

By date: By tag: