nov 11

Mise en oeuvre d’un serveur d’authentification SSO avec CAS et Memcached

sso

Après ce billet où j’ai détaillé la mise en place d’un load-balancing/failover a base de cascade de NS, nous allons passer aujourd’hui à la deuxième partie. Et surtout, au but dont je voulais vous parler dans ce petit challenge technique que mon ami Horacio m’a doucement poussé à réaliser (bien malgré lui :) c’était plutôt un défi personnel que j’avais envie aussi de concevoir).

Au fil de plusieurs discussions techniques enjouées (avec Horacio, le terme enjouée prend rapidement des allures de trolldi :D (private joke)), un système CAS a peuplé nos échanges et je vous en livre ici une explication dans le texte.

CAS (Central Authentication Service) est un système d’authentification unique basé sur une gestion de ticket provisoire.

Il permet à un utilisateur de ne s’authentifier qu’une fois sur un portail web pour avoir accès à diverses ressources (sites web différents la plupart du temps) qui se base également sur ce système d’authentification.
C’est le fameux SSO (Single Sign-On) dont vous avez peut-être entendu parlé.

Le challenge que je me suis donné est bien entendu de rendre cette solution hautement disponible. Si votre serveur CAS est inaccessible, c’est un lot non négligeable d’utilisateurs qui ne pourront plus s’authentifier, avec les désagréments qui vont avec (des gens en cravate partout dans votre bureau ou par dessus votre épaule pour savoir quand cela remarchera).

Quelques années en arrière, je vous avais parlé de Memcached et de la façon de le faire fonctionner en mode sécurisé. Et ça tombe bien, CAS supporte memcached :)

Nous allons considérer que vous avez vos deux serveurs en place, loadbalancés par une technique quelconque (avec PF sous OpenBSD, avec une cascade de NS, avec LVS sous Linux, une appliance propriétaire ou une IP FailOver, bref ce que vous voulez).

Première étape, déployer sur le deux serveurs, un memcached répliqué. Rien de bien compliqué si vous avez lu ce billet (je vous laisse bien évidemment validé que vos clés/valeurs se répliquent correctement).

Déployer un serveur Tomcat sur chacune de vos machines (Tomcat 6 ou 7 à votre convenance, prenez le Core) avec un java 1.6 minimum.
Wget, puis tar xzvf apache-tomcat-x.x.x.tar.gz etc… Rien de transcendant.

- Génération du certificat SSL

CAS exige une connexion https, donc nous allons générer un certificat pour nos tomcats.

serveur:/opt/tomcat7# keytool -genkey -alias tomcat -keyalg RSA -validity 365
Tapez le mot de passe du Keystore :
Quels sont vos prénom et nom ?
[Unknown] :  cas.guiguiabloc.fr
Quel est le nom de votre unité organisationnelle ?
[Unknown] :  guiguiabloc
Quelle est le nom de votre organisation ?
[Unknown] :  guiguiabloc
Quel est le nom de votre ville de résidence ?
[Unknown] :  Brest
Quel est le nom de votre état ou province ?
[Unknown] :  Bretagne
Quel est le code de pays à deux lettres pour cette unité ?
[Unknown] :  FR
Est-ce CN=cas.guiguiabloc.fr, OU=guiguiabloc, O=guiguiabloc, L=Brest, ST=Bretagne, C=FR ?
[non] :  oui
 
Spécifiez le mot de passe de la clé pour tomcat
(appuyez sur Entrée s'il s'agit du mot de passe du Keystore) :

