Skip navigation
All Places > Products > RSA SecurID Access > Blog > Author: Shashank Rajvanshi

RSA SecurID Access

4 Posts authored by: Shashank Rajvanshi Employee

Passwords suck

No one likes passwords, and they are the weakest link in the security chain. End users have way too many passwords to manage and they are impossible to remember— especially when you are required to change them every few weeks. 80% of breaches still involve compromised and weak credentials1. Passwords are expensive for administrators and help desk, as difficult passwords get forgotten frequently and results in higher administrative and help desk costs. In 2018, security breaches costed companies an average of $3.86 million per breach². For CISOs, they are the leading cause of breach-related nightmares. End users and administrators can easily fall into the trap of phishing attacks, resulting in access to systems or database breaches and exposing critical customer and organizational information to adversaries.

 

Passwordless is not new to RSA

Do you know that RSA has been providing passwordless experience to our customers? Yes, for last 35 years our customers have been using RSA SecurID Tokens for securing their VPN, firewall, Unix servers and much more without requiring passwords -- a passwordless experience. Building on this, now end users can also use FIDO2 authenticators for passwordless authentication experience when accessing Web/SaaS applications (acting as SAML Service Provider) and using RSA Cloud Authentication Service as Identity Provider (IdP).

 

FIDO as a strong authentication method

For starters, the FIDO protocol, part of FIDO Alliance, uses standard asymmetric cryptographic techniques to provide stronger authentication which offers a much better phishing resistant alternative to passwords. During the FIDO device registration process, a user’s device creates a public/private key pair and registers its public key with the online FIDO service. Authentication is done by the client device proving possession of the private key to the service by signing a challenge sent by the service. In FIDO2, the client’s private key can be used only after the user unlocks the FIDO device using secure action such as PIN or Bio-metrics. Many of the Hardware FIDO2 authenticator vendors offer tokens that can be setup to use PIN or have a built-in fingerprint reader on the device to secure the private key. Many of the Software FIDO2 Authenticators built into platforms (e.g. Google’s Android 7+ mobile platform or Microsoft Windows 10 1903 patch) can also secure the token using Face Id (or other methods) for user verification, if supported by the device they are running on.

 

If you are wondering how FIDO2 is considered a strong authenticator and a better phishing resistant alternative, reason is that it supports MFA by providing two of the three authentication factors required to meet NIST 800-63-3 AAL2 security requirements – Know something (PIN) OR Are something (Biometrics) AND Have something (asymmetric cryptography based FIDO2 Token).

 

FIDO Token enrollment and self-service at scale

While FIDO2 protocol requires need for user verification and uses asymmetric cryptography for strong authentication, it does not talk much about life cycle management of the FIDO token itself from end user’s point of view and leaves it to the security vendors offering FIDO2 as an authentication service. RSA strongly believes that using FIDO at scale within the enterprise requires far more than just adopting a new authentication protocol. Managing the entire lifecycle of FIDO tokens at scale plays an important role in the success of its adoption within an enterprise. As an example, it requires making the enrollment process of these devices convenient by offering secure self-service capabilities at scale and also support device replacement in case current device is lost. These are some of the key FIDO token life cycle management aspects which cannot be ignored and need to be taken care at scale within an enterprise.

 

RSA SecurID Access and FIDO Support

RSA is a board member of the FIDO Alliance and has been driving the enterprise security workstream. RSA SecurID Access has been supporting FIDO devices for many years as an additional authentication method, and now we are extending that support to use FIDO2 authenticators as a primary authentication (2FA/MFA) method replacing password to access SaaS or Web Applications (service providers).

 

 As part of RSA SecurID Access, both FIDO and FIDO2 devices can be managed using the enterprise grade RSA self-service portal My Page. In case users lose their FIDO devices, they can go to My Page and delete the existing device and register a new FIDO device. If these FIDO authenticators are used as step-up authentication, they can also be registered in-line during step-up authentication flow itself.

Let us discuss below the end-user experience of using FIDO2 Token to securely access SaaS/Web applications followed by administrative workflow of managing the FIDO2 authenticator using RSA SecurID Access.

 

End-User experience using FIDO2 Token

Enterprises are looking to provide friction less user experience to their modern work force who needs to access business applications from anywhere and anytime. Passwords being prone to phishing attacks and hard to manage, customers can now offer FIDO2 Tokens to their end users to gain access to business-critical applications. Now users accessing SaaS Business Applications like (Salesforce) can use FIDO2 Token to securely authenticate and get access these applications without requiring password.

 

