Configuration de la sécurité pour la fonction rtcomm-1.0
Cette rubrique décrit les nombreux aspects de la sécurisation de la fonction rtcomm-1.0.
Pourquoi et quand exécuter cette tâche
La procédure suivant décrit le mode d'activation de la sécurité pour la fonction rtcomm-1.0.
Procédure
- Configurez SSL.
- Utilise SSL entre la fonction rtcomm-1.0 et le courtier MQTT
- Cette fonction est activée pour rtcomm-1.0 en définissant l'attribut sslEnabled="true" pour Rtcomm dans le fichier server.xml, ce qui nécessite souvent un port différent pour SSL (port par défaut 8883) pour la connexion au courtier.
- SSL entre la fonction Rtcomm JavaScript et le courtier MQTT
- Si le client rtcomm.js est servi via https, il activera SSL
par défaut (et tentera d'utiliser le port 8883) ; sinon, SSL doit être activé
dans la configuration lors de l'initialisation du fournisseur EndpointProvider. La configuration est similaire à l'exemple suivant :
var providerConfig = { server: mqttbroker server, port: mqttbroker SSL Port, useSSL: true};
La procédure précédente garantit que les communications entre les clients, le courtier MQTT et le serveur Liberty qui exécute la fonction rtcomm-1.0 sont chiffrées.
- Configurez l'authentification.
- Authentification et autorisation du client JavaScript avec le courtier MQTT
- En règle générale, une application qui implémente la fonction de communication en temps réel (Real-Time Communications)
authentifie un utilisateur.
Pour plus de détails, voir Authentification des utilisateurs dans Liberty.
Un grand nombre de courtiers MQTT externes peuvent nécessiter une authentification, mais ils n'utiliseront pas la même que l'application sans une configuration spécifique.
Un courtier MQTT externe peut utiliser des mécanismes d'authentification similaires et offre différentes façons d'utiliser des jetons LTPA pour vérifier l'identité. IBM® MessageSight prend en charge LTPA et quand les clés LTPA sont partagées avec le courtier MQTT MessageSight, il existe des membres du même domaine (servername.domainname.com), et ils peuvent utiliser la même ressource LDAP pour identifier les utilisateurs, puis un jeton LTPA peut être utilisé pour transmettre l'authentification d'origine à IBM MessageSight. D'autres courtiers MQTT peuvent fonctionner de façon similaire. Pour plus de détails sur l'utilisation de LTPA avec IBM MessageSight, voir Lightweight Third Party Authentication (LTPA).
Le serveur Liberty doit être configuré pour l'utilisation des informations suivantes, Configuration LTPA sous Liberty.Remarque : Utilisez l'attribut ssoDomainNames pour définir le domaine commun entre des serveurs :<webAppSecurity logoutOnHttpSessionExpire="true" singleSignonEnabled="true" ssoDomainNames="domainname.com" />
L'authentification qui utilise LTPA est séparée de l'autorisation ou de l'autorisation dans IBM MessageSight, et il est nécessaire de suivre les instructions fournies à l'adresse suivante : Autorisation.
La configuration fonctionne uniquement si l'authentificateur d'origine, fournie par le jeton LTPA et le serveur MessageSight, partage la même configuration LDAP.
- Authentification de client sans LTPA
- Si LTPA ne peut pas être configuré, le client rtcomm.js fournit une API permettant de fournir
un utilisateur et un mot de passe pour l'authentification avec le courtier MQTT, ce qui est fait dans la configuration
transmise au fournisseur EndpointProvider lors de l'initialisation init() :
var providerConfig = { server: servername, port: port, useSSL: true, credentials: { userName: "username", password: "password" } };
Cette configuration transmet l'identité et le mot de passe au client MQTT afin d'authentifier la connexion au courtier MQTT.

Nom du fichier : twlp_config_rtcomm_security.html