Authentification pour les commandes REST

La manière dont vous vous authentifiez pour exécuter des commandes REST dépend de la façon dont le serveur est configuré et de l'outil que vous utilisez pour exécuter les commandes.
Remarque : L'utilisation de commandes REST requiert les mêmes droits d'accès que l'utilisation de l'interface Web. Pour des informations sur les droits d'accès, voir Rôles et droits d'accès.

Authentification avec un nom d'utilisateur et un mot de passe

Le moyen le plus simple afin de s'authentifier pour les commandes REST consiste à utiliser un nom d'utilisateur et un mot de passe. Par exemple, si vous utilisez le programme curl, vous pouvez spécifier le nom d'utilisateur et le mot de passe dans la commande, conformément au code suivant :
curl -k -u jsmith:passwd
  https://myserver.example.com:8443/cli/application/info
  ?application=JPetStore

Authentification avec une clé de session

Certains clients requièrent une clé de session pour la connexion au serveur. Pour utiliser une clé de session, vous devez vous connecter au serveur comme d'habitude. Ensuite, vous procédez à l'extraction de la clé de session depuis votre session avec le serveur et l'utilisez dans d'autres outils.

Pour extraire une clé de session, connectez-vous au serveur comme d'habitude. Ensuite, dans le navigateur Web, recherchez la valeur de l'en-tête qui s'appelle UCD_SESSION_KEY. Vous pouvez rechercher le cookie de ce nom ou consulter la liste des en-têtes associés à la page Web. La façon dont vous affichez ces informations dépend du navigateur que vous utilisez. Reportez-vous à la documentation de votre navigateur Web pour plus d'informations.

Ensuite, vous pouvez utiliser cette clé de session afin de vous authentifier pour les commandes REST. Par exemple, vous pouvez ajouter l'en-tête suivante à la demande :
UCD_SESSION_KEY:cléSession
Utilisez la valeur du cookie UCD_SESSION_KEY pour cléSession.

Authentification dans des scripts et des programmes

De nombreux langages de programmation et de script peuvent appeler des commandes REST.
L'exemple ci-après est un script Python qui procède à l'authentification en ajoutant le mot de passe à l'en-tête de la demande.
#!/usr/bin/env python

import urllib2
import json
import base64
import sys

if not len(sys.argv) == 3:
  print 'usage: script <username> <password>'
  exit(1)

username = sys.argv[1]
password = sys.argv[2]

epass = base64.b64encode(username + ':' + password)
print 'base64 encoded: ' + epass
baseUrl = 'ucdeploy.example.org:8443'

url = 'https://' + baseUrl + '/cli/application/info' + '?application=JPetStore'

opener = urllib2.build_opener(urllib2.HTTPHandler)
req = urllib2.Request(url)
req.add_header('Authorization', 'Basic '+epass)
req.get_method = lambda: 'GET'

resp = opener.open(req)
print resp.read()

Authentification dans un script Groovy

Pour obtenir un exemple d'authentification dans un script Groovy, voir la page suivante :http://devblog.laraziosi.org/extensibility/index.php/devops-articles/6-getting-started-with-the-ibm-urbancode-deploy-rest-api-and-groovy

Authentification dans une classe Java

Le code Java™ ci-après est un exemple simple d'authentification avec un nom d'utilisateur et un mot de passe. Il accepte tous les certificats, mais vous pouvez le modifier afin de contrôler les certificats qui sont acceptés.

Cet exemple requiert les fichiers JAR HttpComponents-Util.jar et uDeployRestClient.jar. Le fichier HttpComponents-Util.jar se trouve dans le dossier opt sur le serveur. Le fichier uDeployRestClient.jar est disponible dans plusieurs plug-ins de base, comme le plug-in Applications IBM UrbanCode Deploy.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.URI;
import java.net.URISyntaxException;

import org.apache.http.HttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.DefaultHttpClient;
import org.apache.log4j.Logger;

import com.urbancode.commons.httpcomponentsutil.HttpClientBuilder;

public class RESTExample {

