Skip navigation
All Places > Products > RSA SecurID Access > Blog > 2019 > October
2019

An RSA Cloud Authentication Service (CAS) customer asks the following:

"Is there a way to lock the self service portal (CAS My Page) down to just our public IP address range?"

The short answer is yes.

 

UPDATED: 11/22/2019 with information on FIDO.

 

Because the Cloud Authentication Service and it's associated My Page are cloud tenanted services, initial access is allowed to CAS login pages (Admin and My Page) from anywhere. This would be the same as anyone being able to access Amazon, Microsoft or Google logins from anywhere. The ability to restrict users from moving forward in the My Page self-registration process, as with leveraging AWS, Azure or GCP functions, is based on strengthening access to these services using CAS administrative options.

 

A Review of Customer Options for Securing the My Page Self-Registration Experience

 

To review, customers may strengthen access to the My Page self-service registration experience in the following ways:

 

1. Restrict By Password Plus Policy

 

When setting up the My Page service, a policy for access to the page must be selected. This policy can be written to take into account a number of items when granting access to the page. Additional step-up can be required. For premium customers, HTML5 geo-fencing is available as well as Trusted Networks in order to network restrict authentication attempts.

 

In the case of "chicken and egg" new user scenarios where step-up authentication may still be desired, premium customers have the option of requiring MFA for Authenticate app token registration or FIDO token registration through SMS or Voice on-demand authentication (ODA), selected by policy. The identity source linked to My Page 

authentications must, in these cases, have a user's mobile device number registered in the identity source and that mobile device number sync'd into the CAS.

 

Trusted Networks is a premium option that allows customers to deny authentications attempts by users who attempt to register from outside of a trusted network location. I will describe this in detail after a brief review of the other two remaining options for further locking down and protecting the My Page self-registration experience.

 

2. Restrict By SecurID

 

Customers with existing hard/soft tokens (supported by the Authentication Manager) can select "SecurID" to use SecurID tokens to 2FA protect the My Page registration and then register FIDO tokens and/or the Authenticate app to move from a soft/hard token experience to a more modern MFA experience on the Authenticate app.

 

This is done simply by selecting "SecurID" as the authentication option under Authentication on the My Page configuration page.

 

3. Restrict By FIDO Token

 

Customers with registered FIDO tokens can select "FIDO" to use FIDO tokens to further protect My Page access.

 

This is done simply by selecting "FIDO Token" as the authentication option under Authentication on the My Page configuration page.

 

4. Restrict Through Use of an Alternate Cloud IdP

 

Using this option, customers may leverage another existing cloud IdP for seamless authN into the My Page registration experience.

 

This is done by selecting "Performed by Cloud Identity Provider," and selecting a Cloud Identity Provider from the adjacent drop down, or by clicking "Add Cloud Identity Provider" to add a cloud identity provider. (The details for adding an external cloud identity provider are out of scope for this discussion. For information on adding an external Cloud Identity Provider to the CAS, click here.)

 

For further documentation on securing the CAS My Page Self-Service Registration experience, please click here.

 

Denying CAS My Page Access to Users Outside of Trusted Networks

 

Let's go back now and demonstrate how a customer would deny authentication to users attempting to self-register from network locations outside of an established, trusted network.

 

1. Add Your Trusted Networks

 

First, we need to build our trusted networks from which we will accept My Page authentication attempts. Any attempts from outside of these trusted networks will be summarily denied by policy, regardless.

 

1A. Log into the CAS Administration Console:

 

Enter the administrative credentials you were provided or that you have subsequently created to login to the CAS Administration Console and Sign In.

 

1B. Go to the Trusted Networks page to add your trusted network(s):

 

 

Click "Add" to add any trusted networks from which you would like to allow authentication attempts. Any authentication attempts from outside of these networks will be denied by policy, regardless. Here, I have already added a hypothetical trusted network called "Home" with a hypothetical single external address.

 

