# Serveur CloudFoundry User Account and Authentication (UAA)

Le serveur UAA est un service de gestion d'identité multi-tenant, utilisé dans Cloud Foundry, mais également disponible en tant que serveur OAuth2 autonome. Son rôle principal est de fournir un serveur OAuth2, en émettant des jetons pour les applications clientes à utiliser lorsqu'elles agissent au nom des utilisateurs de Cloud Foundry. Il peut également authentifier les utilisateurs avec leurs identifiants Cloud Foundry, et peut agir comme un service SSO utilisant ces identifiants (ou d'autres). Il dispose de points de terminaison pour gérer les comptes d'utilisateurs et pour enregistrer les clients OAuth2, ainsi que diverses autres fonctions de gestion.

Coordonnées

Jetons : Une note sur les jetons, les portées et les autorités
Forum technique : liste de diffusion cf-dev
Documentation : docs/
Documentation API : UAA-APIs.rst
Spécification : Le framework d'autorisation OAuth 2
LDAP : Intégration LDAP UAA

Démarrage rapide

Prérequis :

Java 8

Si cela fonctionne, c'est gagné :

$ git clone git://github.com/cloudfoundry/uaa.git
$ cd uaa
$ ./gradlew run

Toutes les applications fonctionnent ensemble, les applications tournant sur le même port (8080) sous /uaa, /app et /api.

Le serveur UAA écrira un journal dans un fichier appelé uaa.log que vous pouvez trouver à l'aide de la commande suivante :

$ sudo find / -name uaa.log

que vous devriez trouver sous un chemin ressemblant à :

/private/var/folders/7v/518b18d97_3f4c8fzxphy6f8zcm51c/T/cargo/conf/logs/

Déployer sur Cloud Foundry

Vous pouvez également compiler l'application et la pousser vers Cloud Foundry, par exemple. Notre méthode recommandée est d'utiliser un fichier de manifeste, mais vous pouvez tout faire en ligne de commande.

$ ./gradlew :cloudfoundry-identity-uaa:war
$ cf push myuaa --no-start -m 512M -p uaa/build/libs/cloudfoundry-identity-uaa-2.3.2-SNAPSHOT.war 
$ cf set-env myuaa SPRING_PROFILES_ACTIVE default,hsqldb
$ cf set-env myuaa UAA_URL http://myuaa.<domain>
$ cf set-env myuaa LOGIN_URL http://myuaa.<domain>
$ cf set-env myuaa JBP_CONFIG_SPRING_AUTO_RECONFIGURATION '[enabled: false]'
$ cf set-env myuaa JBP_CONFIG_TOMCAT '{tomcat: { version: 7.0.+ }}'
$ cf start myuaa

Dans les étapes ci-dessus, remplacez :

myuaa par un nom d'application unique
2.3.2-SNAPSHOT par le label de version approprié de votre compilation
<domain> : c'est le domaine de votre application. Nous analyserons cela à partir de l'environnement système à l'avenir.
Vous pouvez également fournir un manifeste de configuration où la variable d'environnement UAA_CONFIG_YAML contient la configuration yaml complète.

Démonstration de l'utilisation en ligne de commande sur un serveur local

Exécutez d'abord le serveur UAA comme décrit ci-dessus :

$ ./gradlew run

Ensuite, ouvrez un autre terminal et, depuis le répertoire de base du projet, demandez au point de terminaison de connexion de vous informer sur le système :

$ curl -H "Accept: application/json" localhost:8080/uaa/login
{
  "timestamp":"2012-03-28T18:25:49+0100",
  "commit_id":"111274e",
  "prompts":{"username":["text","Username"],
    "password":["password","Password"]
  }
}

Vous pouvez alors essayer de vous connecter avec la gem ruby UAA. Assurez-vous d'avoir ruby 1.9, puis

$ gem install cf-uaac
$ uaac target http://localhost:8080/uaa
$ uaac token get marissa koala

(ou omettez le nom d'utilisateur / mot de passe pour être invité à les saisir).

Cette opération authentifie et obtient un jeton d'accès du serveur en utilisant l'octroi implicite OAuth2, similaire à l'approche prévue pour un client comme CF. Le jeton est stocké dans ~/.uaac.yml. Fouillez donc ce fichier et extrayez le jeton d'accès pour votre cible cf (ou utilisez l'option --verbose sur la ligne de commande de connexion ci-dessus pour le voir consigné dans votre console).

Vous pouvez ensuite vous connecter en tant que serveur de ressources et récupérer les détails du jeton :

$ uaac target http://localhost:8080/uaa
$ uaac token decode

Vous devriez voir votre nom d'utilisateur et l'identifiant client de l'octroi de jeton d'origine sur stdout, par exemple :

  exp: 1355348409
  user_name: marissa
  scope: cloud_controller.read openid password.write scim.userids tokens.read tokens.write
  email: [email protected]
  aud: scim tokens openid cloud_controller password
  jti: ea2fac72-3f51-4c8f-a7a6-5ffc117af542
  user_id: ba14fea0-9d87-4f0c-b59e-32aaa8eb1434
  client_id: cf

Exécution du système local avec les paramètres MySQL et PostgreSQL par défaut (et informations sur les scripts de migration Flyway)

$ ./gradlew -Dspring.profiles.active=default,mysql run

Cette commande suppose qu'une base de données MySQL est disponible avec les paramètres d'accès par défaut et répondra aux paramètres JDBC suivants.

driver = 'org.mariadb.jdbc.Driver'
url = 'jdbc:mysql://localhost:3306/uaa'
user = 'root'
password = 'changeme'
schemas = ['uaa']

De la même manière, si vous exécutez la commande

$ ./gradlew -Dspring.profiles.active=default,postgresql run

elle utilise les paramètres définis comme suit :

driver = 'org.postgresql.Driver'
url = 'jdbc:postgresql:uaa'
user = 'root'
password = 'changeme'

Ces paramètres sont dupliqués à deux endroits pour l'intégration Gradle. Ils sont définis comme valeurs par défaut dans les fichiers de configuration Spring XML et dans le fichier build.gradle principal. La raison pour laquelle ils se trouvent dans le fichier de build Gradle est que Gradle exécute toujours la tâche flywayClean avant de lancer l'application UAA. Si vous ne souhaitez pas nettoyer la base de données, vous pouvez définir la variable

-Dflyway.clean=false

dans votre ligne de commande. Cela désactive la tâche flywayClean dans le script Gradle. Une autre façon de désactiver flywayClean est de ne pas spécifier les profils Spring en ligne de commande, mais de définir les profils dans les fichiers uaa.yml et login.yml.

Démonstration de l'utilisation en ligne de commande sur run.pivotal.io

Le même exemple en ligne de commande devrait fonctionner avec un serveur UAA exécuté sur run.pivotal.io (sauf pour la partie décodage du jeton, car vous n'aurez pas le secret client). Dans ce cas, il n'est pas nécessaire d'exécuter un serveur uaa local, il suffit donc de demander au point de terminaison de connexion externe de vous informer sur le système :

$ curl -H "Accept: application/json" login.run.pivotal.io
{
  "prompts":{"username":["text","Username"],
    "password":["password","Password"]
  }
}