ATTENTION : spéficiez bien le nom « loadbalancé » DNS de votre CAS (le nom utilisé pour joindre les deux instances dans le champ « Quels sont vos prénom et nom ? »

Décommentez la partie SSL dans le fichier server.xml de votre Tomcat (/TOMCAT_HOME/conf/server/xml)

<!--
   <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"  
   maxThreads="150" scheme="https" secure="true"                clientAuth="false" sslProtocol="TLS" />
-->
(Enlevez les <!-- et -->)

Exporter le certificat pour l’installer sur votre autre Tomcat

keytool -export -alias tomcat -file servercas.crt

Sur le deuxième serveur :

keytool -import -file servercas.crt -keystore $JAVA_HOME/jre/lib/security/cacerts -alias tomcat

Démarrer les tomcats (bin/startup.sh) et vérifier qu’ils sont bien accessibles sur le port 8443 en https.

- Installer Maven 2
Rendez vous sur le site du projet Maven et téléchargez la version 2.2.1 (la version 3 n’est pas encore recommandé pour CAS)

wget http://mirrors.ircam.fr/pub/apache/maven/maven-2/2.2.1/binaries/apache-maven-2.2.1-bin.tar.gz
tar xzvf apache-maven-2.2.1-bin.tar.gz
ln -s apache-maven-2.2.1 maven2

Ajouter l’emplacement des binaires Maven2 à votre PATH (et votre JAVA_HOME si cela n’a pas déjà été fait)

# export PATH=/opt/maven2/bin:$PATH
#export JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.26/jre

(OUI ! je sais, j’ai une vieille version de JAVA toute pourrie sur mes serveurs de tests :D donc je vous laisse mettre à jour la votre)

Vérifier que Maven est opérationnel :

# mvn --version
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_26
Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre
Default locale: fr_FR, platform encoding: ISO-8859-15
OS name: "linux" version: "2.6.26-2-686" arch: "i386" Family: "unix"

(OUI ! Je sais, j’ai un kernel tout moisi. Ca suffit à la fin !)

- Installer CAS

Nous allons utiliser la version communautaire de CAS, conçu par l’université de Yale et maintenu désormais par le projet Jasig qui réunit diverses écoles.
Téléchargez la dernière version a ce jour (3.5.2) :
http://www.jasig.org/cas/download
Une fois le fichier détarré/dégzippé, créer votre propre environnement de travail :

cd /opt/cas-server-3.5.2
mkdir cas-guiguiabloc
cd cas-guiguiabloc

Dans le répertoire de votre projet, nous allons créer le fichier « de configuration » de CAS. Il contient les appels vers les différentes dépendances disponibles.
Ce fichier s’appelle pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd ">
    <modelVersion>4.0.0</modelVersion>
    <groupId>fr.guiguiabloc.cas</groupId>
    <artifactId>cas-guiguiabloc</artifactId>
    <packaging>war</packaging>
    <version>1.1-SNAPSHOT</version>
 
    <build>
        <plugins>
            <plugin>
                 <artifactId>maven-war-plugin</artifactId>
                             <configuration>
                                 <warName>cas</warName>
                             </configuration>
                        </plugin>
        </plugins>
    </build>
 
    <dependencies>
        <dependency>
            <groupId>org.jasig.cas</groupId>
            <artifactId>cas-server-webapp</artifactId>
            <version>${cas.version}</version>
            <type>war</type>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.jasig.cas</groupId>
            <artifactId>cas-server-support-generic</artifactId>
            <version>${cas.version}</version>
            <type>jar</type>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.jasig.cas</groupId>
            <artifactId>cas-server-integration-memcached</artifactId>
            <version>${cas.version}</version>
            <type>jar</type>
        </dependency>
    </dependencies>
 
    <properties>
        <cas.version>3.5.2</cas.version>
    </properties>
 
        <repositories>
             <repository>
                  <id>ja-sig</id>
                  <url>http://oss.sonatype.org/content/repositories/releases/ </url>
             </repository>
        </repositories>
</project>

Je ne détaillerais pas tout, la documentation de CAS est assez explicite, mais dans notre exemple, nous allons utiliser une webapp générique, avec le support memcached et que Maven2 puisse utiliser les dépots publics de Jasig.

C’est parti pour une première compilation !

cd /opt/cas-server-3.5.2/cas-guiguiabloc
mvn clean package

Laisser le temps a Maven de télécharger Internet et le résultat devrait apparaitre

[INFO] [war:war {execution: default-war}]
[INFO] Packaging webapp
[INFO] Assembling webapp[cas-guiguiabloc] in [/opt/cas-server-3.5.2/cas-guiguiabloc/target/cas-guiguiabloc-1.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Processing overlay[ id org.jasig.cas:cas-server-webapp]
[INFO] Webapp assembled in[4636 msecs]
[INFO] Building war: /opt/cas-server-3.5.2/cas-guiguiabloc/target/cas.war
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 minutes 36 seconds
[INFO] Finished at: Mon Nov 11 00:42:10 CET 2013
[INFO] Final Memory: 18M/44M
[INFO] ------------------------------------------------------------------------

En l’état, vous avez donc maintenant un joli cas.war dans le répertoire target de votre projet que vous pouvez déposer dans votre tomcat/webapps/.
Cela vous permet déjà de vérifier que tout fonctionne comme il se doit sur https://serveur:8443/cas

Maintenant, peaufinons tout cela :

serveur:/opt/cas-server-3.5.2/cas-guiguiabloc# mkdir -p src/main/webapp/WEB-INF

Dans ce répertoire WEB-INF, nous allons y copier le fichier :
/opt/cas-server-3.5.2/cas-guiguiabloc/target/cas-guiguiabloc-1.0-SNAPSHOT/WEB-INF/deployerConfigContext.xml
et le modifier pour inclure :
- l’authentification locale par un user/mot de passe
- le support de memcached

Pour l’authentification locale, ajouter la section suivante :

<bean class="org.jasig.cas.adaptors.generic.AcceptUsersAuthenticationHandler">
 <property name="users">
   <map>
   <entry>
   <key>
                                                                <value>guiguiabloc</value>
   </key>
                                                                <value>1234</value>
   </entry>
   </map>
   </property>
   </bean>

 

Ici nous créons un simple utilisateur « guiguiabloc » avec le mot de passe 1234.
En prod, vous pourrez utiliser un autre système d’authentification bien sur (LDAP etc…)

Pour le support memcached, voici la section a ajouter :

bean id="ticketRegistry" class="org.jasig.cas.ticket.registry.MemCacheTicketRegistry">
  <constructor-arg index="0" ref="memcachedClient" />
  <constructor-arg index="1" value="21600" />
  <constructor-arg index="2" value="300" />
</bean>
<bean id="memcachedClient" class="net.spy.memcached.spring.MemcachedClientFactoryBean"
      p:servers="127.0.0.1:11211"
      p:protocol="TEXT"
      p:locatorType="ARRAY_MOD"
      p:failureMode="Cancel"
      p:transcoder-ref="kryoTranscoder">
</bean>
<bean id="kryoTranscoder"
      class="org.jasig.cas.ticket.registry.support.kryo.KryoTranscoder"
      init-method="initialize">
  <constructor-arg index="0" value="8192" />
</bean>

Bien sur je ne peux que vous invitez a lire la documentation officielle :)
https://wiki.jasig.org/display/CASUM/MemcacheTicketRegistry

A toute fin utile, vous trouverez ICI le fichier deployerConfigContext.xml que j’ai utilisé.

On recompile le WAR dans cas-guiguiabloc (mvn clean package) et on le copie dans nos webapps Tomcat (après avoir supprimé l’ancien répertoire cas)

Démarrez vos Tomcat et authentifiez vous sur la mire CAS, Tadam !
Si tout se passe bien, la connexion réussi et vous devez avoir un cookie CAS :

Name	CASTGC
Value	TGT-3-mcWQGjaB1bSHNScWUJbq2EyLsLm9vysjl6lIkaXfuN4TMFVTow-cas01.example.org
Domaine (host)	cas.guiguiabloc.fr
Chemin d'accès (path)	/cas/
Sécurisé	oui
Expire le	À la fin de la session

Et magie, sur vos deux memcached, vous allez retrouver votre ticket en recherchant la valeur du cookie en tant que clé :

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
get TGT-3-mcWQGjaB1bSHNScWUJbq2EyLsLm9vysjl6lIkaXfuN4TMFVTow-cas01.example.org
VALUE TGT-3-mcWQGjaB1bSHNScWUJbq2EyLsLm9vysjl6lIkaXfuN4TMFVTow-cas01.example.org 0 386
BH .
guiguiablocuiduidgroupMembershipgroupMembershipeduPersonAffiliationeduPersonAffiliationauthenticationMethod?org.jasig.cas.adaptors.generic.AcceptUsersAuthenticationHandlerÞÉP!лôîJTGT-3-mcWQGjaB1bSHNScWUJbq2EyLsLm9vysjl6lIkaXfuN4TMFVTow-cas01.example.orgäÉPÞÉP+ST-6-iHWaAvdowI0WGE1du76P-cas01.example.org
END

Vos deux serveurs CAS se partagent la même source d’information de tickets valides :D

J’espère que cette petite approche de CAS vous aura émoustillé. Bien entendu, il existe plein d’options de compilation et de configuration qui vous permettrons d’avoir un/des serveur(s) CAS aux petits oignons.

Si vous souhaitez maintenant intégrer votre serveur web à CAS (avec Apache par exemple), vous trouverez un très bon tuto ici :
https://ucdavis.jira.com/wiki/display/IETP/mod_auth_cas
Pour info, la méthode la plus facile pour compiler le mod_auth_cas avec apxs2 est :

apxs2 -i -lssl -lcurl -c mod_auth_cas.c cas_saml_attr.c

Amusez-vous bien :D

Classé dans architecture, linux, sécurité | Taggé , , | 8 Commentaires
nov 10

OVH, vers un Adsl neutre

Je fais partie de cette génération qui est née avec l’informatique.

Quand je dis « informatique », je ne parle évidemment pas de Facebook, Google, Twitter ou YouPorn

J’ai eu cette chance immense (du moins je le pense), de découvrir les premiers ordinateurs personnels, de m’amuser à me connecter aux premiers réseaux (ah le temps des BBS et de Transpac :p), et surtout de voir naître Internet et d’être parmi les premiers a m’y raccorder.

Durant ces années passées, j’ai pu voir fleurir les offres d’accès, m’enthousiasmer des vitesses de connexions de plus en plus rapides et du nombre de personnes sur le « réseau des réseaux ».

Je fais partie de cette génération de geek que la nouvelle vague a qualifiée de « Barbus », des vieux schnoques qui ont connu VAX et qui pestent quand il s’agit de trouver « telnet » sous windows Seven (quand on les forcent à prendre la main dessus). Mais aussi et surtout, de cette génération pour qui le partage de connaissances et d’informations est un cheval de bataille et un acquis profond et pour qui l’aide à autrui est une chose complètement naturelle (mais qui s’est vite rendu compte dernièrement que l’aide s’est transformée en assistanat, à son plus grand désarroi).

Cette petite introduction pour tenter/essayer d’expliquer la suite.

Durant ces longues années d’internaute, j’ai pu tester un grand nombre de FAI et de technologies et vers le début des années 2000, mon choix s’est arrêté sur Free.

Free, parce qu’a cette époque et jusqu’à assez récemment, j’ai toujours cru qu’il était LE FAI du Geek. Innovant, bousculant les préjugés, s’empêchant de rentrer dans le moule et m’offrant un accès sans contrainte au réseau Internet (oui, c’était avant…).

Car force est de constater qu’au fil des dernières années, cette attitude a complètement changé.
Je peux en parler plus facilement car j’ai donné beaucoup pour Free. J’étais membre et modérateur de l’ADUF (l’Association des Utilisateurs Free) depuis 2005, j’ai été « helpeur » sur IRC sur les canaux dédiés à Free, allant jusqu’à être aujourd’hui IRCop du réseau Europnet (sur lequel irc.free.fr est membre), et j’ai discuté avec des tas de clients, techniciens ou super-techniciens de ce FAI (voir plus ;) ).
Autant vous dire que le monde « Free », je le connais quand même un peu…