Click on this demo to see how RSA SecurID Access allows a user (a sales person in this example) to use FIDO2 Token to authenticate their identity and get access to their Salesforce account after validation.

 

Demo 1: Passwordless Authentication using FIDO2 Token

 

Understand the steps involved in authenticating using FIDO2 Token

Let us briefly talk about the authentication flow using FIDO2 Token shown in the demo. In this use case Administrator has configured a service provider (e.g. Salesforce) to require FIDO2 Token for passwordless authentication and end-user already has a registered a FIDO2 Token to use.

 

 

  1. User tries to access Salesforce (SP) and chooses RSA SecurID Access as an Identity Provider (IdP) to authenticate. User is redirected to IdP (CAS). SP and IdP are communicating over SAML.
  2. User enters their email address and CAS checks the access policy for this user and finds that FIDO2 Token is required as primary authentication method.
  3. CAS challenges the user to authenticate using FIDO2 Token. User presents FIDO2 Token to authenticate and uses PIN or Biometric for user verification. Note that this is a passwordless authentication flow.
  4. CAS (FIDO Servers) authenticates the user and communicates to SP using SAML about the successful auth.
  5. SP (Salesforce) allows user to access their account after successful authentication.

 

End-User experience enrolling FIDO token at scale

1. RSA SecurID Access self-service portal, My Page, to manage FIDO Token

Users can register their FIDO Tokens by using, self-service portal, My Page. This portal also allows users to manage their registered mobile devices along with FIDO tokens. Users can delete an existing mobile devices or FIDO Tokens and re-register new ones in case they lose their current devices using this self-service portal.

 

Demo 2: Registering FIDO Token using My Page

 

 

2. In-line registration of FIDO Token as part of Authentication work flow

In the case where FIDO authenticators are used for additional authentication (not the primary or first factor), new tokens can be registered during the authentication work flow itself. This is not allowed if the FIDO2 token is used for primary authentication. The user must first register it using My Page, as mentioned above.

 

Admin experience enabling FIDO2 Token Authentication for Service Providers

First, an administrator configures a service provider (SaaS or Web application like Salesforce) in the Cloud Administration console and chooses the authentication option RSA SecurID Access manages all authentication and FIDO Token as primary authentication.  

 

                             

With the above steps, an administrator is configuring the service provider to require FIDO Token for primary authentication, without requiring any password. As mentioned earlier, this  has to be a FIDO2 Token as it supports user verification. Optionally, an admin can configure additional authentication methods for higher security, if needed. Also, policy-driven conditional attributes and identity assurance in RSA SecurID Access can be added as part of further securing access to service providers.

 

Admin experience setting up self-service portal, My Page

Administrators, through the Cloud Administration Console, can control if users are allowed to manage their mobile devices or FIDO tokens using My Page. This is where they enable self-service portal for users and manage their mobile devices and FIDO Tokens. Administrators can achieve a higher assurance level by creating a custom access policy using MFA so that users can securely access My page. Optionally, conditional attributes and identity assurance can be added as part of securing My Page for FIDO Token registration

       

In case My Page is enabled for users to manager FIDO Tokens, inline registration will be disabled automatically

 

Summary

FIDO2 is a great step forward, enabling passwordless access to business-critical resources and mitigating phishing attacks. RSA is proud to be leading this effort and helping our customers take passwordless journey for on-prem applications as well as SaaS applications and enabling secure and convenient life cycle management of FIDO Tokens.

 

Verizon Data Breach Investigations Report (DBIR)

2018 Cost of Data Breach Study, Ponemon Institute Research Report

Today RSA announced it has completed an integration on Amazon Web Services (AWS) that will tie Session Tags with identity context through RSA SecurID Access.

 

This integration takes advantage of the benefits of Session Tags (more on this shortly) and the strengths of RSA SecurID Access, an industry-leading and award-winning multifactor authentication and identity assurance solution. RSA customers can now extend the value of key identity context that they already leverage within the product and further enhance the security of their AWS resources. Combined with the RSA SecurID Access flexible deployment (SaaS, cloud, on-premises, or hybrid), choice of authentication methods (mobile push notifications, one-time passwords, fingerprint/facial biometrics, SMS, voice recognition, FIDO and hardware and software tokens), and dynamic, risk-driven access policies – this integration simplifies intelligent identity access and assurance decisions.

 

For the uninitiated, Session Tags enable AWS users to categorize resources and associate them with critical business aspects, such as purpose, environment or owner. In a world of dynamic hybrid cloud environments and workload management, maintaining these connections can be complex or expose users of these systems to risk.

 