  public static void main(String[] args) {

  // suppress log4j messages from UCD library
  Logger.getRootLogger().setLevel(org.apache.log4j.Level.OFF);

  HttpClientBuilder clientBuilder = new HttpClientBuilder();
  clientBuilder.setUsername("admin");
  clientBuilder.setPassword("admin");

  // for SSL enabled servers, accept all certificates
  clientBuilder.setTrustAllCerts(true); 
  DefaultHttpClient client = clientBuilder.buildClient();

  try {
    HttpGet request = new HttpGet(new URI(
      "https://ucdeploy.example.org:8443/cli/application/info?application=JPetStore"));

    try {
      HttpResponseresp = client.execute(request);
      BufferedReaderbr = new BufferedReader ( 
        new InputStreamReader(resp.getEntity().getContent()));

      String currentLine = new String();
      while ((currentLine = br.readLine()) != null){
        System.out.print(currentLine);
      }
    } catch (IOException e) {
      e.printStackTrace();
    }
  } catch (URISyntaxException e) {
    e.printStackTrace();
  }

  }

}

Importation du certificat serveur

Le certificat serveur par défaut n'est pas signé. Certains outils ne se connectent pas aux serveurs dont les certificats ne sont pas signés par défaut. Pour accéder à un serveur avec un certificat autosigné, vous pouvez indiquer à l'outil qu'il doit se connecter de façon non sécurisée ou vous pouvez importer le certificat sur votre client. Procédez comme suit pour importer le certificat sur votre client :
  1. Exportez le certificat serveur dans un fichier :
    1. Sur l'ordinateur qui héberge le serveur IBM® UrbanCode Deploy, ouvrez le fichier server.xml dans un éditeur de texte. Par défaut, ce fichier se trouve à l'emplacement suivant : install_serveur/opt/tomcat/conf/server.xml. Le répertoire d'installation du serveur par défaut est /opt/ibm-ucd/server sous Linux et C:\Program Files\ibm-ucd\server sous Windows.
    2. Dans le fichier server.xml, recherchez les lignes de code suivantes et notez les valeurs des attributs keystoreFile et keystorePass :
      sslProtocol="TLS"
      keystoreFile="conf/tomcat.keystore"
      keystorePass="changeit" />
    3. Dans la fenêtre de ligne de commande, exécutez la commande suivante :
      keytool -v -list -keystore nomFichierMagasinClés
      Utilisez le nom de l'attribut keystoreFile qui figure dans le fichier server.xml pour nomFichierMagasinClés. Lorsque la commande vous invite à entrer un mot de passe, spécifiez la valeur de l'attribut keystorePass. Par défaut, il s'agit de changeit.
    4. Dans le résultat de la commande, recherchez l'alias du serveur. Par exemple, le résultat de la commande peut ressembler au code suivant :
      Keystore type: JKS
      Keystore provider: SUN
      
      Your keystore contains 1 entry
      
      Alias name: server
      Creation date: Mar 19, 2014
      Entry type: PrivateKeyEntry
      Dans ce code, l'alias est server.
    5. Exécutez la commande suivante pour exporter le certificat dans un fichier et spécifiez le mot de passe à nouveau :
      keytool -exportcert 
        -alias aliasServeur 
        -keystore nomFichierMagasinClés 
        -storetype jks 
        -file server.cert
      Utilisez l'alias du serveur pour aliasServeur.
  2. Copiez le fichier server.cert sur l'ordinateur client.
  3. Importez le fichier server.cert dans le magasin de clés de l'ordinateur client :
    1. Dans une fenêtre de ligne de commande sur l'ordinateur client, exécutez la commande suivante et spécifiez le mot de passe du magasin de clés sur le client ; par défaut, il s'agit de changeit :
      emplacementJre\jre\bin\keytool.exe -importcert 
        -alias aliasServeur
        -file tomcat.cert 
        -storetype jks 
        -keystore emplacementJre\jre\lib\security\cacerts
      Utilisez l'emplacement de l'environnement d'exécution Java (JRE) ou du kit Java Development Kit (JDK) pour emplacementJre.
A présent, certains outils qui utilisent cet environnement d'exécution Java (JRE) ou ce kit Java Development Kit (JDK) acceptent le certificat serveur. Il se peut que d'autres outils, comme curl, n'acceptent toujours pas le certificat serveur car il n'est pas signé. Pour résoudre ce problème, configurez un certificat signé pour le serveur.

Commentaires en retour