Je ne referais pas l’actualité de Free, vous la connaissez autant que moi.
Au bout d’un moment, quand on a l’esprit de transparence, cela commence a faire bouillir légèrement.

Depuis le début, j’ai toujours reproché à Free son manque de transparence vis à vis de ses clients  et, dernièrement,  la « prise d’otage » de ses clients pour influencer un plus gros que lui a été la cerise qui a fait déborder le gâteau.

A côté de cela, j’ai aussi vu naître OVH et surtout son geek de « guide », Octave Klaba.
J’avais déjà parlé de l’interet que je portais à OVH dans de précédents billets,

S’il y a bien une chose qu’on ne peut reprocher à OVH, c’est son manque de transparence. Tout y est. Le moindre incident est tout de suite rapporté aux clients (et à tous d’ailleurs) via la page Travaux.
L’accès à l’état du reseau en temps réel, l’état des serveurs dédiés dans les Datacenters, la latence des équipements d’infrastructures etc…
Cela peut paraître futile a certains, mais personnellement, je connais peu de FAI/Hébergeur qui donnent accès ainsi a leurs graphes…

Ajouter à cela un DG/C(T|E)O présent sur Twitter, les forums et accessible par email (sérieusement vous avez vu ca ailleurs ???) et qui répond (ah bah oui, Mr Xavier Niel, c’est pas tout d’être sur les réseaux sociaux, d’avoir une adresse email, faut répondre aussi..).

Je ne fais pas de prosélytisme pour OVH, mais il faut bien avouer qu’ils forcent le respect. De plus, et ce n’est pas une chose qu’un geek prend a la légère, au bout du fil de la hotline, il y a des gens qui parlent et comprennent ce que vous dites ! (si si :) )

Pour avoir tester 3 ou 4 fois, en désespoir de cause, la hotline de Free, j’ai été sidéré de l’incompétence technique de mes interlocuteurs (je suis navré, mais quand un sysadmin ou un admin résal appelle une hotline, se présente en tant que tel et demande a ce que l’on passe directement a la partie technique et pas au « vous etes sous windows ? Mac ?…), on s’attend a un peu de répondant plutot que « cliquez sur démarrer/executer » quand on parle de routage ou d’OpenBSD…)
A l’inverse, j’ai très peu appelé la hotline OVH mais quand je parle de DRBD a mon interlocuteur, il me demande plutot la version du module utilisée… On est décidement pas dans la même cour…

J’extrapole bien évidemment, mais il faut dire les choses telles qu’elles sont, chez OVH, j’ai eu des sysadmins au bout du fil qui parlait la même langue que moi, et rien que ça, ça donne du baume au coeur (en plus de régler un incident plus vite…)

Bien sûr, il y a aussi des côtés négatifs. Que je te fasse des mises en prod en pleine journée, que je te mette une mise à jour d’un ios Cisco sur les routeurs à l’arrache, que je me plante dans l’ospf…  Bref, la vie d’un client OVH n’est pas des plus faciles tout les jours, mais bon, j’ai assimilé cela depuis le début, c’est une boite de geeks, administrée par des geeks et ils font un peu ce qu’ils veulent, quand ils veulent, avec les aléas qui en dépendent (en même temps, ils avouent rapidement quand ils ont fait une bourde…).

