Hi Brian,
Some of the things you can do:
Hope this helps.
As a quick workaround, you can remove "Everyone" - "Read" permissions from the pages. Usually it's enough to remove it from the root page, if everything else inherits permissions from it.Doing this will require authentication to access any page.
Any static resources though still can be available to anonymous via direct links, or custom API requests can be configured to access without authorization etc etc, so IP whitelisting would be better solution in a long run.
You can implement custom solution to require authentication if site is being accessed not via list of approved public domains - like require authentication if anyone requests a not "www." domain. That can be done via app.MapWhen(...) in startup.cs with filtering based on request hostname.
I assume you meant DXP sites - in that case you can request service desk to only allow specific IP ranges to access the site
We have a custom middleware that will prompt for a pincode in integration and prep (and prod before going live).
Once the correct pincode is entered we use cookies to allow subsequent user requests.
Certain urls (integration endpoints) and user agents (e.g. DXC automation, screaming frog) are allowlisted so that they don't need to authenticate.
Working with IP restrictions can be a bit cumbersome because you probably want to be able to access the site from mobile etc.
For backoffice we use IP restrictions tho (also in middleware).
Thank you for the input! For IP whitelisting, is there a built-in Optimizely CMS12 solution for this, or do I need to "roll my own" using middleware or a third-party NuGet package?
Thanks again!
Not a builtin solution that I'm aware of. but implementation is pretty straightforward Client IP safelist for ASP.NET Core | Microsoft Learn
There is an article from Opti on this as well: Restricting environment access
We use a custom middleware for within our DXP solutions that requires a user to either be a logged in CMS user or to have an approved IP address on a CMS editable IP Allowlist. It's essentially an extension of the documentation linked by Siddharth: https://docs.developers.optimizely.com/digital-experience-platform/docs/restricting-environment-access
Hi,
In general, what is the best practice for locking down integration and pre-production so that only internal organization users can access both CMS and frontend?
Thanks,
Brian