Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

Introduction

Esup-nfc-tag-server permettant d'utiliser comme lecteur/borne de badge NFC :

- un smartphone Android : EsupNfcTagDroid
- ou ordinateur + lecteur usb NFC : EsupNFCTagDesktop
- ou encore éventuellement un Arduino : EsupNfcTagArduino

Ce projet vise à permettre et faciliter le développement de services autour des cartes NFC dites "multiservice". Il propose une architecture standardisée et connectée autour du badgeage d'une carte présentant un identifiant (CSN ou identifiant codé en Desfire AES) correspondant à une carte valide d'un individu connu du système d'information.

Esup-nfc-tag-server permet d'utiliser comme lecteur/borne de badge NFC :

Image Added

L'application Esup-nfc-tag-server L'application EsupNfcTagServer, elle est développée en Spring (ROO) et tourne sur Tomcat.

Sommaire

Installation

Pré-requis

  • Postgresql 9 : le mieux est de l'installer via le système de paquets de votre linux.
  • Tomcat (Tomcat 8)
  • Git

Configuration Apache Shibboleth

L'authentification repose sur Shibboleth. Apache doit être configuré pour faire du mod_shib.

Une fois le SP Shibboleth et Apache configurés usuellement (voir : https://services.renater.fr/federation/docs/installation/sp), il faut sécuriser /manager et /nfc en ajoutant ceci à la conf apache (à adapter cependant en fonction des versions d'Apache et mod_shib) :

Bloc de code
languagexml
<Location /manager>
AuthType shibboleth
ShibRequestSetting requireSession 1
require shib-session
ShibUseHeaders On
</Location>
<Location /nfc>
AuthType shibboleth
ShibRequestSetting requireSession 1
require shib-session
ShibUseHeaders On
</Location>

 

Configuration PostgreSQL

  • pg_hba.conf : ajout de
Bloc de code
languagebash
host all all 127.0.0.1/32 password

...

Bloc de code
languagebash
create database esupnfctag;
create USER esupnfctag with password 'esup';
grant ALL ON DATABASE esupnfctag to esupnfctag;

 

Paramétrage mémoire JVM :

Pensez à paramétrer les espaces mémoire JVM :

Bloc de code
languagebash
export JAVA_OPTS="-Xms1024m -Xmx1024m -XX:MaxPermSize=256m"

Pour maven :

Bloc de code
languagebash
export MAVEN_OPTS="-Xms1024m -Xmx1024m -XX:MaxPermSize=256m"

Sources

Bloc de code
languagebash
git clone https://github.com/EsupPortail/esup-nfc-tag-server

Configurations

Au niveau de l'application, les fichiers de configuration à modifier sont les suivants : 

  • src/main/webapp/META-INF/context.xml pour le paramétrage des connexions à la base de données
  • src/main/resources/logback.xml pour la configuration des logs
  • src/main/resources/META-INF/spring/applicationContext-custom.xml pour le paramétrage des services que doit intégrer l'application EsupNfcTagServer ; c'est le fichier de paramétrage important de l'application et ce sont ces paramétrages qui sont décrits dans ce qui suit.

3 services distincts correspondent à l'implémentation DES API définis dans org.esupportail.nfctag.service.api :

  • NfcAuthConfig
  • TagIdCheckApi
  • AppliExtApi

NfcAuthConfig

NfcAuthConfig correspond à la façon dont la carte est authentifiée/identifiée.

Les 2 implémentations proposées actuellement sont l'authentification par lecture du simple CSN (Card Serial Number) d'une part, et l'authentification par Mifare Desfire AES d'autre part. Ces implémentations sont très liées à EsupNfcTagDroid (ie l'APK, la partie mobile) aussi une nouvelle implémentation d'un NfcAuthConfig nécessitera(it) sans doute la modification de EsupNfcTagDroid.

Implémentations actuellement disponibles :

  • CsnAuthConfig : implémentation de la lecture csn

  • DesfireAuthConfig : implémentation de la récupération d'un identifiant issu de la lecture d'un fichier chiffré Mifare Desfire AES

Les 2 autres services TagIdCheckApi et AppliExtApi sont indépendants quant à eux de EsupNfcTagDroid et de nouvelles implémentations de ces services peuvent être envisagées, même si le recours à leurs implémentations sous forme de Web Service REST doit être naturellement privilégiées.

TagIdCheckApi

TagIdCheckApi correspond à la façon dont on récupère l'identification d'un individu depuis un identifiant de carte (identifiant CSN ou issu de la lecture d'un fichier Desfire). Cette identification de l'individu consiste en son eppn, nom, prénom.

Implémentations actuellement disponibles :

  • TagIdCheckRestWs : recupération des identifants via webservices REST

  • TagIdCheckSql : recupération des identifants via une base de données

  • TagIdCheckLdap : recupération des identifants via un annuaire LDAP

AppliExtApi

AppliExtApi correspond à l'application cible finale du badgeage :

  • il retourne d'une part les "locations" sur lesquels peut éventuellement badger l'utilisateur qui se trouve derrière le téléphone : on utilise l'eppn (issu de l'authentification shibboleth) pour identifier cette personne.
  • d'autre part, il propose des méthodes correspondant au badgeage sur la "location" de la personne détentrice de la carte ;  on utilise ici l'eppn (issu ici du tagIdCheckApi lui même issu du csn ou identifiant desfire issu du nfcAuthConfig) pour identifier cette personne détentrice de la carte.

Implémentations actuellement disponibles :

  • AppliExtDummy : permet de tester l'application, elle renvoit un lieu (Dummy Location)

  • AppliExtRestWs : s'appuie sur des webservices REST pour fournir les lieux et generer les badgeages

 

Les services utilisables avec la carte peuvent être configurés dans le fichier src/main/resources/META-INF/spring/applicationContext-custom.xml.

Exemples

AppliExt

Bloc de code
<bean id="esupSgcExtApi" class="org.esupportail.nfctag.service.api.impl.AppliExtRestWs">
	<property name="isTagableUrl" value="https://esup-sgc.univ-ville.fr/wsrest/nfc/isTagable"/>
	<property name="validateTagUrl" value="https://esup-sgc.univ-ville.fr/wsrest/nfc/validateTag"/>
	<property name="locationsUrl" value="https://esup-sgc.univ-ville.fr/wsrest/nfc/getLocations"/>
<!--   	<property name="displayUrl" value="https://esup-sgc.univ-ville.fr/wsrest/nfc/verso"/> -->
	<property name="description" value="Web Service Carte Culture"/>
	<property name="backgroundColor" value="rgb(121, 119, 116)"/>
	<property name="header" value="https://carte-culture.univ-rouen.fr/resources/images/logo.jpg"/>
</bean>
  • isTagable : adresse du webservice permettant de contrôler si un badge est valide

  • validateTagUrl : adresse du webservice permettant de confirmer un badgeage

  • locationsUrl : adresse du webservice retournant la liste des « lieux » disponible pour l'utilisateur courant (utilisateur du lecteur de carte)

  • displayUrl (non requis) : adresse du webservice permettant l'affichage d'information après la validation du tag

TagIdCheck

Bloc de code
<bean id="tagIdCheckApiCarteCulture" class="org.esupportail.nfctag.service.api.impl.TagIdCheckRestWs">
	<property name="tagIdCheckUrl" value="https://carte-culture.univ-rouen.fr/nfc-ws/tagIdCheck"/>
	<property name="description" value="via Carte Culture"/>
</bean>
  • tagIdCheckUrl : adresse du webservice permettant de retrouver une personne en fonction de sont identifiant de carte (csn ou idp2s)

 
Pour tester l'application rapidement, ajouter ce tagIdCheck (qui retournera toujours un résultat):
 
Bloc de code
<bean id="tagIdCheckApiDummy" class="org.esupportail.nfctag.service.api.impl.TagIdCheckDummyWs">
	<property name="description" value="TagIdCheckDummy"/>
</bean>

 

AuthConfig

Pour une configuration d'authentification de carte par CSN :

Bloc de code
<bean id="csnAuthConfig" class="org.esupportail.nfctag.service.api.impl.CsnAuthConfig">
<property name="description" value="Authentification CSN"/>
</bean>

Pour une configuration d'authentification de carte par Mifare Desfire AES :

Bloc de code
<bean id="desfireAuthConfig" class="org.esupportail.nfctag.service.api.impl.DesfireAuthConfig">
	<property name="desfireKeyNumber" value="01"/>
	<property name="desfireAppId" value="A123F1"/>
	<property name="desfireAppName" value="test-app"/>
	<property name="readFileCommand" value="90BD0000070000000016000000"/>
	<property name="desfireKey" value="/var/local/key"/>
	<property name="description" value="Authentification DESFIRE"/>
</bean>

Base de données

src/main/resources/META-INF/persistence.xml

afin que les tables soient préalablement créées, notamment la table big_file sur lequel on souhaite mettre le trigger lo_manage, vous devez démarrer l'application une fois ; en n'oubliant pas ensuite, pour ne pas écraser la base au redémarrage, de modifier src/main/resources/META-INF/persistence.xml : create-> update - cf ci-dessous.

src/main/resources/META-INF/spring/database.properties

database.driverClassName=org.postgresql.Driver

database.url=jdbc\:postgresql\://localhost\:5432/esupnfctag

database.username=esupnfctag

database.password=esup

Logs

logbacksrc/main/resources.xml

modifier le fichier pour paramétrer l'adresse mail d'envoi et le chemin du fichier de log

Obtention du war pour déploiement sur tomcat ou autre :

Bloc de code
languagebash
mvn clean package

Lancement de la mise à jour de la base de données

Bloc de code
languagebash
mvn exec:java -Dexec.args="dbupgrade"

 

Droits utilisateur

Le rôle ROLE_ADMIN est necessaire pour gérer l'application

Il est à paramétrer dans application-context-security.xml. L'authentification/identification se fait en shibboleth, le credentialsRequestHeader est à paramétrer en fonction de vos attributs shibboleth; ainsi que le authUserDetailsService.

Paramétrage via l'IHM

A cette adresse :
https://esupnfctag.univ-ville.fr/manager/applications
Ajouter une application. Pour un test, choisir Authentification CSN, Dummy !, le tagIdCheck qui convient (voir implémentation du tagIdCheck)

Test de l'application sans EsupNfcTagDroid et sans EsupNfcTagArduino

L'idée est de tester le process de badgeage en simulant les appels HTTP du badgeur EsupNfcTagDroid et/ou EsupNfcTagArduino

En utilisant cette adresse :

https://esupnfctag.univ-ville.fr/nfc-index?apkVersion=1-2099-01-01-00-00-00-dev&imei=123456

L'application va vérifier les différent service autorisés pour la personne connectée et créer une entrée dans Device (dans notre cas Dummy location) puis rediriger vers le « live » de ce lieu.

http://esupnfctag.univ-ville.fr/live?numeroId=6847041179388220887

Il est alors possible de simuler un badgeage csn via une commande curl ex :

 

Bloc de code
curl -X POST -H "Content-type:application/json" -d '{"csn":"045371d2fd3a80","numeroId":"6847041179388220887"}' http://esupnfctag.univ-ville.fr/csn-ws

Une fenetre de validation doit apparaître sur le « live »

Badgeage (tag_log)

Esup-nfc-tag-server à été pensé pour être souple et s’intégrer dans différents systèmes d'information. C'est pourquoi l'action de badger a été séparée en plusieurs étapes :

  1. Lecture de l'identifiant de carte
  2. Rechercher de l'identifiant de la carte dans un des référentiel du SI (tagIdCheck), puis création d'un tag_log au statut "none"
  3. Interrogation d'une application métier pour vérifier l'autorisation pour cette carte (isTagable)
  4. Validation du badgeage et lancement d'une procédure métier (validateTag), puis modification du statut du tag_log
  5. En option récupération d'éléments à afficher (getDisplay)

Image Added

Lors du badgeage un objet tag_log est créé au moment du tagIdCheck (si l'identifiant de carte est retrouvé dans le référentiel). Le tag_log représente la date (authDate), le lieu (location), et l'identité (eppn) du badgeage.

Bloc de code
languagejava
public class TagLog {
    private String desfireId;
    private String csn;
    private String eppn;
    private String firstname;
    private String lastname;
    private String numeroId;
    private String eppnInit;
    private String applicationName;
    private String location;
    private Status status;
    private Date authDate;
 
    public enum Status {
        none, valid, cancel
    }
}

A sa création le tag_log porte le statut "none", il passera à "valid" si le procéssus va jusqu'au bout et si tout se passe bien. Si le badgeage est annulé par l'utilisateur le status passe à "cancel". Dans les autres cas il restera au statut "none".

 

Info

Dans esup-nfc-tag eppnInit représente toujours le gestionnaire (celui qui badge). eppn représente l'identifiant du propriétaire de la carte badgée.

Applications

Esup-nfc-tag-server propose de gérer des "Applications" qui représentent la conjonction de 3 éléments:

  1. Une configuration d'authentification sur la carte NfcAuthConfig (pour faire simple CSN ou DESFIRE)
  2. Un service de recherche de l'indentifiant TagIdCheckApi
  3. Les urls des web-services métiers AppliExtRestApi comportant: isTagableUrl, validateTagUrl, getLocationsUrl et eventuellement displayUrl

Exemple d'une application de controle de présence :

  1. Configuration NFC : Desfire
  2. Contrôle du tagId : via LDAP
  3. Application externe : web service controle de présence

Autre exemple d'une application de carte culture :

  1. Configuration NFC : CSN
  2. Contrôle du tagId : via carte culture
  3. Application externe : web service carte culture

D'origine Esup-nfc-tag-server est fourni avec les implémentations suivante :

  • pour NfcAuthConfig : CsnAuthConfig (lecture simple du CSN),  DesfireReadConfig (Lecture d'une application Desfire, voir ici), DesfireWriteConfig et DesfireUpdateConfig (configurations spécifiques pour ESUP-SGC)
  • pour TagIdCheckApi : TagIdCheckLdap (recherche LDAP), TagIdCheckSql (requete SQL dans une base métier), TagIdCheckRestWs (recherche via un web service)
  • pour AppliExtRestApi : AppliExtRestWs (communication avec les applications métier en web services REST)

A voir :

Implémentation du Web Service TagIdCheck

Implementation du webService AppliExtRestWs

En option il est possible de préciser si, pour une application donnée, une validation par le gestionnaire (validation manuelle) est nécessaire. Il est aussi possible de déclarer une application active ou inactive, ceci ayant pour conséquence de rendre l'application ainsi que les salles (locations) non visible (cependant elle reste fonctionnelle).

Les salles (locations)

La notion de salles permet de proposer des applications "multi-salles". Dans le cas d'un dispositif carte culture, par exemple, les salles sont les différentes salles de spectacle. Pour une application de contrôle de présence il pourrait s'agir de salles de classe.

La liste des salles est donc fournie par l'application métier sous forme d'une liste de String au format JSON, accessible par esup-nfc-tag-server, en échange de l'eppn du gestionnaire (eppnInit). L'application métier gère de son coté les salles disponibles en fonction des droits du gestionnaire qui utilise l'application.

Bloc de code
languagexml
["Salle 1", "Salle 2"]

Périphériques (devices)

Chaque périphérique (Android, Appli Java, Arduino, Emulation clavier, encodeur ...) est enregistré dans esup-nfc-tag-server. Dans la plupart des cas les périphériques sont créés automatiquement lors du démarrage des applications clientes.

Il est nécessaire de créer manuellement des applcations dans le cas d'esup-nfc-tag-keyboard et pour les arduinos.

Bloc de code
languagejava
public class Device {
    private String numeroId;
    private boolean validateAuthWoConfirmation;
    private String eppnInit;
    private String imei;
    private String macAddress;
    private String userAgent;
    private String location;
    private Application application;
}

Le numéro d'identification du périphérique (numéroId) est utilisé lors du badgeage pour retrouver le lieu du badgeage (location), l'application et le gestionnaire (eppnInit). On recupère aussi le paramètre de validation automatique (validateAuthWoConfirmation).

Installation ESUP-NFC-TAG-SERVER