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:

  • Two or more Virtual Machines (VM) running under Azure's Infrastructure-As-A-Service (IAAS)
  • The VMs run the Microsoft Windows 2012 R2 Enterprise edition OS
  • Each VM in the cluster runs Microsoft IIS 8.5 which acts as Nebula's front-end HTTP Server
  • Each cluster member may have one or more IIS web sites present
  • Nebula stores user profile and reporting/auditing data in SQL. Each cluster member runs Microsoft SQL Server 2014 with a single “master” that receives all reads and writes from the other cluster members. All other SQL instances are considered “backups” that receive real-time updates via SQL Server's one-way, transactional replication.
  • 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.

    Resource Monitoring

    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 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. 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.

    Virtual LAN

    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:

  • Active Directory via LDAP
  • LDAP (e.g. OpenLDAP, Novell)
  • SQL

  • 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):

  • Firewall ACL allowing only Nebula IP(s) to reach the directory (e.g. port 636 of an isolated DC)
  • Utilize an LDAP proxy in the DMZ instead of a DC
  • IPSec between Nebula and the DC using a Pre-Shared Key
  • IPSec between Nebula and the DC using a certificate on Nebula from a customer's Certificate Authority

  • Microsoft Azure has an offering called ExpressRoute (link) that utilizes a dedicated connection between the Nebula cloud server and your network

  • For SQL-based directories, Nebula uses encryption at the ODBC layer to ensure confidentiality of the connections.