Tout ce bla-bla donc pour dire que lorsqu’OVH a décider de se lancer en tant que FAI, j’ai ouvert les deux yeux et j’ai suivi les retours de près.
Quand en plus, Octave Klaba commence a remuer tout le monde en disant que son métier c’est le réseau et pas autre chose, qu’un FAI doit offrir un ADSL neutre sans bridage, filtrage et tout faire pour offrir l’accès au réseau des réseaux pour lequel paye son client, la je me dis, mon petit Guigui (oui j’aime me caresser tendrement dans le sens du poil le soir au coin du feu), tu dois quitter Free pour prendre ton Adsl chez lui.

Je n’encense pas Octave Klaba, j’ai même eu quelques désaccords avec lui, mais le bonhomme est ce qu’il est, franc du collier, transparent (même sur des aspects difficiles de sa vie privée), et avec ce caractère bien trempé qu’a tout barbu de ma génération.

Alors j’ai décider lui faire confiance une nouvelle fois (car oui, mes serveurs dédiés sont chez OVH déjà) pour mon accès ADSL perso.

J’y suis allé avec la même inquiétude que lorsque j’ai quitter France Telecom pour Free il y plus de 10 ans (pour l’ADSL), et j’osais espérer que y prendre la même satisfaction.

Aujourd’hui cela va faire 8 mois que mon ADSL est géré par OVH.

Et j’en tire un bilan plus que positif.
Tout d’abord une synchro plus haute qu’avec Free (non dégroupé):

xDSL Type:                               ADSL2+
Bandwidth (Down/Up – kbit/s):            23326/1020

Un débit constant quand je télécharge (comprendre ramener une simple image iso un dimanche après midi). Alors qu’avant mon débit faisait le yoyo entre 12Ko/sec et 1,9Mo/sec, aujourd’hui il reste stable a 2,1Mo/sec.

Un modem qui m’a plus amusé que la freebox (voui je sais, c’est totalement subjectif de faire joujou avec telnet).

Une téléphonie parfaite, et surtout, un accès aux services Google sans faille (qui a dis youtube ?…).

Alors mon accès est-il vraiment neutre ? Concernant les débits, oui, je n’ai pas vu/ressenti une quelconque QoS sur mon accès.
Concernant mes données qui transitent ? Difficile de le savoir (après tout, OVH analyse les emails sortants des serveurs de ses clients), mais j’ai la naïveté de le croire.
En tout cas, après ses 8 mois d’utilisation, j’avoue ne pas regretter mon choix.

Classé dans geekerie | 15 Commentaires
juin 26

Le détecteur de mouvement comme système d’alarme

Aujourd’hui un petit billet invité que l’on m’a proposé et le sujet étant intéressant, je vous le fais partager.

