In order to provide a simple, yet powerful Identity-as-a-Service (Idaas) offering, Nebula utilizes best practices from a system & procedures standpoint, in conjunction with the proven, off-the-shelf PortalGuard functionality. This section describes the underlying architecture of the Nebula service.
Nebula is hosted on Microsoft's Azure cloud platform. Azure is a world-class infrastructure that boasts numerous regional data centers with geo-redundancy. Each Nebula cluster starts with:
Load Balancing and High Availability
Each Nebula cluster maintains high availability and substantial load balancing via Microsoft Azure's built-in Load Balancing (link). The Azure Load Balancer is a Layer-4 (TCP, UDP) type load balancer that distributes incoming traffic among healthy service instances in VMs defined in a load balancer set. Nebula uses the Internet-Facing type of load-balancing. Each VM in a Nebula cluster runs IIS to help balance front-endload.“Sticky sessions”are not enabled, resulting in a truly RESTful implementation.
Azure's built-in resource monitoring allows Nebula to dynamically add or remove cluster members for regular maintenance, as well as provide automatic failover if a cluster member fails. Multiple probes in different Azure data center locations are setup to automatically determine each cluster member's health to ensure that only functioning members are participating in the cluster.
Static External IP Address
Each Nebula cluster has a single, dedicated static IP address, which will vary depending on the data center in which the cluster resides. These IP addresses are what end-users use when connecting to Nebula. It is also the IP address seen by customer networks when Nebula connects to any on-premises customer directories. When accessing Nebula using the standard customer.ondemandlogin.com name, PistolStar manages the DNS entries since it maintains that DNS domain.
NOTE: It is possible for Nebula to be accessed using a customer's own DNS domain (e.g. login.customer.com). In this configuration, the customer is responsible for both adding the corresponding CNAME entry in their own DNS, as well as providing the SSL certificate to Nebula engineers for installation on the VM cluster members.
The Nebula VMs are members of their own virtual LAN within Azure. This network is wholly contained within each Azure Data Center and is used only for VM-to-VM traffic such as SQL replication
By default, Nebula uses a SHA-2 SSL certificate from a globally recognized 3rd party Certificate Authority which helps ensure that all devices can make secure connections to the Nebula service. Each IIS server handles its own HTTPS connections directly via built-in IIS support (the Load Balancer performs SSL pass-through). Microsoft IIS utilizes Microsoft's own cryptography library for SSL/TLS connections, so it was never vulnerable to OpenSSL-specific bugs like HeartBleed.
Nebula accesses customer directories in real-time. It does not rely on synchronization to create a duplicate, local copy of users and their associated passwords in the cloud.
Nebula's direct connection method supports accessing the following directory types:
Note on Active Directory: Making a Read-Only Domain Controller (DC) available to Nebula works for Single Sign-on purposes to authenticate users, it is not sufficient for Self-Service Password Reset in a hybrid-cloud environment.
Numerous steps are available to ensure that this direct connection is as secure as possible. The measures that each customer takes will depend on customer-specific risk tolerance. Some common options/layers for securing the connection between Nebula and a customer's directory are (from less to more secure):
For SQL-based directories, Nebula uses encryption at the ODBC layer to ensure confidentiality of the connections.