Addresses are added using CIDR notation with address and network mask to allow for blocks of IPs to be added quickly and easily.

 

Click Save to save the Trusted Networks that were added/created.

 

2. Build A Location-Specific Policy

 

Next, we need to build a location-specific policy that will deny logins to users who attempt to register from outside of the trusted network we have designated previously above.

 

(Consider: Any user from anywhere will still be able to reach the My Page login page. But attempts to login from outside of a trusted network will be denied, even if valid credentials are entered. The denial of the login provides the user making the attempt with no clue as to whether the credentials themselves are correct or not. All logins, valid or not, will be denied out of hand if attempted outside of the trusted network we have established.)

 

 

2A. Go to the Policies page to add a new policy:

 

 

2B. Click "Add A Policy".

 

 

2C. Complete The Policy Wizard.

  • Name the policy (example: "Network-Restricted My Page Access")
  • Give the policy a good description (optional) (example: "Deny My Page logins from locations outside of trusted networks")
  • Select the identity sources you wish to include in the policy (this will determine which users, if they fall into the trusted network locations at login, will be able to successfully authenticate).
  • Build the policy rule/ruleset (I will expand explanations at that point).

 

Here we pick a good, descriptive name such as "Network-Restricted My Page Access." You can enter any name and description that best suits you.

 

Here we select the identity source from which we will accept and validate authentications to the My Page page. In this case, I have selected my own Demo AD sitting on-prem. Any available source your organization has will work fine.

 

In this example, we will use any user from the previously selected identity source (eg. my Demo AD). If you would like to further restrict which users may authentication to My Page, you may select "Selected Users" under Target Population, and apply additional conditions for selecting groups of users specific to this policy.

 

Our access will be selected as "Conditional" because we will be basing access on trusted network locations in the next few steps.

Under Access Details and "Conditional", click the "Add" button to begin adding the conditional access.

 

In the dialog that results from clicking "Add," choose "Trusted Network" and "True" under Attributes. Choose "Allow Access" under Action. Click Save.

 

Now our Access Details for the policy rule should look like this:

 

 

The rule now reads as follows:

 

"For all the users in the selected identity source, use conditional access for this policy. That conditional access will be: (a) for users inside of a trusted network, we will validate primary authentication and allow access if primary authentication from the identity source is valid. (b) For users outside of the trusted network, we will deny access, regardless."

 

Click Save and Finish to save the new policy that restricts authentications based on Trusted Networks.

 

3. Apply Our Network-Restricted My Page Access Policy

 

Now we just need to apply this policy to the My Page configuration, and we will achieve our goal of restricting authentication attempts to users authenticating only from trusted networks.

 

3A. Go to the My Page Configuration Page.

 

 

3B. Select The Network-Restricted Policy Previously Built.

 

Our intended method of allowing authentication to the My Page self-registration experience is through (a) primary authentication against our selected identity source, (b) restricted to trusted networks only. Any authentication attempts that either fail primary authentication or take place outside of the trusted network will be denied.

 

So we want to choose "Password" as the Primary Authentication Method under Authentication. And the policy we built as the Access Policy for Additional Authentication.

 

After selecting the policy we built to restrict authentications to our trusted networks, click Save above.

 

4. Publish Our Changes

 

As always whenever we make changes in the CAS Administration Console, we need to publish our changes to make them live.

 

 

Let's Review!

 

In this article, we learned:

  • Like any public cloud offering, login pages to RSA Cloud Authentication Service can be accessed from any location, by any user on the internet.
  • We can strengthen access to the RSA Cloud Authentication Service My Page self-registration experience using a number of options, available administratively to customers of CAS.
  • All options for strengthening My Page authentications were briefly reviewed.
  • A specific cookbook recipe was shared for restricting My Page authentications to only networks we trust using three building blocks:
    • Trusted Networks (available to Premium customers)
    • A specific, network-restricted policy (that included Trusted Networks)
    • Application of our network-restricted policy to the My Page configuration page