Les alarmes anti-intrusion sont devenues un équipement standard dans les magasins et entreprises, et elles sont de plus en plus courantes dans les maisons des particuliers. Si vous avez déjà cherché un dispositif de surveillance pour votre maison, vous saurez qu’il y a une grande variété d’options disponibles, comme les détecteurs d’ouverture et les systèmes de télésurveillance.

Pour détecter un intrus qui a déjà réussi à pénétrer dans une maison, le meilleur système est le détecteur de mouvement. Les détecteurs de mouvement basiques sont assez courants de nos jours. Vous en voyez sans doute tous les jours quand vous franchissez une porte qui s’ouvre automatiquement, par exemple. Il existe plusieurs sortes de détecteurs :

Système infrarouge passif. Photo par Jack LaRosa.

  • Les systèmes de sécurité les plus avancés incluent le détecteur infrarouge passif , qui perçoit l’énergie infrarouge émise par la chaleur d’un corps. Le capteur va détecter une augmentation importante de l’énergie infrarouge lorsqu’une personne entre dans son champ de vision. Comme l’énergie thermique dans une zone donnée est en constante fluctuation, les détecteurs sont conçus pour déclencher l’alarme seulement quand les niveaux de rayonnement infrarouge changent très rapidement. Pour qu’un capteur puisse détecter un être humain, vous devez le rendre sensible à la température du corps humain. Les humains ont une température de peau d’environ 33ºC et émettent de l’énergie infrarouge d’une longueur d’onde comprise entre 9 et 10 micromètres. Par conséquent, les capteurs sont généralement sensibles dans la gamme de 8 à 12 micromètres. Si vous êtes bricoleur, vous pouvez fabriquer votre propre détecteur avec Arduino, une résistance et un capteur infrarouge vendu par rs components.
  • Il existe un autre type de design plus simple, le capteur à cellule photo-électrique. C’est le genre de dispositif que vous pouvez voir dans un magasin ou en entrant chez le médecin. Au moment où une personne franchit la porte du magasin ou du bureau, le détecteur de mouvement émet une sonnerie ou une cloche pour avertir les employés. Lorsque ce genre de détecteur est utilisé comme alarme domestique, le faisceau est dirigé vers le détecteur de lumière, à travers un couloir ou passage à l’intérieur de votre maison. Quand quelqu’un se promène entre la source lumineuse et le capteur, le trajet du faisceau est brièvement bloqué. Le capteur enregistre une baisse du niveau d’éclairage et envoie un signal au boitier de commande.
  • Un système d’ouverture automatique de porte coulissante est un exemple de détecteur de mouvement basé sur un radar. Un boitier placé au-dessus de la porte émet des salves d’ondes radio (ou ondes ultrasonores), puis attend que l’énergie réfléchie rebondisse. S’il n’y a personne en face de la porte, l’énergie radio va rebondir de la même manière. Mais si quelqu’un pénètre dans la zone, le faisceau de réflexion est perturbé. Lorsque cela se produit, le capteur envoie un signal au boitier de commande et la porte s’ouvre. Dans un système de sécurité, le capteur envoie un signal d’alarme lorsque le faisceau de réflexion dans une pièce est perturbé.

Tous ces modèles de détecteurs de mouvement peuvent être utilisés conjointement dans une maison de manière à offrir une couverture complète. Dans un système d’alarme typique, le boîtier de commande ne déclenchera pas la sonnette d’alarme dès que les détecteurs de mouvement captent un changement. Il y a toujours un court délai pour donner le temps au propriétaire d’entrer un code de sécurité qui éteint le système.

Classé dans Non classé | 5 Commentaires
juin 19

Domotique, le choix d’une vulgarisation erronée

La semaine des examens du BAC commençant par ses fameuses épreuves de philosophie (matière qui offre des débouchés forts intéressants ), ce billet sera plus d’humeur que technique.

D’ailleurs, il semblerait que cette semaine soit source à réflexion ;)
Donc deux bonnes lectures a ajouter à votre escarcelle :

http://blog.domadoo.fr/index.php/domotique/1271-quest-ce-que-la-domotique
http://www.domotique-info.fr/2013/06/domotique-interoperabilite-m2m-api-socket-ip/

Nous le savons tous, la domotique c’est pour demain (oui, cela fait des années que c’est demain).
Heureusement, ce demain se dessine de plus en plus grâce tout d’abord à un engouement porté par des passionnés de plus en plus nombreux qui, magie du Nain Ternet aidant, le relaie sur des blogs et forums.
Par des médias qui commencent doucement à en parler sur des chaînes tout public, et surtout par des constructeurs/distributeurs qui se sont dit que le créneau pouvait être porteur et ont donc commencé a offrir des offres packagées permettant au tout venant de s’initier au bienfait de la domotique chez soi.

