Que de mois près l’épisode 1 sur les API RSE. Il était temps que je m’y remette !
Pour rappel, les APIs RSE, sont un ensemble de services fournis avec l’OS depuis la V7R5 TR2 (V7R4 TR8).
Elles sont gérées par le serveur admin5. On y accède depuis un navigateur par host:2012/openapi/ui/
Ces APIs sont sécurisées par une authentification basique, avec possibilité d’ouvrir une session via la génération d’un token.
Par défaut, tous les utilisateurs peuvent accéder à ces services.
Vu les possibilités d’actions de ces services, il est impératif d’en limiter l’accès.
Dans le bloc « Administration Services », il y a l’API « post /api
Dans cette API, il y a un json à renseigner.
- Persist : Permet de garder la configuration au-delà, d’un arrêt-redémarrage du serveur (admin5). Pour cela, il faut valoriser le paramètre à true. Dans ce cas, le service génèrera le fichier, rseapi.properties, dans le répertoire IFS /QIBM/UserData/OS/RSEAPI
- adminUsers: Utilisateurs qui seront désignés en tant qu’administrateur de l’API RSE.
- includeUsers: Utilisateurs autorisés à utiliser l’API RSE
- excludeUsers: Utilisateurs non autorisés à utiliser l’API RSE
- maxFileSize: Taille maximale des données du fichier IFS pouvant être traitées (lecture ou écriture) par l’API RSE.
- maxSessionInactivity: Durée maximale d’inactivité, en secondes, avant qu’une session disponible ne soit invalidée.
- maxSessionLifetime: Durée de vie maximale, en secondes, pour une session. La valeur -1 indique qu’il n’y a pas de limite. Une valeur autre que -1 doit être supérieur ou égal à 30.
- maxSessionUseCount: Nombre maximum de fois qu’une session peut être utilisée avant qu’elle ne soit invalidée. La valeur de -1 indique qu’il n’y a pas de limite.
- maxSessionWaitTime: Temps maximum, en secondes, d’attente pour qu’une session devienne disponible. La valeur de -1 indique il n’y a pas de limite.
- maxSessions: Nombre maximum de sessions totales. La valeur -1 indique qu’il n’y a pas de limite.
- maxSessionsPerUser: Nombre maximum de sessions autorisées par utilisateur. La valeur -1 indique qu’il y a aucune limite.
- sessionCleanupInterval: Intervalle de temps, en secondes, entre deux exécutions du démon de maintenance de session.
Il y a plusieurs subtilités sur les autorisations de profils:
- D’inscrire un profil en tant qu’admin ne suffit pas, il doit aussi être dans les utilisateurs autorisés.
- Un profil autorisé ayant le droit *ALLOBJ est de fait admin des APIs.
- Un profil exclu et autorisé, c’est l’exclusion qui gagne.
Mes préconisations :
- Avoir un paramétrage persistant – « persist »: true
- Autoriser explicitement les profils autorisés et les rôles administrateurs – adminUsers et IncludeUsers
- Limiter le nombre de profils autorisés, attention aux profils *ALLOBJ
- Sur les paramètres de session, ça va dépendre des usages, mais si vous savez par avance les limites en nombres d’appels, ou de temps, alors ajuster aussi ces paramètres.
Pour une gestion plus fluide des autorisations, il manque à mon sens la possibilité d’inscrire un groupe qui serait le profil de groupe ou supplémentaire des utilisateurs autorisés aux APIs. Ceci permettrait une gestion plus fluide et sans accès à l’APIs de paramétrage.
Il existe une Idea avec cette demande. J’ai voté pour elle, vous pouvez aussi le faire :
