Restricting Authentication to SecurID CAS Self-Service Registration Page (My Page) by IP Address
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Printer Friendly Page
- Report Inappropriate Content
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.
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
One of our engineers, Shashank Rajvanshi, pointed out the following:
Don't forget that in "chicken and egg" scenarios, customers may also:
- Register their Authenticate Token App using a generated Registration Code (new feature released recently) (no password or My Page Access required).
- Once they have registered mobile device, they can then access My Page using MFA to register their FIDO key or manage those devices.
To execute on this type of workflow, administrators would:
- Generate a one-time registration code for a user on the User Management page.
- Distribute the code to the user (perhaps through secure, in-house email).
- Then leverage Option #1 above -- Password & Policy approach -- and use step up MFA authentication to access My Page. The Registration Code would basically pre-register the Authenticate App with no need to access My Page (as Shashank Rajvanshi pointed out).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.