Tout cela est bien, on ne peut pas dire le contraire. L’idée fait son chemin dans la tête de plus en plus de personnes pour qui la domotique n’était qu’une vaste idée de geeks technophiles accros aux dernières nouveautés et pour lesquels le fait d’allumer une lampe avec son pc par une url dans son navigateur était aussi excitant qu’un ping vers un serveur externe à moins de 10ms.

Oui mais pour ce commun des mortels, pour qui un pc est sous windows et un accès à internet est une boite noire (ou blanche ou translucide, bref un tupperware qui prend la poussière sur une étagère) qu’on branche sur la prise du téléphone, la domotique reste un gadget et je le comprend.
Après tout, allumer la lampe du salon avec son smartphone, c’est très con. Si, si, je vous assure.

 

Alors pour vulgariser la domotique et la rendre attrayante auprès du grand public, les constructeurs/distributeurs ont décidé de mettre en oeuvre une stratégie mercantile apte à rentabiliser les heures passées par les équipes de R&D (Rapporte de l’argent et Démerde toi pour que cela ne me coûte rien).
Un environnement domotique comprend des équipements de confort (télécommande, prise commandée, sonde de température, douille commandée, volets roulants ou portails automatisés etc..) et des équipements de sécurité (détecteur de mouvement, d’ouverture, de fuite d’eau, de gaz ou de fumée ).

A partir de ce concept assez basique,  les chefs de projets/commerciaux se sont dit :
- « Comment qu’on va vendre ça a Mme Michu ? On va quand même pas lui dire qu’elle peut gérer les prises électriques de sa maison ! ».
- « Non mais attends Roger ! On va vendre ça comme une alarme apaschère !!! »
- « Génial Brandon ! Vendons leur ça ! »
Car oui, l’idée absolument géniale qui va révolutionner le monde et amener la domotique chez les gens, c’est de leur parler « sécurité » !
Après tout, c’est un constat évident, les français ont un sentiment d’insécurité et on nous le rabache sans cesse.

Pain béni pour ses constructeurs de solution domotique et des équipement de « sécurité » qui en font partie, le leitmotiv commercial devenu bien rodé qu’ils ont décidé de nous asséner est la possibilité justement de détecter et prévenir de toutes intrusions à domicile.
Que je te vende des caméras ip/wifi, des possibilités de visionner les flux sur son smartphone, d’être prévenu par SMS d’une intrusion chez moi et que sais-je encore, les solutions domotiques de nos chers constructeurs/fabricants se sont rapidement transformées en alarme à domicile, moins cher qu’une vrai alarme (après tout je m’en fous qu’elle soit neutralisable en quelques secondes ou ne résiste pas à un coup de marteau ou un évier rempli d’eau), elle est devenu la solution de protection de sa maison a moindre coût.

Le plus gênant, c’est que cette stratégie a plutôt bien marché puisque même certains constructeurs d’alarmes ont décider d’intégrer des possibilités de controle de prise électrique sur leurs solutions
Car peu de particulier disposent d’une alarme à domicile (étonnant non ?) et les fabricants d’alarmes qui ont difficilement réussi à promouvoir leur solution au sein des foyers se sont dit qu’ils avaient peut-être louper le coche, malgré les sommes engagées dans la certification de leur produits à des attaques de tout genre, non, ce qui semble intéresser le client lambda, c’est que son smartphone sonne quand quelqu’un rentre chez lui, au détriment de la résistance du produit d’alarme et de sa capacité à éloigner un intrus (ceux qui ont entendu la sirène d’alarme d’une blyssbox me comprendront…).
Et bien entendu, les assureurs suivent le pas tracé dans le sable du business.

Dans les forums ou discussions sur la domotique, c’est d’ailleurs l’une des premières préoccupations des « nouveaux » qui s’essayent à ce concept. Loin de privilégier une autre piste, les premières questions portent quasiment toujours sur les équipements de sécurité, les caméras et les sirènes.

La domotique se trouvent donc t-elle condamnée à être confiner comme une alarme low-cost au détriment de ses autres possibilités parce que le choix stratégique commercial des principaux constructeurs/fabricants est d’en promouvoir le côté sécuritaire ?
Peut-être, et c’est bien dommage, car c’est un mauvais choix et sûrement pas la meilleure façon de vulgariser la domotique, de la rendre attrayante et de lui rendre ce pour quoi elle est a été conçue.

 

Ne nous méprenons pas. Je ne dénigre aucunement les capacités de détections d’un équipement domotique et la facilité de sa mise en oeuvre pour être alerter d’une effraction chez soi.
Mais n’est-il pas particulièrement réducteur d’en faire le cheval de bataille de la domotique ?
Est-ce par cette voie (voix s’appliquant aussi ;) ) que l’on fera comprendre la domotique aux gens ?
Non. Définitivement non.

La domotique a plusieurs rôles qui sont complètement occultés par cette approche sécuritaire.

  • Un rôle d’économie d’énergie à son domicile.
    La gestion de son chauffage beaucoup plus finement que ne le ferait n’importe quel thermostat d’ambiance. La coupure automatique de lampes restaient sournoisement allumées après avoir quitter une pièce. L’extinction d’appareil électrique qui n’ont pas vocation a être alimenter en permanence (et par la même la sécurité électrique d’une, par exemple, cafetière laisser en marche…).
  • Un rôle d’information et de prise en compte des données de son domicile. Température de chaque pièce (et par la même d’une isolation peut être déficiente a un endroit). Consommmation d’eau (et détection d’une surconsommation signe d’une fuite discrète). Consommation énergétique (électricité, gaz, fioul) en temps quasi réel et la prise de conscience subjacente des postes de dépenses.
  • Une centralisation de ses multiples données  (senseurs, équipements et vêtements connectés…) qui permettront un stockage et une analyse fines de toutes ses informations pour une traitement « a posteriori » (http://www.cityzensciences.fr/ sera a suivre dans les mois qui viennent)
  • Une automatisation des habitudes qui peuvent naturellement être délégués à un système domotique, avec un soupçon de cognitivité qui pourrait vous surprendre.

Enfin, et surtout, la force de la domotique pour laquelle le discours ne se veut malheureusement pas assez convaincant : les scénarios.

Car la puissance de la domotique vient justement de l’interopérabilité entre tout ce qui « fait » notre vie à la maison. Le fameux IFTTT (If Then Then That (si ça, alors fait ça).

- « S’il y a du vent supérieur à telle vitesse alors ferme les volets »
- « S’il est plus de 23h et que je sors de ma chambre pour aller aux toilettes, allume la lumière du couloir et des wc qu’a 20% de sa puissance »
- « Si ma grand-mère, chez elle, n’a pas ouvert sa boite de médicaments au repas du midi et/ou qu’elle n’a pas allumer un équipement électrique/ouvert un tiroir/frigidaire/placard depuis plus de 3h, alerte moi »
- « Si je suis en vacances alors n’ouvre pas les volets automatiquement à 7h, ne met pas mon réveil en route et coupe mon téléphone jusqu’à ce que j’ouvre mon frigo »
- « S’il fait beau demain, fait moi penser à acheter du charbon de bois pour le barbecue et profites en pour regarder si 2-3 potes seraient partant pour passer manger une merguez autour d’un bon bordeaux dont, bien sûr, tu auras vérifier que sa vieillesse se sera dérouler correctement en supervisant la température, la luminosité et l’hygrométrie de ma cave a vin ».
Etc, etc…

Ce manque de communication sur la possibilité de ces scénarios, sur des exemples de mise en place, de démonstration dans la vie quotidienne est un manque cruel des capacités réelles et avérées de la domotique en 2013.

Cantonner la domotique a un simple rôle de sécurité est dégradant au vue des possibilités du concept.
Rendre abordable, facile, compréhensible la création et la gestion de divers scénarios devrait être aussi simple que la mise en place de 3 détecteurs de mouvements couplés à une alerte SMS que se targue de vendre nos chers constructeurs/distributeurs.

C’est à nous tous, utilisateurs, contributeurs, passionnés de domotique de relayer ses possibilités auprès du public et de ne pas laisser quelques entreprises commerciales vulgariser un concept qui n’est vraiment pas le bon.

A ce genre de jeu, certains s’étaient essayer avec succès dans les années 80/90 avant que les passionnés et vrais utilisateurs en reprennent le contrôle et clame haut et fort qu’un autre chemin était possible et sûrement le mieux. Cela s’appelait, les débuts de l’informatique.

Classé dans domotique | Taggé , , , | 14 Commentaires