Safelisting / Whitelisting

Wes.D.204 Posts: 2 🔍
edited February 1 in Development
Hello, I am wondering if there is a way of tightening the safe listing / whitelisting so that our clients can only login to our subdomain while accessing whatever other subdomains the components and apis need to reach out to function. My employer does not our clients having access to logon to other organization's Brightspace environments.


  • brad.r.503
    brad.r.503 Posts: 35

    To restrict your clients' access so they can only log in to your specific Brightspace subdomain, while still allowing necessary access to other subdomains for components and APIs to function properly, you'll likely need to implement a combination of domain restrictions and network configuration rules. Here are some steps and considerations to tighten the safe listing/whitelisting in your organization's Brightspace environment:

    1. Domain Restrictions:
      • Restrict Login Page Access: Ensure that the login page for your Brightspace environment is only accessible from your organization's subdomain. This can usually be configured within Brightspace's administrative settings or by working with D2L support.
      • Implement a Custom Login Portal: Create a custom login portal for your clients that authenticates users before redirecting them to your Brightspace subdomain. This portal can enforce additional security measures and ensure that only authorized users reach your Brightspace login page.
    2. Network Configuration:
      • IP Whitelisting: Configure your network firewall or Brightspace's IP restriction settings to only allow access to your Brightspace environment from specific IP ranges that your clients use.
      • VPN Access: Require that clients connect through a VPN to access your Brightspace environment. This adds a layer of security and ensures that they are coming from a trusted network.
    3. Brightspace Configuration:
      • Subdomain Configuration: Work with D2L support to ensure that your Brightspace instance is configured to recognize and accept connections only from your specific subdomain.
      • API Access Restrictions: If you're using APIs, ensure that they are set up to only communicate with your subdomain and the necessary service endpoints. This might involve configuring CORS (Cross-Origin Resource Sharing) policies or similar settings.
    4. Client Education and Policies:
      • Educate Your Clients: Make sure your clients are aware of the access policies and understand the importance of connecting only through the approved methods (e.g., using the correct subdomain, VPN).
      • Usage Policies: Establish clear usage policies that prohibit accessing other organizations' Brightspace environments and explain the consequences of such actions.
    5. Regular Audits and Monitoring:
      • Access Logs: Regularly review access logs to monitor for any unauthorized attempts to access your Brightspace environment.
      • Security Audits: Conduct regular security audits of your Brightspace configuration, network settings, and client access patterns to ensure that the restrictions are working as intended.

    Remember, while configuring these settings, it's crucial to maintain a balance between security and usability to ensure that legitimate clients can access the necessary resources without undue hindrance. It's also advisable to work closely with D2L support and possibly a network security specialist to implement these measures effectively.