Skip navigation
All Places > Products > RSA SecurID Access > Blog > Author: Lenore Tumey

RSA SecurID Access

5 Posts authored by: Lenore Tumey Employee

The powerful policy engine in RSA SecurID Access can be used to control access to “My Page,” just like you can control access to other protected resources/applications.  This allows you to configure additional protections beyond simple password-based authentication.  You might consider incorporating some or all of the following elements into your policy:

  • If you have an Active Directory group for users with existing RSA SecurID Tokens (hardware, software, or ODA), you could configure a ruleset to require those users to perform additional authentication  to access My Page, by specifying an assurance level that includes RSA SecurID Tokens.
  • You could add a contextual rule to your ruleset that uses IP Address and/or (with Premium license) Trusted Networks, Trusted Locations, and so on.  For example, you might allow users who are logging in from your corporate network or  company office locations to access My Page with just a password, while users logging in from any other locations would need to perform additional authentication to meet a specified level of assurance.
  • If you have your users’ phone numbers in Active Directory, you might want to consider adding the SMS or Voice tokencode authentication methods (licensed separately) to an Assurance Level, so users who don’t have a SecurID Token could receive an SMS or Voice tokencode and use it to access My Page and/or other resources, as appropriate.

For example, here is how you might use some of these suggestions protect access to My Page:

 

First, configure your assurance levels. Note that “SecurID Token” is part of the medium assurance level. That will be important in the next step when you configure your policy.

Now create your “My Page” policy. In this case you will create a ruleset for the subset of users that belong to an Active Directory group named “SecurIDUsers”.

Then select the settings shown below. These settings will allow these users to use their SecurID tokens to securely access My Page, where they may then enroll the RSA SecurID Authenticate application.

New users that do not have a SecurID token also need secure access to My Page. You could allow access to My Page with just a password for new users who are in a trusted location such as your corporate office, or who are logged into a trusted network, such as on your corporate network. You could also allow new users who are not in a trusted location and not in a trusted network to authenticate with SMS or Voice tokencode since they do not have a SecurID token.

 

To accomplish this, create an additional rule set that includes a conditional rule that allows password access to users in a trusted location or using a trusted network and that requires additional authentication for those users who do not meet one of those conditions. In this case you’ll assign a low assurance level to the rule to allow these users to authenticate with SMS or Voice tokencode.

 

When you’ve finished creating your new policy, go to Platform > My Page, select the policy you created, click Save, and then Publish changes before testing to ensure your configuration achieves your goals.

If you’ll be connecting to your Identity Source securely, using LDAPS, you’ll need the SSL certificate from your LDAP directory server when configuring the connection in the Cloud Administration Console. Not sure how to get it? We’ve seen our customers use a few different ways to get this certificate. Here are just a couple:

 

  1. Ask your directory server administrator for the certificate chain. Really, it can be that easy. When you add your connection to the LDAP directory (following the steps in your Quick Setup Guide), upload this file in the SSL Certificates section.
  2. Can’t ask your directory server admin or don’t want to? OpenSSL can be an easy way to do it. Here’s how:
    1. After you add your identity router (following the steps in your Quick Setup Guide), access SSH on your identity router using these instructions: https://community.rsa.com/docs/DOC-75833 
    2. From the identity router command line, query the directory server to obtain the certificate chain using the following command:

       

      openssl s_client -showcerts -connect LDAP.SERVER:636

       

      where LDAP.SERVER is the LDAP directory server that has the full certificate chain loaded on it. (You might have to ask your directory server admin to know which directory server to query.)

    3. From the output, copy the sections starting from and including the BEGIN CERTIFICATE line to (and including) the last END CERTIFICATE line. Paste these lines into a local file on your desktop and call it something like ldaps.pem.
    4. When you add your Identity Source connection to the LDAP directory (again following the steps in your Quick Setup Guide), upload this file in the SSL Certificates section.

Do you have other easy ways to get your LDAPS certificate?  If so, please share your tips and tricks in the comments!

We sometimes get questions regarding the scalability of the RSA SecurID Access Cloud Authentication Service.  Customers who are used to managing on-premises solutions want to know how many machines they need to set up to support their end user population during peak periods. But since the Cloud Authentication Service is a hybrid solution, the scaling considerations are a bit different.  

If you use the Cloud Authentication Service to provide primary and/or additional authentication to relying parties, scalability is simple because the cloud components are designed to scale to meet your needs.  The hybrid architecture still involves an on-premises identity router, which provides a secure connection to your identity source(s), but its role is minimal at runtime. Just make sure you deploy more than one identity router for redundancy, in case one goes down.

If you use the identity router for RADIUS-based access control, all you need to do is make sure you have redundant identity routers with RADIUS enabled. The Cloud Authentication Service handles the heavy lifting.

If you want information about scalability and you use the SSO Agent capabilities, you can read more about that in the RSA SecurID Access SSO Agent Performance and Scalability Guide.

 

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="http://www.w3.org/2000/09/xmldsig#" entityID="https://saml.exampleapp.com" 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

E3NhbWwuZXhhbXBsZWFwcC5jb20wHhcNMTUxMjE5MDAzOTI3WhcNMTkxMjE5MDAz

OTI3WjAeMRwwGgYDVQQDExNzYW1sLmV4YW1wbGVhcHAuY29tMIIBIjANBgkqhkiG

9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvOJHL/8SbjV3WZ/wj2l/ra+a6Emmo0hQUo4U

Tgdj+IeSOng8dklK9p3TtfCzx9i4mqw20yal4PMYwp9F0SH1FujQ6p9e662hNMS5

AokWfMg0p4gj8LkRFHETxJzgNevEmRoUUy1HnLsocAv2ORQbzRws2m6AqRJESiIF

SW57vOl5bYzGQ2jRMm2+1UgBxCyTLRcUyF859CpEoQiX6mWnw7fOgFoY27NrXmQg

if++ms/GOIAj2O3hW+gX0ZAgBWKLJdbsLvf5gXe+aELj5XTXe28eseDqiOsGqbA8

JMclyOyhT4uNR2TkLmz4I5CG505DIzZzzCQH72OcjlX9SZv+ewIDAQABMA0GCSqG

SIb3DQEBCwUAA4IBAQConpu5liGIPB2hBSRWxJCDtAzD2dXsaAXaAQZP4qJF2JWA

BSLMMkP6E+HTgUmv0DF1AYwk5KTwhJVk3QH/g6yXSdzO9S9U5b7mrvt5lK0tkdSa

neEqHjTF9kOuVreQtX7vSFZ/yfRYVa99YuGJU5n3lvp8detfGyYa+MaRVA2+UaHJ

sLof1KoTr43mm9SXvwhLWN81b4njF1IrbhctGHvqhB2n3Nx6UiMSmlcxzStPq+zb

3cw3iqnRMr6jlPXspWK1gjqbNJfMvPxSbZpotc46ur3wCDLEwLrQpsj2bu8G64n7

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="https://login.exampleapp.com?so=00D1a000000JmBn" 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 ‘@gmail.com’ 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.

Filter Blog

By date: By tag: