Skip navigation
All Places > Products > RSA SecurID Access > Blog > Author: Jason Oeltjen

RSA SecurID Access

5 Posts authored by: Jason Oeltjen Employee

SecurID Access offers convenient options for authentication like push, biometrics, etc. Many of these are smart phone centric so, depending on how your system is deployed, your users may be required to have their mobile phone to authenticate. Occasionally, a user will forget their phone so we need to have a way to handle these emergency access scenarios. Here are the options in SecurID Access.

 

1. Do you have an Authentication Manager server attached to the SecurID cloud service? If so, make sure it is upgraded to release 8.2 SP1. As long as you are on that release or greater, your users using the SecurID Authenticate App can get emergency access just like your SecurID token users. Helpdesk admin can give the user a tokencode with a specific time limit (24 hours, for example) to get them through until they get back to their phone. Full details on this is available here Provide an Offline Emergency Access Tokencode.

 

2. If you don't have the Authentication Manager server connected to the cloud service, policies can be used for these users. Policy exceptions can be made to allow a specific user access with password only. The key here is to make sure that you have a process in place to revisit the policy the next day to reset it to normal after the emergency access period.

At RSA we just unveiled our RSA SecurID Suite of Identity offerings. The access and authentication offerings from RSA are now known as RSA SecurID Access.  RSA is doubling down on Identity and by bringing the market-leading RSA SecurID and Via Access solutions together, we intend to support customers and provide secure and convenient access for any user, from anywhere, to anything.

 

We want to make sure we are clear with what this means for our Via Access customers. While the RSA Via Access name is going away, the product RSA via Access customers have is very much alive and a core part of the present and future of SecurID Access.

 

SecurID Access is being offered in 3 editions; Base, Enterprise, and Premium.

1. RSA SecurID Access Base Edition incorporates the RSA Authentication Manager Base License feature set.  Base Edition can be easily upgraded to the Enterprise and Premium Editions.

 

2. RSA SecurID Access Enterprise Edition incorporates the RSA Authentication Manager Enterprise License feature set and, in some cases, bundles in Single Sign-On, or SSO, agents.  This allows you to extend traditional RSA SecurID authentication to protect cloud, mobile and web applications at no additional cost. SSO integration methods & options include: SAML 2.0 which support Browser POST, IdP-Initiated or SP-Initiated options, Trusted Headers with Reverse Proxy support and HTTP-Federation which includes Reverse Proxy, Login-form POST and user keychains (for password vaulting).

   

     RSA SecurID Access Enterprise customers are eligible for Single Sign-On (the SSO Agent) if all of the following statements are true:

    • You have a minimum 1,000 RSA Authentication Manager Enterprise or RSA SecurID Access Enterprise Licenses
    • You have upgraded to RSA Authentication Manager 8.2
    • You have an active RSA Authentication Manager Enterprise or RSA SecurID Access Enterprise Maintenance Contract

 

3. RSA SecurID Access Premium Edition includes all the functionality of RSA SecurID Access Enterprise Edition plus the full functionality of RSA Via Access including the Authentication (MFA) Service to protect cloud and SaaS applications with a variety of mobile optimized authentication methods, which include push notifications, biometrics and FIDO coupled with Identity Assurance. RSA is leading the innovation in Identity Assurance – the concept that various contextual items about a request for access such as location, device, role, and application – should be used to make real time risk-based authentication decisions. RSA is leveraging its legacy in risk-based analytics to bring this innovation to the RSA SecurID Access solution.

        

RSA Via Access customers, will have their licenses converted to RSA SecurID Access Premium. This license entitles customers to all the features that were part of RSA Via Access plus some additional capabilities.

 

To keep using the product as you have been, RSA Via Access customers don’t have to do anything.

 

The new capabilities RSA Via Access customers are entitled to include the ability to connect to legacy, enterprise resources (like VPNs, mainframes, etc.) through our 400+ RSA SecurID agents. For more information on how to take advantage of this new capability, check out the details athttps://community.rsa.com/docs/DOC-53954.

 

The press release on the new RSA SecurID Identity Suite can be found RSA Changes the Identity Game: Unveils New RSA SecurID® Suite.

 

This is an exciting step for us as we continue our journey in identity solutions at RSA!

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.

While RSA Via Access supports using any identity source attribute in creating policies, user groups is probably the most commonly used attribute. What's great about groups is they give you pre-packaged sets of users with similar job functions. With the policies in Via Access, groups alone can offer great flexibility in access control.

 

Let's look at an example. Both my IT department and my Sales department need access to Concur for expenses. The Sales department has iPhones with TouchID and the IT department does not. However, the IT department has been issued SecurID tokens. As a company we want to offer single sign-on with additional authentication to Concur for all these users.

 

Let's take a look at how to make that happen.

 

First, I will create a new policy and select the appropriate identity source(s) where these users reside. Administration Console Access / Policies / Create a Policy.

 

To build my rule sets, I will first enable sales access by adding a new rule that selects the virtualGroups attribute.

Note: I could also use memberOf, but would need to include the full distinguished name (i.e. CN=Sales,OU=Mach_4_Corp,OU=MST,OU=United_States,OU=North_America,OU=Clients,DC=kc,DC=org ). VirtualGroups lets me strip out just the group name, "Sales".

 

Once I select "virtualGroups", I will select the operator "Set Contains Any" and enter the value "Sales". This says I'm restricting access to only users in the Sales group.

 

Screen Shot 2015-09-09 at 9.21.54 PM.png

 

 

When I save that setting, I've allowed sales access. In order to require sales to use "Fingerprint" as the step-up method, I first need to choose step-up required. I then choose the scheme and sensitivity that I have previously mapped to Fingerprint. In this case "Basic Step-Up Authentication" with a sensitivity of "High".

 

Great! I've got a rule set that allows sales access if they use their Fingerprint. We're half done.

 

 

Screen Shot 2015-09-09 at 9.26.18 PM.png

 

 

Now we need to enable IT access. To start, I will choose the option to create a new rule set. This new rule set will follow the first. Since the policy builder uses the XACML standard of First Applicable between rule sets, if I'm a user that's not in sales, the next rule set will be evaluated to see if that rule set grants me access.

 

I will repeat the steps I just did for selecting the attribute "virtualGroups" with the operator "Set contains any" with a value of "IT".

 

To add SecurID as the step-up required for the IT folks, I will again select step-up required and choose the scheme and sensitivity tied to SecurID. In this case "Basic Step-Up Authentication" with a sensitivity of "Medium".

 

 

Screen Shot 2015-09-09 at 9.23.42 PM.png

 

 

Anyone not in sales or IT will be denied access because neither of these rules sets apply to them.

 

Screen Shot 2015-09-09 at 9.28.14 PM.png

 

 

I can save this policy and then apply it to my Concur app and any other app where I want to use this policy using the application access page of application setup. Once this is done and I publish the changes, my sales team can access Concur using Fingerprint and IT can access Concur using SecurID.

Darren Platt has published a blog about the importance of deployment flexibility in leveraging IDaaS in a Hybrid World. In the post, Darren discusses the importance of migrating to the cloud in the way that makes sense for each company. Many applications are still on-prem while others are in the cloud but users want an experience that doesn't differentiate. With Via Access, we strive to provide end users with a consistent experience while providing enterprise level security. Whether through integrating with an existing WAM or using Via Access to connect to on-prem and SaaS applications, the Via Access hybrid model is purpose built for combined environments.

Filter Blog

By date: By tag: