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

Earlier this year we introduced RSA SecurID Access, The enterprise grade IDaaS solution that delivers secure access to cloud and mobile applications without creating roadblocks for users. However, like our customers’ needs, our product will continue to evolve rapidly. This quarter we have released a range of new updates for our enterprise customers and I’d like to highlight a few them.

 

Improvements for end users

The end user experience is the heart of the simple and secure capabilities of RSA Via Access. In this release, we’ve made the mobile application easier for users to provide step-up authentication by enabling users on iOS devices to take approve or deny actions right from the notification, without opening the app. In addition, users can approve or deny access from their Apple Watch.

 

For Samsung device users, we’ve partnered with Samsung to enable the Samsung fingerprint sensor to work with RSA Via Access fingerprint authentication. Administrators don’t need to worry about whether users have Samsung or Apple devices. Simple setup for fingerprint authentication will enable both brands of devices to work seamlessly. For those users without a device that supports fingerprints, the flexibility of the RSA Via Access policy engine will make sure they have a secure and convent method of assurance available as well.

 

As RSA Via Access gains traction around the world, we recognize that we have to continue to enhance our global capabilities. As a result, we have extended localization of our end user components to 6 new languages (German, Spanish, French, Japanese, Portuguese, and Simplified Chinese).

 

Improvements for Administrators

RSA Via Access strives to have a powerful yet simple to use administrator interface. We know that companies need lots of capabilities and flexibility in their IAM solutions. However, if they’re too difficult to understand and administer, you end up with great features that no one can use. IT Administrators are busy people so we try to keep administration time needed for RSA Via Access to a minimum. Sometimes it’s simple things. In this release we’ve added efficiency improvements in many places of the product. For example, administrators can now copy an existing complex policy so they can quickly build new policies off an existing one. Also, to make connecting to applications simpler, we’ve introduced SAML metadata import and export support to reduce application setup errors and make connecting to applications faster.

 

Extend Functionality

While over 90% of enterprises use Microsoft Active Directory, many of those companies have AD plus other identity sources. Because of this we now have support for LDAPv3 directories. Companies can use AD, LDAP or combinations of both as their system(s) of record for identities.

 

This is a sample of what’s new with RSA Via Access. Much of this new functionality was included in our Fall Release. The release notes for that release can be found HERE. Stay tuned as we have a lot more to release in the coming months. 2016 will be an exciting year for us at RSA and, specifically, for RSA Via Access.

I wanted to try out the Salesforce Mobile App with SAML enabled and here is what I discovered.

Enable SP-Initiated Mode in Salesforce

Reading over Single Sign-On for Desktop and Mobile Applications using SAML and OAuth, I saw the following:

 

The Force.com 'My Domain' feature allows you to select a custom domain name for your application. A 'My Domain' URL looks like https://customer.my.salesforce.com/ (for a production org) or https://customer-developer-edition.my.salesforce.com/ (for a Developer Edition). A benefit of configuring 'My Domain' is that it enables support for SP-initiated single sign-on, improving the user experience, and allowing users to access 'deep links' into their environment via SSO.

You may configure 'My Domain' in Setup | Company Profile | My Domain. As users may be un-authenticated when they arrive at Force.com, a unique domain is the mechanism by which a specific organization's SAML configuration can be discovered. In order to take advantage of SAML for desktop and mobile apps you must deploy My Domain. In addition, this will greatly improve the user-experience for web browser based single sign-on. This is considered a best practice if you deploy SAML with Force.com.

 

 

So we need to enable "My Domain" and then configure SAML to be SP-Initiated.

Configure My Domain in Salesforce

After you login as the administrator to Salesforce navigate to Administer -> Domain Management -> My Domain and pick a name for your Domain to make sure it's available:

sf-check-dom-avail.png

After click Register Domain and it will take some time to enable all the DNS settings and you will see the following:

sf-domain-pending.png

After the registration is complete you will receive an email similar to this:

sf-domain-reg.png

After that if you go back to the domain settings you will see that the domain is ready for use:

sf-domain-ready-for-testing.png

Configure an SP-Initiated SAML Setup

Now login to your access console and configure a SAML application and get all the necessary information:

  1. Issuer (Issuer Entity ID)
  2. Entity Id ( Audience (Service Provider Entity ID) )
  3. Identity Provider Certificate (cert.pem from the Certificate Bundle)
  4. Identity Provider Login URL (Identity Provider URL)

Then from Salesforce as an administrator go to Administer -> Security Controls -> Single Sign-On Settings and add a new SAML config. Here is one I ended up with:

sf-saml-config-sp.png

Make sure you enter an Identity Provider Login URL or the configuration won't be seen as SP-Initiated.

Modify Authentication Configuration for the Custom Domain

The last thing we need to do is enable the SAML configuration to be used as an Authentication service. So again from the salesforce portal go to Administer -> Domain Management -> My Domain -> Authentication Configuration -> Edit, and enable your SAML configuration:

sf-ac-saml-enabled.png

You can have both enabled (the Login page and the SAML configuration). With both enabled people can see the login page and choose to either use the SAML configuration or to use their passwords. If you just leave the SAML configuration, then it auto start the login process and forward you to the IdP as soon as you visit the login page for your custom domain.

Salesforce Mobile Client Testing

At this point, I installed the Salesforce1 Application on my Android phone:

sf-mob-app.png

After installing it, I launched the application and I saw the login page:

sf-mob-login-page.png

From here click on the option menu and choose change server:

sf-mob-ch-ser.png

Then click Add Connection and enter the custom domain that you created in salesforce:

sf-mob-app-new-conn.png

and then choose that connection and click Apply:

sf-mob-con-added.png

Then it will take you to the login page and you will see a button to use the IDP for the login:

sf-mobile-app-saml-idp-seen.png

Upon clicking that it took me to the IDP and I was able to enter my AD credentials:

sf-in-idp-login.png

After you get authenticated it will confirm that you want to provide the necessary access to this application:

sf-confirm-mob-app.png

And then you will gain access to the application:

sf-mob-app-win1.png

And here are the options for my chatter user:

sf-mob-app-win2.png

Just-In-Time Provisioning

There is actually a pretty good description from the Salesforce About Just-in-Time Provisioning for SAML

With Just-in-Time provisioning, you can use a SAML assertion to create regular and portal users on the fly the first time they try to log in. This eliminates the need to create user accounts in advance. For example, if you recently added an employee to your organization, you don't need to manually create the user in Salesforce. When they log in with single sign-on, their account is automatically created for them, eliminating the time and effort with on-boarding the account. Just-in-Time provisioning works with your SAML identity provider to pass the correct user information to Salesforce in a SAML 2.0 assertion. You can both create and modify accounts this way. Because Just-in-Time provisioning uses SAML to communicate, your organization must have SAML-based single sign-on enabled.

It's a pretty awesome feature so let's see how to utilize it with RSA SecurID Access.

Just-In-Time Attributes For Salesforce

Looking over the Salesforce Just-in-Time Provisioning Requirements it looks like we case use the following SAML Attributes in the Assertion for Just-In-Time Provisioning:

 

Field

 

Required

Comments

AboutMe
AliasIf not present, a default is derived from FirstName and LastName.
CallCenter
City
CommunityNicknameIf not present, a default is derived from the UserName.
CompanyName
Country
DefaultCurrencyIsoCodeDerived from organization settings.
DelegatedApproverId
Department
Division
EmailYFor example,User.Email=test2@salesforce.com
EmailEncodingKeyIf not present, a default is derived from the organization settings.
EmployeeNumber
Extension
Fax
FederationIdentifier (insert only)If present, it must match the SAML subject, or the SAML subject is taken instead. Can't be updated with SAML.
FirstName
ForecastEnabled
IsActive
LastNameY
LanguageLocaleKey
LocaleSidKeyIf not present, a default is derived from the organization settings.
Manager
MobilePhone
Phone
ProfileIdYFor example,User.ProfileId=Standard User
ReceivesAdminInfoEmails
ReceivesInfoEmails
State
Street
TimeZoneSidKeyIf not present, a default is derived from the organization settings.
Title
Username (insert only)YFor example,User.Username=test2@test.com. Can't update using SAML.
UserRoleIdDefaults to “no role” if blank.
Zip

From the same page it looks like we need to prepend each SAML attribute with User.:

 

To correctly identify which object to create in Salesforce, you must use the User. prefix for all fields passed in the SAML assertion. In this example, the User. prefix has been added to the Username field name.
<saml:Attribute

   Name="User.Username"

   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

      <saml:AttributeValue xsi:type="xs:anyType">testuser@123.org</saml:AttributeValue>

</saml:Attribute>

 

 

 

Enable JIT for the SAML Salesforce Configuration

Login as a Salesforce Administration and navigate to Administer -> Security Controls -> Single SignOn Settings and you will see your SAML configurations:

sf-saml-configs.png

Then click Edit on your desired configuration and ensure the User Provisioning Enabled checkbox is checked and the standard option is used:

sf-saml-jit-enabled.png

Also make sure you select Assertion contains the Federation ID from the User object:

sf-saml-config-fed-id.png

Configure Extended Attributes for the Salesforce Connector in Via Admin Console

The basic configuration for salesforce is found at RSA Via Access Salesforce SAML Implementation Guide. After you have that configured let's modify the Extended Attributes section to have the following Attributes (the first two will already be there, I am just including them for completion):

 

Attribute Source

 

Attribute Name

User Store

Property

ConstantlogoutURLN/Ahttps://portal.PDN.com
ConstantssoStartPageN/A

https://portal.PDN/IdPServlet?idp_id=APP_ID

UserStoreUser.EmailADmail
UserStoreUser.LastNameADsn
ConstantUser.ProfileIdN/A

Chatter Free User
NOTE: If you have an attribute within AD that contains this information, then you can use that

UserStoreUser.UserNameAD

Here is how it looks like:

sf-ac-ex-at-sf-con.png

Just-In-Time Provisioning Testing

I created a new user in AD:

sf-new-user-added.png

I also double checked and no such user existed in Salesforce, you can confirm by going to Administer -> Manage Users -> Users:

sf-users.png

Then I logged into the portal as the velma user and clicked on the Salesforce Application and I logged in successfully:

velma-logged-in.png

If you look at the SAML assertion that RSA Via Access sent, it will look similar to this:

 

<saml2:AttributeStatement>

    <saml2:Attribute Name="User.Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

        <saml2:AttributeValue xsi:type="xs:string">velma@demorsa.com</saml2:AttributeValue>

    </saml2:Attribute>

    <saml2:Attribute Name="User.UserName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

        <saml2:AttributeValue xsi:type="xs:string">velma@demorsa.com</saml2:AttributeValue>

    </saml2:Attribute>

    <saml2:Attribute Name="logoutURL" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

        <saml2:AttributeValue xsi:type="xs:string">https://portal.singlepoint66.com/</saml2:AttributeValue>

    </saml2:Attribute>

    <saml2:Attribute Name="User.LastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

        <saml2:AttributeValue xsi:type="xs:string">Tech</saml2:AttributeValue>

    </saml2:Attribute>

    <saml2:Attribute Name="ssoStartPage" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

        <saml2:AttributeValue xsi:type="xs:string">https://portal.singlepoint66.com/IdPServlet?idp_id=sp66sales</saml2:AttributeValue>

    </saml2:Attribute>

    <saml2:Attribute Name="User.ProfileId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

        <saml2:AttributeValue xsi:type="xs:string">Chatter Free User</saml2:AttributeValue>

    </saml2:Attribute>

</saml2:AttributeStatement>

Confirming Just-In-Time Provisioning

I then logged in to salesforce as the administrator and saw the user created:

sf-velma-created.png

Also if you check out the Audit Logs (Under Administer -> Security Controls -> View Setup Audit Trail), you will see something like this:

sf-audit-log.png

Filter Blog

By date: By tag: