Deployment Scenarios
Physical Deployment Scenarios
Single Computer System Deployment
The deployment model on a single computer is recommended only for non-production environments. In this scenario, all Sentinet Components reside on the same machine. The Sentinet Repository database and Developer Portal CMS database can be installed either on the same or on a different machine(s).
Distributed Deployment
In this scenario, all Sentinet Components are deployed on individual computer systems.
High-Availability Distributed Deployment
In this scenario, Sentinet Node instances and Repository Web Application instances are deployed behind load-balancers for high-availability, redundancy and high-performance.
See Appendix D for more details on the requirement for high-availability distributed installation.
Figure 5 above shows Sentinet Core Components in the high-availability scenario. Developer Portal Application can be placed behind the load-balancer just like all other Sentinet Core Components.
Security Deployment Scenarios
Sentinet Core Components
Sentinet Core Components are configured with five distinct communication channels and each channel is configured with its own security configuration.
Communication channels 1, 2 and 3 connect Sentinet Administrators and Sentinet Nodes with the Repository Web Application. Channels 2 and 3 are configured with mutual authentication security configuration. By default, channel 1 is also configured with mutual authentication security. Channel 1 can be reconfigured with client-only authentication security, Username/Password over HTTP (clear text HTTP transport is not recommended for security reasons).
Communication channels 4 and 5 are external communication channels and do not use the Repository Web Application. Communication channels 4 and 5 apply security that is required by the deployed Managed REST APIs, SOAP services, and the Virtual Services hosted on the Sentinet Nodes and consumed by API Consumers.
Channels 4 and 5 capabilities (including supported security configurations) depend on how and with what capabilities Sentinet Nodes are deployed (this subject is described in further details later in the chapter).
Communication Channel 1. Sentinet Administrative Console to Sentinet Repository Web Application
Channel 1 allows Sentinet administrators to control, manage and monitor the entire Sentinet infrastructure, APIs and services via the Sentinet Administrative Console application. Channel 1 configuration options have the following security deployment options:
| Security Model | Transport | Encoder | User Credentials | User Store | Default |
|---|---|---|---|---|---|
| Forms | HTTPS | Binary | Transport-level Username/Password over HTTPS | Sentinet Repository database | |
| Forms | HTTPS | Text | Transport-level Username/Password over HTTPS | Sentinet Repository database | ✔ |
| Forms | HTTP | Binary | Transport-level Username/Password over HTTP (not recommended) | Sentinet Repository database | |
| Forms | HTTP | Text | Transport-level Username/Password over HTTP (not recommended) | Sentinet Repository database | |
| Windows Integrated | HTTPS | Binary | Transport-level Windows Kerberos or NTLM over HTTPS | Windows Active Directory or Windows local machine accounts | |
| Windows Integrated | HTTPS | Text | Transport-level Windows Kerberos or NTLM over HTTPS | Windows Active Directory or Windows local machine accounts | |
| Windows Integrated | HTTP | Binary | Transport-level Windows Kerberos or NTLM over HTTP (not recommended) | Windows Active Directory or Windows local machine accounts | |
| Windows Integrated | HTTP | Text | Transport-level Windows Kerberos or NTLM over HTTP (not recommended) | Windows Active Directory or Windows local machine accounts | |
| Client X.509 Certificate | HTTPS | Binary | Transport-level client X.509 certificate | Sentinet Repository database | |
| Client X.509 Certificate | HTTPS | Text | Transport-level client X.509 certificate | Sentinet Repository database | |
| Federation | HTTPS | Text | Federation Claims | External Trusted Authority |
The default security deployment model uses mutual authentication security through a HTTPS.The Repository Web Application is authenticated based on its X.509 SSL certificate. Sentinet users and administrators are authenticated based on transport-level username/password credentials. The Repository database functions as a Sentinet User Identity Store.
Communication channel 1 can also be configured with the Windows Integrated Security model.
Administrators and users of the Sentinet Administrative Console can be authenticated based on their currently logged-in Active Directory (Kerberos) or local machine (NTLM) Windows account credentials. This configuration does not require the Sentinet Administrative Console application to present users with the Login screen (see Appendix A for detailed instructions).
Sentinet also supports client-side X.509 certificates as user credentials, and single-sign-on with Federation Claims.
To enable Sentinet administrators to use any user credential type above, install and configure multiple application instances, where each instance is configured with its own user credential type. The application instances must be attached to the same Sentinet Repository database.
Communication Channel 2. Sentinet Node Configuration Wizard to Sentinet Repository Application
Sentinet Node Configuration Wizard uses communication channel 2 to access the Repository Web Application. The channel uses mutual authentication security through an HTTPS transport. The Repository Web Application is authenticated based on its X.509 SSL certificate. Sentinet users and administrators are authenticated based on their username/password credentials.
Communication Channel 3. Sentinet Nodes to Sentinet Repository Web Application
Sentinet Nodes use communication channel 3 for dynamic self-configuration, management of hosted Virtual Services and reporting of the APIs monitoring data to the Sentinet Repository. Mutual authentication security with binary message encoding is used over HTTPS transport. Repository Web Application is authenticated based on its X.509 SSL certificate. Nodes are authenticated based on their client X.509 certificates. Sentinet infrastructure includes a built-in X.509 Certificates Management and Provisioning System to allow administrators the use of either existing certificates or have Sentinet generate and manage new certificates, effectively using the Sentinet Repository application as a Certificates Authority.
Communication Channel 4. API Consumers to Sentinet Nodes
Communication channel 4 can use any security and reliability model, transports, message encodings and security token types supported by Microsoft WCF technology including Microsoft Azure platform specific transports and security models. Actual deployment scenarios depend on hosting features configured in the IIS/WAS service that hosts the Sentinet Node(s). For example, if IIS is configured to support NET.TCP and NET.MSMQ transport, then the Sentinet Nodes can also be enabled with support for NET.TCP and NET.MSMQ transports.
Communication Channel 5. Sentinet Nodes to Managed Services and APIs
Communication channel 5 can use any security and reliability models, transports, message encodings and security models supported by Microsoft WCF technology including Microsoft Azure platform specific transports and security tokens. Actual deployment scenarios depend on availability of Windows specific features configured in the Windows OS. For example, if the Windows OS is configured to support MSMQ, then the Sentinet Nodes can also be enabled with MSMQ support.
Developer Portal
Developer Portal uses Forms based authentication over HTTP(S), where developers’ accounts with their usernames and passwords are stored in the Sentinet API Repository Database.