As noted, one of the primary parameters for categorization is owner, i.e., who is responsible for maintaining this resource. As our IT boundaries continue to break down, the ability to leverage identity as the basis of ensuring data and resource confidentiality, integrity and availability becomes a critical link in enabling secure cloud strategy.

 

Typically, the only information IAM or security teams have about a user when authenticating to AWS is their username. This piece of information alone is insufficient for an organization to truly understand what that user should have access to. How would a downstream system (in this case, AWS) evaluate the login event and determine whether access to an environment should be allowed? Additional user context added by RSA SecurID Access as Session Tags can help address this gap.

 

Additional context (tags) that RSA SecurID Access could also provide beyond user ID could include: displayName, emailAddress, title, organization, department, manager, and officeLocation.  Given this additional context, appropriate permissions could be applied to session. A customer can create many more of these tags using RSA SecurID Access.

 

All of this additional context could be passed in the form of Session Tags and then appropriate permissions applied based on a user’s department, manager, or some other attributes. This attribute-based access control (ABAC) mechanism enables intelligent decisions to be made downstream by either a human or a machine to support decisions based on business context, i.e. permissions rules in AWS IAM.

 

As part of our growing collaboration with AWS, we’re excited about this integration as another step in advancing customers’ ability to manage new digital risks as they transform IT through opportunities such as cloud computing.

 

Current RSA SecurID customers interested in leveraging this new integration can learn more here.

  • Password-less authentication experience for users accessing SaaS/web applications using FIDO2 Token as primary authentication method

RSA SecurID Access has provided password-less experience to its customers for the last 35 years by offering strong authentication using RSA SecurID Tokens for use cases with VPN, firewall, Unix servers, and more. Building on this, now end users can also use FIDO2 authenticators for password-less authentication experience (in addition to RSA SecurID Token) when accessing Web/SaaS applications, which are acting as SAML Service Provider (SP) and using Cloud Authentication Service as Identity Provider (IdP). The FIDO2 authenticators can be securely enrolled using RSA SecurID Access self-service portal, My Page or using in-line registration process when used for additional authentication. Policy-driven authentication can leverage location or IP address based conditional attributes along with machine learning driven identity assurance for improved security.  

                                                                                               

  • Ensure uninterrupted user access to SaaS/Web apps with new cloud-native emergency access 

Organizations now have two options for emergency access. For Cloud Authentication Service and RSA Authentication Manager deployments, Authentication Manager provides a universal option for emergency access.  Cloud-only deployments now have native emergency access capabilities that can be enabled for end users accessing SaaS or Web applications.  End users who have lost or misplaced their authentication devices can contact the Help Desk, and the help desk administrator can provide emergency access codes that can be used for a specific time period by this useraddi.  Emergency access can be configured as an available authentication method and can be enabled for users even if the RSA SecurID Authenticate app isn't enrolled. This allows greater flexibility, especially in the case where user forgets their FIDO authenticator, which is used for additional authentication.

 

  • Improved productivity and security for Windows sign-in experience with new release of RSA MFA Agent 1.2 for Microsoft Windows

 

RSA MFA Agent 1.2 for Microsoft Windows leverages the RSA SecurID Access Cloud Authentication Services to provide strong multifactor authentication to users signing into Windows machines, both online and offline. This MFA Agent now provides more authentication choices for users, along with features that improve user productivity and security during Windows sign-in. End users can also have uninterrupted access to their Windows machine in case they have temporarily forgotten or misplaced their MFA authenticators (for example, an RSA SecurID Authenticate device or an RSA SecurID hardware token). For more information, see https://community.rsa.com/docs/DOC-108426.

 

  • Corporate re-branding using company logo for the end-user authentication experience

Organizations want to provide a consistent branding experience for their end users during the Cloud Authentication Service additional authentication. Now organizations can display their company logo during the additional authentication flow. Administrators add this logo in the Cloud Administration Console.

 

  • Improved SaaS resiliency and availability

A critical component of the Cloud Authentication Service internal messaging infrastructure, responsible for all communication between components, has been replaced. A more reliable secure connector cloud REST implementation has been implemented and will solidify performance and reliability.

 

  • One employee, one Authenticate app for all accounts

To help improve security, IT admins typically separate administrator and user accounts for the same employee. This is widely regarded as a security best practice because it adds another hurdle for an attacker trying to gain a foothold into the IT infrastructure. However, this meant that these same employees must have separate registered devices running the RSA SecurID Authenticate app per account. Now, with the release of the RSA SecurID Authenticate 3.1 for Android and iOS and a corresponding upcoming release for Windows, these users will no longer need to have separate devices. Users can now conveniently register all their accounts within the same registered app by adding them as they would normally do.

 

  • Share identity risk context with third-party party SIEM platform providers for better threat analysis 

