uaa
77.19.0
Slack #uaa
L'UAA est un service de gestion des identités multi-locataires, utilisé dans Cloud Foundry, mais également disponible en tant que serveur OAuth2 autonome. Son rôle principal est celui de fournisseur OAuth2, émettant des jetons que les applications clientes doivent utiliser lorsqu'elles agissent au nom des utilisateurs de Cloud Foundry. Il peut également authentifier les utilisateurs avec leurs informations d'identification Cloud Foundry et peut agir comme un service SSO en utilisant ces informations d'identification (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.
Le service d'authentification est uaa . Il s'agit d'une simple application Web Spring MVC. Déployez normalement dans Tomcat ou le conteneur de votre choix, ou exécutez ./gradlew run pour l'exécuter directement à partir du répertoire uaa dans l'arborescence source. Lors de l'exécution avec Gradle, il écoute sur le port 8080 et l'URL est http://localhost:8080/uaa
Le serveur UAA prend en charge les API définies dans le document UAA-APIs. Pour résumer :
Les points de terminaison OAuth2 /oauth/authorize et /oauth/token
Un point de terminaison /login_info pour permettre l'interrogation des invites de connexion requises
Un point de terminaison /check_token, pour permettre aux serveurs de ressources d'obtenir des informations sur un jeton d'accès soumis par un client OAuth2.
Un point de terminaison /token_key, pour permettre aux serveurs de ressources d'obtenir la clé de vérification pour vérifier les signatures de jetons
Point de terminaison de provisionnement des utilisateurs SCIM
OpenID connecte les points de terminaison pour prendre en charge l’authentification/userinfo. Prise en charge partielle d'OpenID.
L'authentification peut être effectuée par les clients de ligne de commande en soumettant les informations d'identification directement au point de terminaison /oauth/authorize (comme décrit dans la documentation UAA-API). Il existe un ImplicitAccessTokenProvider dans Spring Security OAuth qui peut faire le gros du travail si votre client est Java.
Authentifier
GET /login
Une interface de connexion par formulaire de base.
Approuver l'octroi du jeton OAuth2
GET /oauth/authorize?client_id=app&response_type=code...
Point de terminaison d’autorisation OAuth2 standard.
Obtenir un jeton d'accès
POST /oauth/token
Point de terminaison d’autorisation OAuth2 standard.
Exigences:
Si cela fonctionne, vous êtes en affaires :
$ git clone git://github.com/cloudfoundry/uaa.git
$ cd uaa
$ ./gradlew run
Les applications fonctionnent toutes avec les applications exécutées sur le même port (8080) que /uaa , /app et /api .
UAA se connectera à un fichier appelé uaa.log qui peut être trouvé à l'aide de la commande suivante : -
$ sudo lsof | grep uaa.log
que vous devriez trouver sous quelque chose comme : -
$TMPDIR/cargo/conf/logs/
Exécutez d’abord le serveur UAA comme décrit ci-dessus :
$ ./gradlew run
Depuis un autre terminal, vous pouvez utiliser curl pour vérifier que UAA a démarré en demandant des informations système :
$ curl --silent --show-error --head localhost:8080/uaa/login | head -1
HTTP/1.1 200
Pour les requêtes complexes, il est plus pratique d'interagir avec UAA en utilisant uaac , le client de ligne de commande UAA.
Pour charger l'agent JDWP pour le débogage UAA jvm, démarrez le serveur comme suit :
./gradlew run -Dxdebug=trueou
./gradlew -Dspring.profiles.active=default,hsqldb,debug runVous pouvez ensuite attacher votre débogueur au port 5005 du processus jvm.
Pour suspendre le démarrage du serveur jusqu'à ce que le débogueur soit connecté (utile pour déboguer le code de démarrage), démarrez le serveur comme suit :
./gradlew run -Dxdebugs=trueou
./gradlew -Dspring.profiles.active=default,hsqldb,debugs run ./gradlew run exécute le serveur UAA avec la base de données hsqldb par défaut.
% docker run --name mysql1 -e MYSQL_ROOT_PASSWORD=changeme -d -p3306:3306 mysqluaa (par exemple dans une session interactive mysql) % mysql -h 127.0.0.1 -u root -p
...
mysql > create database uaa ;% ./gradlew -Dspring.profiles.active=mysql,default rundocker run --name postgres1 -p 5432:5432 -e POSTGRES_PASSWORD=mysecretpassword -d postgresuaa (par exemple dans une session interactive psql) % psql -h 127.0.0.1 -U postgres create database uaa;
create user root with superuser password 'changeme';
% ./gradlew -Dspring.profiles.active=postgresql,default run c uaa
psql (14.5 (Homebrew), server 15.0 (Debian 15.0-1.pgdg110+1))
WARNING: psql major version 14, server major version 15.
Some psql features might not work.
You are now connected to database "uaa" as user "postgres".
d
List of relations
Schema | Name | Type | Owner
--------+-------------------------------+----------+-------
public | authz_approvals | table | root
public | expiring_code_store | table | root
public | external_group_mapping | table | root
public | external_group_mapping_id_seq | sequence | root
public | group_membership | table | root
public | group_membership_id_seq | sequence | root
public | groups | table | root
public | identity_provider | table | root
public | identity_zone | table | root
public | oauth_client_details | table | root
public | oauth_code | table | root
public | oauth_code_id_seq | sequence | root
public | revocable_tokens | table | root
public | schema_version | table | root
public | sec_audit | table | root
public | sec_audit_id_seq | sequence | root
public | spring_session | table | root
public | spring_session_attributes | table | root
public | user_info | table | root
public | users | table | root
(23 rows)
Vous pouvez exécuter les tests d'intégration avec docker
$ run-integration-tests.sh <dbtype>
créera un conteneur Docker exécutant la base de données uaa + ldap + sur laquelle les tests d'intégration sont exécutés.
Les tests unitaires uaa par défaut (./gradlew test IntegrationTest) utilisent hsqldb.
Pour exécuter les tests unitaires avec docker :
$ run-unit-tests.sh <dbtype>
Les tests unitaires uaa par défaut ( ./gradlew test ) utilisent hsqldb.
Commencez par découvrir à quel projet Gradle appartient votre test. Vous pouvez trouver tous les projets en exécutant
$ ./gradlew projects
Pour exécuter une classe de test spécifique, vous pouvez spécifier le module et la classe de test.
$ ./gradlew :<project name>:test --tests <TestClass>.<MethodName>
Dans cet exemple, il exécute uniquement les tests JdbcScimGroupMembershipManagerTests dans le module cloudfoundry-identity-server :
$ ./gradlew :cloudfoundry-identity-server:test
--tests "org.cloudfoundry.identity.uaa.scim.jdbc.JdbcScimGroupMembershipManagerTests"
ou pour exécuter tous les tests d'une classe
$ ./gradlew :<project name>:test --tests <TestClass>
Vous souhaiterez peut-être utiliser la commande gradle complète trouvée au bas du script scripts/unit-tests.sh en ajoutant le nom du projet à la commande test et en ajoutant l'option --tests .
$ ./gradlew :clean :assemble -Pversion=${UAA_VERSION}
Il y a en fait plusieurs projets ici, l'application serveur uaa principale, une bibliothèque client et quelques exemples :
uaa un projet WAR pour un déploiement facile
server un projet JAR contenant l'implémentation de l'API REST d'UAA (y compris SCIM) et de l'interface utilisateur
model un projet JAR utilisé à la fois par la bibliothèque client et le serveur
api (exemple) est un service de ressources OAuth2 qui renvoie une liste fictive des applications déployées
app (exemple) est une application utilisateur qui utilise les deux éléments ci-dessus
En termes de CloudFoundry
uaa fournit un service d'authentification ainsi qu'une délégation autorisée pour les services et applications back-end (en émettant des jetons d'accès OAuth2).
api est un service qui fournit des ressources auxquelles d'autres applications peuvent souhaiter accéder au nom du propriétaire de la ressource (l'utilisateur final).
app est une application Web qui nécessite une authentification unique et un accès au service api au nom des utilisateurs.
Conditions préalables
Le déploiement Kubernetes est en développement actif. Vous devez vous attendre à des changements fréquents (et éventuellement cassants). Cette section sera mise à jour au fur et à mesure des progrès réalisés sur cet ensemble de fonctionnalités. À partir de maintenant :
Le répertoire K8s contient des modèles ytt qui peuvent être rendus et appliqués à un cluster K8s.
En développement, ce Makefile peut être utilisé pour des activités courantes de rendu et de déploiement.
En production, vous souhaiterez probablement utiliser ytt directement. Quelque chose comme ceci devrait vous aider à démarrer :
$ ytt -f templates -f values/default-values.yml | kubectl apply -f -
Si vous souhaitez remplacer certaines de ces valeurs, vous pouvez le faire en profitant de la fonctionnalité de superposition de YTT.
$ ytt -f templates -f values/default-values.yml -f your-dir/production-values.yml | kubectl apply -f -
Bien entendu, vous pouvez toujours abandonner complètement les valeurs par défaut et fournir votre propre fichier de valeurs.
Voici quelques façons de vous impliquer dans la communauté :
Exigences:
Pour déboguer les intégrations UAA et LDAP, nous utilisons une image docker OpenLdap du projet Bitnami de VMWare
uaa/src/main/resources/uaa.yml et activez LDAP en décommentant la ligne 7, spring_profiles: ldap,default,hsqldbdocker-compose up à partir du répertoire scripts/ldapscripts/ldap vérifiez la connectivité jusqu'à l'exécution du conteneur OpenLdap en exécutant docker-confirm-ldapquery.sh./gradlew run/uaa et connectez-vous avec l'utilisateur LDAP user01 et le mot de passe password1Utilisez la commande ci-dessous pour nettoyer le conteneur et le volume :
docker-compose down --volumes