This blog started as a knowledge base, KB article, but it was quickly decided by the KCS content review team that any put in this KB would be added to, and possibly changed.  It is our hope that all growth here will be useful.

 

While RSA does not have a Best Practices Guide for Authentication Manager, we do have planning, performance and configuration guides.  See    RSA Authentication Manager 8.4 Performance & Scalability Guides   See Also

RSA Authentication Manager Previous Versions page for versions earlier than 8.4.

 

Principles

  1. Probably the single best piece of advice I ever got in the technical business world is that "you tend to get more credit for a small success than a big failure."  So good principles are to watch scope creep, keep jobs manageable and then use manageable subprocesses as building blocks for larger processes or jobs.
  2. Try to stay up to date with versions and patches.  Not only are new features are included in newer versions, but bug and vulnerability fixes are always targeted for the latest releases.  Be aware that your support contract mandates staying current with versions, and that asking RSA apply new fixes to older versions results in exponentially more complex Quality Engineering test scenarios, especially in the area of upgrades or updates.  Applying a hot fix to an older version of AM means QE has to go back and test previous version updates.
  3. Authentication is the act of verifying the authenticity of someone or something; in other words, to make sure someone is who they claim to be.  Authentication is the foundation of all access control, and all access controls are only as sound as the authentication system under girding them.  Authentication Manager two factor authentication (2FA) is the integration of something you have (the tokencode) and something you know (the PIN) into the passcode.
  4. If your tokens do not require PINs (that is, PINless tokens), then you do not have 2FA configured. and have an inherently less secure authentication mechanism.
  5. If you mate PINless tokens with passwords, you have a multi-factor authentication (MFA), which may or may not be a strong as 2FA, depending on the degree of integration and the protection of token seeds.  What I'm saying is there is a debate, which we will not resolve here, and all I can say is this debate revolves around the concept that one eight-foot high fence is considered more secure than two four-foot high fences.  Your risk analysis needs to determine if your MFA is sufficient to mitigate your risk concerns in according to your business principles.


Technical Principles

  1. You cannot extend the size of the RSA Authentication Manager appliance disk drive on a virtual machine after it has been deployed.  To resolve this, you will need to deploy a new instance, probably a replica that you will promote.
  2. Authentication Manager is an authentication system first, and only secondarily a reporting system; therefore you need to understand several database concepts, such as managing log archival maintenance, which lets you understand how long authentication and administration data is maintained in the database for your authentication and administration reports.
  3. Log archival management is closely related to database management.  As authentication and administrative activity is logged into or added to the database, the database grows in size. As this information grows older there is a point where is should be archived out and purged from the database, so that the database does not grow infinitely.  However, most databases do not automatically compress the space allocated to this information as it is archived, so the database does not instantaneously shrink, instead the database marks this space as writeable so newer logged data can use this space, so that the rate of growth of the database is slowed.  If you want or need to compress the the Authentication Manager internal database, you need to run the postgres vacuumdb utility.  For information on how to run this utility, please contact customer support and open a case.  Cite article 000035033.
  4. If your Authentication Manager primary runs on VMware you may have deployed this server with the default disk size of 100GB.  If you also have thousands of users, there may be circumstances where due to logging and archiving your disk could be at risk for filling up.  Therefore, it is wise to configure a Critical System Event Notification in the Security Console (Setup > System Setup), and enable an email for Low disk space events.  Optionally modify the warning threshold from the default setting of 5GB to something larger to give you an earlier warning.  See 000036191 - How to modify the low disk space critical event email warning threshold from 5 GB to 10 GB free in RSA Authentication Manager 8.2.1 and higher for more information.

Recommended KBs


Server consoles


Agent and Authentication Knowledge


Linux and certificate knowledge


Authentication Manager Integration Service (AMIS) articles


Hardware appliance knowledge

Filter Blog