Security operations center (SOC) analysts prefer to have as much identity context as possible during threat analysis to get a 360° view of the incident. RSA SecurID Access can now share such identity context in a more granular way to any SIEM platform. Specifically, customers can now get overall identity confidence scores along with the categories (device, behavior, and location) that influenced or contributed to the overall score. The risk or confidence score are now exposed securely through the Cloud Administration User Event Log API. Through the API, customers can now export user risk information to any Security Information and Event Management (SIEM) platform for further analysis.  This will enable SOC analysts to have better identity context in building Indicators of Compromise (IoCs) and preventing identity specific attacks.

 

RSA continues to strengthen its RSA SecurID Access Cloud Authentication Service with the September and October product release.  For further details on all the new and updated capabilities of the this release, please refer to the Release Notes.

The Cloud Authentication Service now supports multiple RADIUS profiles. Previously, you had to use the same Default RADIUS Profile for all the RADIUS clients. This new, policy-drive capability gives you the flexibility to assign a custom RADIUS profile to a target user population.  You can also provide custom return list attributes, such as VLAN assignments or IP address assignments, to RADIUS client devices, which are used to connect the target user population. The RADIUS server also sends the RADIUS client the Access-Accept message to set session parameters for that user. You can set static attribute values or use dynamic values for LDAP or Active Directory attributes to provide granular control.

 

Multiple RADIUS profiles follow these basic rules

 

 

  1. The RADIUS client can uses only one access policy. This access policy is associated with one or more identity sources and can be used by multiple RADIUS clients.
  2. Each RADIUS client can have multiple custom RADIUS profiles and a list of checklist attributes.
  3. Each access policy has one or more rule sets. These rule sets can be configured to target a smaller user population based on user attributes. For example, a rule set can target only users who have the “manager” title and can control access to specific applications.  
  4. One RADIUS profile can be associated with only one rule set and vice a versa. The rule set must be in an access policy used by the RADIUS client. You can configure return list attributes for the target population tied to this rule set to provide granular control by the RADIUS client device.
  5. You can create multiple custom RADIUS profiles associated with different RADIUS clients which use the same policy.
  6. When RADIUS profile is not created for few rule sets or RADIUS Profile for few rule sets is not associated to this RADIUS client, then for those rule sets (set of users) in this RADIUS Client default RADIUS profile will be used. Default profile can have only static attribute values as part of their return list attributes, if configured.

 

  

 

 

You can create RADIUS profiles as part of the RADIUS client workflow. You can now add checklist attributes when you configure the RADIUS client, whereas in earlier versions, checklist attributes were part of the Default RADIUS Profile. After you configure the RADIUS client, click the RADIUS Profiles on the left Window pan, as shown below, to go to the RADIUS Profile configuration.

 

 

 

 

   On the RADIUS Profile configuration page, you can choose to create a new custom profile. If you do not create one,       Default RADIUS Profile will be associated with this RADIUS client. You can configure return list attributes for this             Default RADIUS Profile, but remember that Default RADIUS Profile is same across all the RADIUS clients. You cannot    delete a Default RADIUS Profile, but this profile will not apply to RADIUS clients that are associated with at least one    custom RADIUS profile. To see the Default RADIUS Profile, select Show default profile. By default this option is       unselected.

 

 

 

Click New Profile to see the custom RADIUS Profile page. This page allows you to add static and dynamic return list attributes from the identity source. After you specify the attributes and rule set, you can associate this RADIUS profile to the client or just save it to make it available to other RADIUS clients. Remember that one rule set can be assigned to only one RADIUS profile. If no rule sets are available, you must create one in the access policy associated with the RADIUS client that this profile is associated with.  

 

You can also choose to disassociate or delete an associated RADIUS profile. If you want to remove a profile from the RADIUS client, click  Disassociate. You can always re-associate this profile with the RADIUS client by clicking Associate. If you delete a profile, the profile will be removed from all RADIUS clients that use it.

 

You can create multiple RADIUS profiles for each RADIUS client and leverage stronger, policy-based, granular control for end-users/privileged users who access RADIUS-protected applications. We will continue to bring additional features and enhancements in future releases of the Cloud Authentication Service. Please feel free to reach out to us with any additional comments and feature requests.

 

Multiple RADIUS Profiles Demo Link

Filter Blog