# Operations System Overview # ## Request Collectors ## __What is a Request Collector?__ Xiid Request Collectors are the frontlines of the Xiid Security System. The Request Collector __collects__ all of the authentication requests that come in from various external applications, such as Office 365, (or internal authentication requests such as XOTC codes) and put them into a __Queue__, which is then consumed by an Xiid Agent. The response from the Agent is forwarded back through the request collector using perfect __Forward Secrecy__. __Where does a Collector reside?__ There are Xiid-vended Collectors which are securely managed on __Xiid’s infrastructure__, distributed across multiple regions and cloud providers. You can also deploy your own Collector as well within your own private network, however this only permissible for highly specialized use-cases. The Request Collector should __never__ be in the same network as your directory service. In fact, we recommend that your directory service be __segmented__ and __isolated__ to its own subnetwork (see Agents below). __Why use a Request Collector?__ The Xiid Request Collector is the __frontline defense__ against threat actors. The Xiid Request Collector is the only component within Xiid’s software that allows external communication for authentication requests. Request Collectors are purpose-built to be __highly-optimized__ (handling hundreds of thousands of requests per second) and __highly secure__ across multiple levels. The Request Collector only has inbound port 443 open for HTTPS communication, the code that runs the Request Collector Service is compiled to byte-code and uses no third-party libraries (eliminating buffer overflow and injection attacks), and the data from requests is not stored on disk, while all data flowing through the Request Collector is encrypted (elminating MITM attacks and reconnaissance). __How does a Collector work?__ The Xiid Collector is effectively a __queue__ that listens for inbound authentication requests, packages the requests into Xiid's patented __Smart-Hybrid Protocols (SHyPs)__, and then puts the requests into the queue. Xiid Agents then __pull requests__ from the collector based on the Agent's purpose, unpacks the data using the second half of the Smart-*Hybrid* Protocol, and forwards the safe request on to the respective resource. The results are then digitally signed behind the closed Firewall and sent back to the Request Collector which then forwards the results to the respective destination. ## Xiid SealedChannel ## __What is the SealedChannel?__ The Xiid SealedChannel™ is a __one-way__ communications channel that is established between an Xiid Agent and an Xiid Request Collector. The SealedChannel works the same way across all Xiid Agents: One-way __outbound__ communication established from the private network, only allows __SHyPs__ to be pulled from the Request Collector's queue, only pulls __Agent-Specific Information__ from the queue and __digitally signs__ responses safely behind the firewall. __Where does the SealedChannel reside?__ Since the SealedChannel is a communications channel, it does not *physically* reside anywhere. *Abstractly*, it resides __between__ the __Request Collector__ and the __Xiid Agents__. __Why use the SealedChannel?__ Xiid's SealedChannel has been meticulously thought-out to __eliminate__ all __attack surfaces__ to private networks. Between the three layers of encryption used to handle the consumption of data by the agents behind the closed network, getting any malicious data or execution through the SealedChannel is effectively impossible, providing an air-tight mechanism to safely allow communication between your network and the internet. __How does the SealedChannel work?__ When an Xiid Agent is set up, a code is provided to the Agent which allows the Agent to reach out to the Request Collector to __establish__ the communications channel. After the connection has been established, requests will be accepted by the Request Collector, __packaged__ with Xiid's SHyPs, and put into the Request Collector __queue__. The Xiid Agent will begin polling for requests from the Request Collector's queue, and will __extrapolate__ any information needed from the request, __route__ it to the proper resource, __digitally sign__ the response, and send it back to the Request Collector, which will then __forward__ the response to the appropriate destination. ## XOTC Authenticator ## __What is the XOTC Authenticator?__ The __Xiid One-Time-Code__ (XOTC) Authenticator is a mobile application developed by Xiid for use in the Xiid Single Sign-On Portal. In a more abstract sense, XOTC Authentication is Xiid's patented technology that allows authentication without __any__ usernames or passwords. __Where does the XOTC Authenticator reside?__ The XOTC Authenticator resides on every __user's phone__ within the organization via the XOTC Authenticator Mobile Application available in the Google Play Store and Apple App Store. All users that are required to sign into an SSO Portal are required to download the mobile application. __Why use the XOTC Authenticator?__ The XOTC Authenticator is the __most secure__ form of Multi-Factor authentication. XOTC takes authentication to the next level by removing user credentials from the authentication process. This has a plethora of benefits: - No __Man in the Middle Attacks__ - XOTC codes do not contain __any__ user credential information, rendering them useless in reconnaissance. - No need to write down or __remember passwords__ - In the event that a user's domain credentials are compromised, Xiid's SSO Portal and the applications within are still protected (authentication must occur from the XOTC Authenticator App, __manual entry is not permitted__ after the credentials are bound). - Streamlined __ease-of-use__ - it's fast and easy to sign in! __How does XOTC Authentication work?__ The XOTC Authenticator starts by __binding__ your credentials to your XOTC Security Profile. When you register your XOTC App with your company's domain, you create a __link__ between the Agent and the XOTC App for your known Group Numbers. From that point, whenever a user __scans__ the QR code on the SSO Portal Screen, the XOTC Mobile App will generate an XOTC Code using one of those Group Numbers and the screen information, and then will send that code to the Request Collector, where the request will be put into a queue and picked up by the Authentication (see [Sealed Channel](#xiid-sealedchannel)). ## Xiid Agents ## __What is an Agent?__ An Xiid Agent is an intermediary thin-wrapper software that acts as the __liaison__ between the Request Collector and your __internal resources__. An Agent pulls requests from the Request Collector queue and will __action__ based on the incoming request, depending on the *type* of Xiid Agent. For instance, Xiid.IM Active Directory Agents will pull authentication requests from the Request Collector Queue and authenticate users against the Active Directory Service. An RDP Agent would pull RDP Access Requests from the Request Collector and generate a one-time-password for the user on the local machine. __Where does an Agent reside?__ The Xiid Agent resides in the __same network segment as the resource__ to which the agent interacts. Xiid highly recommends using proper network segmentation to __separate your resources__ by subnets, with Xiid Agents handling the authentication and access to the resources across your enterprise network. __Why use an Agent?__ Xiid Agents are paramount to the __SealedChannel__ paradigm, and only by use of Xiid Agents can you reduce (or eliminate) inbound ports on your network. Each Xiid Agent that goes online and becomes operational translates to __inbound ports__ that can be __closed__, and subsequently __less attack surface__ for malicious actors. Xiid Agents also manage overhead, __abstract__ and __obfuscate__ pertinent enterprise data (such as user credentials), and extend configurations and customization for the particularities of your enterprise network. __How does an Agent work?__ Xiid Agents __operate differently__ depending on what __resources__ they govern. In general, all Xiid Agents adhere to the paradigms of the SealedChannel (__outbound communication__ channels only, and only __communicating directly__ with the __Request Collector__). The specifics of how interactions with different resources are managed will vary depending on the *type* of Agent deployed. See below for more information. ### Xiid RDP Agent ### __What is an RDP Agent?__ An RDP Agent is a __thin-wrapper software__ that runs on machines which you would like to RDP *into*. The Xiid RDP Agent runs in the background on the machine and __manages__ the __credentials__ used for authentication on the machine through an RDP connection. __Where does an RDP Agent reside?__ The RDP Agent runs on the __remote machine__ that you would like to __RDP into__. There is also an RDP wrapper which you can download and install on any client machines wishing to access the RDP agent. __Why use an RDP Agent?__ RDP Agents __manage credentials__ on the machine, making it safer to RDP into the instance without the fear of having your __credentials hijacked__. The integration of RDP Agents into the SSO Portal also makes it much easier for employees who manage or use multiple remote machines to __easily manage__ the __connections__ and credentials for all of them. __How does an RDP Agent work?__ The RDP Agent is first installed on the remote machine and bound to your Xiid account using the RDP Agent Configuration Code. Next, you can configure the remote machine to be available in your SSO Portals as either an RDP Application or RDP App (VDI) Application. When a user clicks the blue monitor icon in the SSO Portal, a __session__ is started and a request is put in the Request Collector Queue, and pulled in from the RDP Agent. The Agent would then generate a new one-time-password for RDP login and push the __password__ back out to the client's computer, where it is __injected__ into the user's __clipboard__. When the .rdp file is downloaded, the username will already be provided, and the user just pastes the password into the prompt to sign in. ### Xiid.IM Active Directory Agent ### __What is the Active Directory Agent?__ The Active Directory Agent is the __configuration portal__ and __liason__ to your __Active Directory__ services. The AD Agent will handle all authentication interactions with Active Directory and check for access to SSO portals. It also provides the configuration portal for configuring access to various Active Directories (if there are multiple), setting up Firewalls and Translations for credentials, and configuring your Xiid SSO Portals. The Active Directory Agent is the __heart__ of the Xiid Software stack, as almost all interactions with the enterprise network flow through this Agent, either directly or indirectly. __Where does an Active Directory Agent reside?__ The Active Directory Agent resides in the __same network segmentation__ as your __Active Directory Service__. The AD Agent just needs to be able to communicate directly with Active Directory. If you have multiple domains or Active Directories, you can deploy an Agent in each of those network segments. __Why use an Active Directory Agent?__ Active Directory Agents handle all of the __authentication__ requests for your SSO Portal as well as handling __access__ validation for portals and applications. The AD Agent is the heart of the your enterprise security, because your __directory__ is the __life blood__ of your organization. As such, the AD Agent is critical to providing support for any other Agents. Without being able to verify who an individual is, applications cannot be provided securely to them. __How does an Active Directory Agent work?__ Active Directory Agents are deployed in the same network as your Active Directory Service. Once installed, the AD Agent is __bound__ to your Xiid Account using the __Agent Configuration Code__. A browser application will be available on your desktop which you can open to go directly to the Xiid __Agent Management Portal__. The Agent Management Portal allows you to __configure__ Active Directory Agent as well as the Single Sign-On Portals associated with your Xiid account. See the below information on the Xiid Active Directory Agent sub-components for more information. --- The following __sub-components__ are all part of the Xiid __Active Directory Agent__. All of these sub-components reside on the AD Agent and thus the "Where does it reside?" section has been removed. #### Authenticators #### __What is an Authenticator?__ Authenticators define how the AD Agent __communicates__ with the __directory service__. The authenticator is comprised of the information regarding your directory service such as where it is physically located (__IP Address__) and how to interact with (query) the service, and who has __access__ to what resources (Group Include/Exclude). Xiid recommends that the service account used to communicate with the Active Directory be limited to purely querying the LDAP directory; no other permissions, such as write permissions, are needed nor recommended. __Why use an Authenticator?__ An Authenticator serves two main purposes. The first is to aggregate information about how to __communicate__ with your __LDAP directory__. This is necessary to handle to authentication to your SSO Portals and to protect your Active Directory from outside threats. The second purpose is to __limit access__ via Group Include and Group Exclude filters. __How does an Authenticator Work?__ Authenticators are a sub-component of the AD Agent. An __Authenticator__ is comprised of __metadata__ regarding the communication with the directory service, such as Group Include/Exclude, as well as __Connector__, which houses the information for the Active Directory Agent to __connect__ to the __LDAP__ service. This information is then used by Active Directory Agent when authentication requests come into the Request Collector and pulled in by the Agent to validate authentication. Without an Authenticator sub-component, the Agent would not be able to communicate with your Active Directory. #### 2-Factor Authentication #### __What is 2-Factor Authentication?__ 2-Factor Authentication is a framework that utilizes an __“out-of-band”__ device to provide additional validation for an individual’s identity. An “out-of-band” device refers to a device that is not directly tied to the network you are trying to authenticate against. Typically, the out-of-band device is a person’s __smartphone__. Xiid offers two 2-Factor Authentication mechanisms: __Legacy MFA__, which uses the outdated "One-Time-Password" as a secondary authentication mechanism (not recommended), and __XOTC Authentication__, which uses Xiid One-Time-Codes to safely log in users without usernames or passwords (recommended). __Why use 2-Factor Authentication?__ 2-Factor Authentication is an effective method of adding a __layer__ of __security__ to the authentication process. Xiid goes a step further than legacy MFA by using our highly __secure XOTC__ codes, which helps unify the authentication experience and retain rigid security, and keep usernames and passwords out of the broader internet ether. __How does 2-Factor Authentication work?__ Legacy MFA uses a __synchronized one-time-password__ on the user's out-of-band device, which cycles based on a specific algorithm for unique passwords. XOTC Authentication __abstracts usernames__ and __passwords__ behind ambiguous Group Numbers, which are only known by the AD Agent safely behind your enterprise network. For more information on XOTC, see [XOTC Authenticator](#xotc-authenticator). Regardless of which 2-Factor Authentication method you use, you need to create the sub-component (either an XOTC or Legacy MFA) in the Agent Management Portal, and then __add__ it to an __SSO Portal__ to __enforce__ the 2FA mechanism. #### Translators #### __What is a Translator?__ Xiid Translators tell the Xiid Agent how to __convert external authentication__ credentials to the __internal__ format that your LDAP service expects. A single Translator will define the round-trip conversion process from external credentials for authentication requests to the local Active Directory credentials and then inversely converting the authentication response back to the external credentials. __Why use a Translator?__ Translators are necessary to convert __external__ authentication data to __internal__ representations. If you have any __other__ username or __credential formats__ that are not understood by your LDAP service, then you will need a translator to convert the data. __How do Translators work?__ Translators are tied into the operations of the Active Directory Agent. Think of the individual translators as __instruction sets__ provided to the Agent. When the Agent sees a username come in with a certain format, the translator provides the ability to identify that format and then convert from that format to your LDAP format and back. Translators are – in technical terms – __regular expressions__ that parse and replace string characters during the intermediary authentication steps done by your AD Agent. An External to Internal translator may look for the characters “example.com” in the username, and replace it with “example.local” for your LDAP service. The translator would then look for the characters “example.local” coming from your Active Directory and replace it with “example.com” for the Service Provider, such as Office 365. #### Firewalls #### __What are Firewalls?__ Xiid Firewalls are __Application Firewalls__ that provide users the ability to __restrict__ and __allow__ specific IP addresses to authenticate at the SSO Portal. Xiid Firewalls operate between the collector and agent levels, meaning the restrictions and allowances defined in your Xiid Firewalls apply to authentication requests at the initial stage of authentication. The Collector will accept any authentication requests but the Xiid __Agent__ may __accept__ or __reject__ those requests based on the Firewall settings. __Why use a Firewall?__ Xiid Firewalls are not required to set up Xiid’s technology, but they can __enhance security__ to the systems by further restricting what authentication requests are allowed from what IP Addresses. Xiid Firewalls are particularly useful for __blacklisting__ known bad-acting __IP Addresses__ (or compromised systems and services) as well as __allowing__ authentication requests from known __“safe” IP addresses__. You can also use Xiid Firewalls to restrict access to your SSO Portal within your enterprise network as well. __How do Firewalls work?__ Xiid Firewalls are split into two categories: __Blacklist__ and __Whitelist__. Blacklist firewalls can be employed to block specific IP Addresses, such as compromised servers or known __bad actor__ addresses. Whitelist firewalls can be used to indicate that a specific IP address is a known __“trusted”__ address, such as a third-party service or your own enterprise network. Be cognizant of the application firewalls that you create and block malicious addresses while allowing access to intended users. #### SSO Portals #### __What are SSO Portals?__ Xiid SSO Portals provide __access__ to users for their applications. Xiid supports creating as many SSO Portals as you feel are needed for your organization. From the user perspective, the SSO Portals provide all-in-one access to their applications with secure __SAML2 Authentication__ to protect their credentials. From a System Administrator perspective, an SSO Portal is an aggregated __collection__ of __sub-components__ that are synthesized together to create a cohesive __Single Sign-On__ experience for users. __Why use an SSO Portals?__ SSO Portals allow your users to __access__ their __applications__ over the internet safely and __securely__. SSO Portals also provide the flexibility and extensibility to separate access, restrict users, define translations for groups or sub-groups, enforce 2-Factor Authentication, and enforce application firewall rules. __How do SSO Portals work?__ When you configure your Active Directory Agent through the Agent Management Portal, by default a __home__ SSO Portal will be created and use your first Authenticator (once you have created your first [Authenticator](#authenticators) sub-component). You can __create__ additional SSO Portals or __edit__ any existing SSO Portal and change the configurations. The configuration changes happen __immediately__ and may require users to sign back into the SSO Portal to observe the changed configurations. The SSO Portals are then vended by the Active Directory Agent to users based on the configurations you have set up for the portal. #### Applications #### __What are Applications?__ Xiid Applications are integration __sub-components__ used to help configure and __connect__ your Xiid __SSO Portals__ to your third-party web applications (Also known as __Service Providers__). Xiid offers different types of Applications for different purposes, some very specific (such as the Office 365 and GSuite Applications) and some that are more generalized and support various different external applications (such as the SAML2 Application). __Why use an Application?__ Xiid Applications define all of the __configurations__ and metadata necessary to configure an external __service provider__ to integrate into your SSO Portals. For each Service Provider you would like to __integrate__ with, you would create an Xiid Application with the metadata to contact and verify authentication for users into that application. Each of those Xiid Applications will be added to a specified SSO Portal for access by those users. __How do Applications work?__ Xiid Applications will vary based on the *type* of Application you are configuring. Some applications, such as GSuite and Office 365, are more streamlined and include additional instructions to configure the Service Provider and the Xiid Application to integrate with each other. Applications like the SAML2 Application are more ambigious and integration instructions will vary. From a general perspective, all applications require minimum configuration with Xiid for information like the __domain name__ and the initial SAML2 __entry point__, and all Service Providers generally require __configuring__ SSO settings through the __Service Provider__ to allow authentication from an __Identity Provider__. For more information regarding Application Setup, see [GSuite](https://docs.xiid.com/src/google_workspace.html), [Office 365](https://docs.xiid.com/src/office_application.html), [RDP](https://docs.xiid.com/src/remote_desktop_setup.html), or the generic [SAML2](https://docs.xiid.com/src/saml_application.html) setup guides. #### Logs #### __What are Log Components?__ The Xiid Log Component is available for system administrators to aggregate logs from their system for __debugging__ or for __technical support__ from Xiid. __Why use a Log Component?__ The Xiid Log Component should be used when you need to __debug__ or __diagnose__ issues with __Service Provider__ integration or SSO Portals. Xiid does __not__ recommend leaving the Log sub-component __running__ at all times due to computational constraints and security. __How do Log Components work?__ Log sub-components are managed by the Active Directory Agent via the Agent Management Portal. You can __enable__ logging from the __Logs__ tab, which will then __log interactions__ with the Active Directory Agent. The logs are stored in `C:\ProgramData\Xiid\XIID-Agent\logs` by default.