Tester les connecteurs SCIM pour l'approvisionnement local

Okta fournit un utilitaire permettant de tester les connecteurs SCIM créés à l'aide du SDK Okta Provisioning Connector. Il peut également tester n'importe quel connecteur SCIM personnalisé ou serveur SCIM. Vous n'avez pas à vous connecter à Okta et à l'Okta Provisioning Agent pour tester votre connecteur.

L'utilitaire de test est compris dans le package du SDK Okta Provisioning Connector, qui est disponible dans la page des Téléchargements d'Okta. Pour obtenir le package du SDK Okta Provisioning Connector, connectez-vous à la console d'administration et sélectionnez ParamètresTéléchargements. Cliquez ensuite sur Télécharger le SDK Okta Provisioning Connector.

L'utilitaire de test se trouve dans le fichier scim-sdk-test.jar du dossier de test du SDK Okta Provisioning Connector. La documentation de l'utilitaire de test se trouve dans le fichier tester/README.TXT. Ces tests ont pour objectif principal de valider la réponse de votre connecteur SCIM ou de votre serveur SCIM.

Ce contenu s'applique uniquement à SCIM 1.1.

Données de test

Les données de test sont dans les fichies .json du répertoire tester/data. Vous pouvez utiliser ou modifier ces fichiers pour tester votre connecteur. Tous les tests partent du principe que les données d'entrée sont valides. Modifiez ou créez les fichiers de données exemple avec précaution.

Exécuter des tests

Exécutez les tests à l'aide du fichier scim-sdk-tests.jar . Des informations complètes sur les tests, notamment sur les appels, les réponses, les différentes options et les exemples de résultats sont fournies dans le fichier tester/README.TXT.

Pour visualiser tous les arguments possibles, exécutez le fichier jar sans aucun argument :

java -jar scim-sdk-tests.jar

Chaque appel doit inclure les paramètres suivants :

  • url : l'URL de base du serveur SCIM
  • method : la méthode d'approvisionnement Okta à tester
  • file : le fichier contenant les données d'entrée

Voici un exemple d'appel utilisant le nombre minimum d'arguments :

java -jar scim-sdk-tests.jar -url http://localhost:8080 -method createNewUser -file data/createNewUser.json

Le tableau suivant répertorie les arguments que vous pouvez transmettre.

Argument Description
-arg <propertyName=propertyValue> Transmet n'importe quelle paire nom/valeur de propriétés que votre méthode doit utiliser.
-expectResults <true|false> Définissez les attentes de test indiquant si le connecteur doit retourner un résultat pour la méthode actuelle. Cet argument peut être utilisé avec les méthodes suivantes : checkUserExists, downloadUsers, downloadGroups, et importUserProfile.
-file <fileName> Le fichier de données à utiliser comme entrée pour la méthode actuelle. Des fichiers d'exemple sont disponibles dans le répertoire de données du package de l'utilitaire de test.
-header <headerName=headerValue> N'importe quelle en-tête HTTP que vous souhaitez envoyer au serveur SCIM. Par exemple, X-Internal-AuthHeader=secret
-method <methodName> La méthode pour appeler. Le tableau Méthodes répertorie les méthodes disponibles.
-url <url> L'URL du serveur SCIM à utiliser (par exemple, http://acme.com:8080).

Méthodes

methodName

Requête HTTP envoyée

Remarques
createNewUser GET /Users?filter=userName=myemail@domain.com&startIndex=1&count=100POST /Users Si vous utilisez un connecteur créé à l'aide du SDK Okta Provisionning Connector, le testeur transmet un objet User pour créer un utilisateur en attente à l'aide de votre connecteur. Cela teste la méthode SCIMService.createUser du connecteur.
createPendingUser POST /Users Si vous utilisez un connecteur créé à l'aide du SDK Okta Provisionning Connector, le testeur transmet un objet utilisateur pour créer un utilisateur en attente à l'aide de votre connecteur. Il teste la méthode SCIMService.createUser. du connecteur.
downloadUsers GET /Users?startIndex=1&count=100 Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de renvoyer la liste complète des utilisateurs. Il teste la méthode SCIMService.getUsers du connecteur (sans filtre).
checkUserExists GET /Users?filter=userName=myemail@domain.com&startIndex=1&count=100 Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de vérifier si un utilisateur spécifique existe déjà. Il requiert les propriétés userIdFieldName et userIdFieldValue. Il teste la méthode SCIMService.getUsers du connecteur (avec filtre).
importUserProfile GET /Users/<Id> Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de renvoyer un seul utilisateur, en lui transmettant l'ID de l'utilisateur. Il requiert la propriété supplémentaire suivante : id. Il teste la méthode SCIMService.getUser du connecteur.
activateUser PUT /Users/<id> Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur d'activer un utilisateur existant. Il teste la méthode SCIMService.updateUser du connecteur.
deactivateUser PUT /Users/<id> Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de désactiver un utilisateur existant. Il teste la méthode SCIMService.updateUser du connecteur.
reactivateUser PUT /Users/<id> Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de résactiver un utilisateur existant. Il teste la méthode SCIMService.updateUser du connecteur.
pushPasswordUpdate

PUT /Users/<id>

Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de metre à jour le mot de passe d'un utilisateur existant. Il teste la méthode SCIMService.updateUser du connecteur
pushProfileUpdate

PUT /Users/<id>

Si vous testez un connecteur créé avec le SDK Okta Connector, Okta demande à votre connecteur de metre à jour les propriétés d'un utilisateur existant. Il teste la méthode SCIMService.updateUser du connecteur.
deleteGroup DELETE /Groups/<id> Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de supprimer un groupe. Il teste la méthode SCIMService.deleteGroup du connecteur.
updateGroup PUT /Groups/<id> Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de mettre un groupe à niveau. Il teste la méthode SCIMService.updateGroup du connecteur.
createGroup POST /Groups Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de créer un groupe. Il teste la méthode SCIMService.createGroup du connecteur.
getGroupById GET /Groups/<id> Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de renvoyer un groupe en fonction de son ID. Il teste la méthode SCIMService.getGroup du connecteur.
downloadGroups GET /Groups?startIndex=1&count=100 Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de renvoyer la liste complète des groupes. Il teste la méthode SCIMService.getGroups du connecteur.
getImplementedUserManagementCapabilities GET /ServiceProviderConfigs Si vous testez un connecteur créé avec le SDK Okta Connector, le testeur demande à votre connecteur de renvoyer la liste UserManagementCapabilities que votre connecteur a implémenté. Il teste la méthode SCIMService.getImplementedUserManagementCapabilities du connecteur.

Exemples

L'implémentation par défaut proposée par Okta part du principe que the appname est onprem_app. Les exemples suivants et les fichiers de données d'entrée dans le dossier de données de l'implémentation par défaut utilisent le nom de schéma personnalisé (urn:okta:onprem_app:1.0:user) pour les schémas personnalisés App User. Le bon appname doit être utilisé lorsque vous implémentez votre connecteur.

createNewUser

createNewUser transmet un objet SCIM User pour tenter de créer un utilisateur à l'aide de votre connecteur. Il teste la méthode SCIMService.createUser du SDK du connecteur. Deux exemples de fichiers de données sont fournis pour effectuer les tests.

Le test suivant envoie l'utilisateur SCIM défini dans le fichier createNewUser.json à votre connecteur SCIM. Une validation de base est effectuée sur l'utilisateur renvoyé par votre connecteur.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method createNewUser -file data/createNewUser.json

Réponse :

[ 04-10-2013 13:23:01.258 ] [ INFO] - Envoi d'une requête POST à http://localhost:8080/Users [ 04-10-2013 13:23:01.449 ] [ INFO] - Okta utilisera l'ID 103 pour identifier cet utilisateur à l'avenir. [ 04-10-2013 13:23:01.450 ] [ INFO] - Utilisateur renvoyé par le connecteur : Schémas : "urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:enterprise:1.0" Numéros de téléphone : Veleur : "123-444-5555" Type : "mobile" Nom d'utilisateur : "myemail@domain.com" Nom : Nom de famille : "LastName" Prénom : "FirstName" Active : vrai E-mails : Principal : vrai Valeur : "myemail@domain.com" Type : "primary" Primaire : faux Valeur : "mypersonalemail@domain.com" Type : "secondary" Mot de passe : "verySecure" Id : "103" [ 04-10-2013 13:23:01.450 ] [ INFO] - OK!

createPendingUser

createPendingUser transmet un objet SCIM User pour tenter de créer un utilisateur en attente à l'aide de votre connecteur. Il teste la méthode SCIMService.createUser du SDK du connecteur. Deux exemples de fichiers de données sont fournis pour effectuer les tests.

createPendingUser est similaire à createNewUser . La seule différence est que le champ actif de tous les utilisateurs sera faux.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method createPendingUser -file data/createPendingUser-withCustomExtension.json

downloadUsers

downloadUsers demande à votre connecteur de renvoyer la liste complète des utilisateurs. Il teste la méthode SCIMService.getUsers du connecteur, sans lui appliquer de filtre.

Le test suivant envoie une requête à votre connecteur SCIM pour demander tous les utilisateurs Les utilisateurs renvoyés sont enregistrés sur le disque. Si plusieurs pages d'utilisateurs existent, le test peut envoyer plusieurs requêtes à votre connecteur.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method downloadUsers. Réponse :

[ 04-10-2013 14:14:18.888 ] [ INFO] - requête GET faite à http://localhost:8080/Users?startIndex=1&count=100 [ 04-10-2013 14:14:19.003 ] [ INFO] - downloadUsers : 3 utilisateurs renvoyés. [ 04-10-2013 14:14:19.007 ] [ INFO] - Utilisateurs téléchargement : Utilisateurs renvoyés depuis le connecteur connecté à downloadUsers-20131004-141419.txt

checkUserExists

checkUserExists demande à votre connecteur si un utilisateur spécifique existe. Il teste la méthode SCIMService.getUsers du connecteur, en lui appliquant un filtre. Il requiert les propriétés supplémentaires suivantes : userIdFieldName et userIdFieldValue.

Le test suivant utilise les propriétés fournies pour envoyer une requête à votre connecteur SCIM. Le test part du principe que votre connecteur SCIM ne trouvera pas d'utilisateur correspondant au nom d'utilisateur myemail@domain.com et leur nom d'utilisateur.

Le test doit renvoyer une sortie similaire à l'exemple de réponse.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080/ -method checkUserExists -arg userIdFieldName=userName -arg userIdFieldValue=myemail@domain.com -expectResults false

Réponse :

[ 03-10-2013 14:54:16.741 ] [ INFO] - requête GET faite à http://localhost:8080/Users?filter=userName%20eq%20%22myemail%40dom... [ 03-10-2013 14:54:16.846 ] [ INFO] - checkUserExists : Aucun utilisateur n'est revenu du serveur. On peut s'attendre à ça. [ 03-10-2013 14:54:16.846 ] [ INFO] - OK!

Utilisation

L'exécution du code suivant (en omettant l'argument -expectResults de la commande précédente) devrait faire échouer les tests :

$ java -jar scim-sdk-tests.jar -url http://localhost:8080/ -method checkUserExists -arg userIdFieldName=userName -arg userIdFieldValue=myemail@domain.com

Réponse :

[ 03-10-2013 14:57:41.218 ] [ INFO] - requête GET faite à http://localhost:8080/Users?filter=userName%20eq%20%22myemail%40dom... [ 03-10-2013 14:57:41.319 ] [ ERROR] - Résultats attendus de checkUserExists mais rien n'a été obtenu.

Lorsque votre connecteur trouve un utilisateur, les données de utilisateur et certaines informations de débogage Okta sont générées :

$ java -jar scim-sdk-tests.jar -url http://localhost:8080/ -method checkUserExists -arg userIdFieldName=id -arg userIdFieldValue=102

Réponse :

[ 03-10-2013 15:01:14.095 ] [ INFO] - requête GET faite à http://localhost:8080/Users?filter=id%20eq%20%22102%22&startInd... [ 03-10-2013 15:01:14.217 ] [ INFO] - checkUserExists: 1 utilisateur renvoyé. [ 03-10-2013 15:01:14.217 ] [ INFO] - checkUserExists: Utlisateur renvoyé de Connector : schemas: "urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:enterprise:1.0", "urn:okta:onprem_app:1.0:user" ID : "102" Nom d'utilisateur : "admin" Nom : Formaté : "SCIM firstname2 SCIM lastname2" Prénom : "SCIM first2" Nom de famille : "SCIM last2" Deuxième prénom : "SCIM middle2" E-mails : Valeur : "SCIM_admin@okta.com" Primaire : vrai Type : "work" Active : faux Mot de passe : "fakepassword" Groupes : Valeur : "1002" Affichage : "secondGroup" urn :okta:onprem_app:1.0:utilisateur : isAdmin : vrai isOkta : faux departmentName: "Administration" [ 03-10-2013 15:01:14.217 ] [ INFO] - checkUserExists: L'ID 102 servira d'identifiant pour cet utilisateur dans Okta [ 03-10-2013 15:01:14.217 ] [ INFO] - checkUserExists: L'utilisateur sera retourné comme INACTIF [ 03-10-2013 15:01:14.218 ] [ INFO] - OK!

Cas d'utilisation

Comment rechercher un utilisateur à partir de son prénom :

java -jar scim-sdk-tests.jar -url http://localhost:8080/ -method checkUserExists -arg userIdFieldName=name.givenName -arg userIdFieldValue="SCIM first"

Comment rechercher un utilisateur à partir d'une propriété d'extension de schéma personnalisé :

java -jar scim-sdk-tests.jar -url http://localhost:8080/ -method checkUserExists -arg userIdFieldName=urn:okta:onprem_app:1.0:user:departmentName \ -arg userIdFieldValue="Cloud Service"

importUserProfile

importUserProfile demande à votre connecteur de renvoyer un seul utilisateur en lui transmettant l'ID de l'utilisateur. Il teste la méthode SCIMService.getUser du connecteur. Il requiert la propriété supplémentaire suivante : id.

Le test suivant envoie une requête à votre connecteur SCIM pour obtenir le profil utilisateur dont l'ID est 101.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method importUserProfile -arg id=101

Réponse :

[ 04-10-2013 13:57:54.092 ] [ INFO] - requête GET faite à http://localhost:8080/Users/101 [ 04-10-2013 13:57:54.203 ] [ INFO] - importUserProfile : Utilisateur retourné de Connector : Schéma s: "urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:enterprise:1.0", "urn:okta:onprem_app:1.0:user" Id : "101" Nom d'utilisateur : "okta" Nom : Formaté : "SCIM firstname SCIM lastname" Prénom : "SCIM first" Nom de famille : "SCIM last" Deuxième prénom : "SCIM middle" E-mails : Valeur : "SCIM_okta@okta.com" Primaire : vrai Type : "work" Active : vrai Mot de passe : "inSecure" Groupes : Valeur : "1001" Affichage : "firstGroup" valeur : "1002" Affichage : "secondGroup" urn :okta:onprem_app:1.0:user: isAdmin : faux isOkta : vrai departmentName : "Cloud Service" [ 04-10-2013 13:57:54.204 ] [ INFO] - importUserProfile: L'ID 101 servira d'identifiant pour cet utilisateur dans Okta [ 04-10-2013 13:57:54.204 ] [ INFO] - OK!

Cas d'utilisation

L'exemple suivant vous explique comment rechercher un utilisateur qui, selon vous, n'existe pas :

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method importUserProfile -arg id=invalidExternalId -expectResults false

Réponse :

[ 04-10-2013 14:00:01.081 ] [ INFO] - requête GETfaite à http://localhost:8080/Users/invalidExternalId [ 04-10-2013 14:00:01.245 ] [ WARN] - état d'erreur 404 reçu de http://localhost:8080/Users/invalidExternalId [ 04-10-2013 14:00:01.245 ] [ INFO] - importUserProfile : Aucun utilisateur n'est revenu du serveur. On peut s'attendre à ça. [ 04-10-2013 14:00:01.246 ] [ INFO] - OK!

L'exemple suivant vous montre comment rechercher un utilisateur que vous attendiez, mais pour lequel aucun résultat n'est renvoyé :

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method importUserProfile -arg id=103

Réponse :

[ 04-10-2013 14:00:52.096 ] [ INFO] - requête GET faite à http://localhost:8080/Users/103 [ 04-10-2013 14:00:52.191 ] [ WARN] - état d'erreur 404 reçu de http://localhost:8080/Users/103 [ 04-10-2013 14:00:52.191 ] [ ERROR] - Résultats attendus de importUserProfile mais n'a rien obtenu.

activateUser

activateUser demande à votre connecteur d'activer un utilisateur existant. Il teste la méthode SCIMService.updateUser du connecteur.

Le test ci-dessous envoie une requête à votre connecteur SCIM vous demandant de mettre à jour l'utilisateur. Comme il s'agit d'un test d'activation de l'utilisateur, le champ actif est toujours vrai.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080/ -method activateUser -file data/activateUser.json

Réponse :

[ 10-10-2013 14:29:00.211 ] [ INFO] - requête PUT faite à http://localhost:8080/Users/101 [ 10-10-2013 14:29:00.598 ] [ INFO] - activateUser : enverrra à Okta que l'état actif de l'utilisateur est : vrai [ 10-10-2013 14:29:00.598 ] [ INFO] - OK!

deactivateUser

deactivateUser demande à votre connecteur de désactiver un utilisateur existant. Il teste la méthode SCIMService.updateUser du connecteur.

Le test suivant envoie une requête à votre connecteur SCIM vous demandant de mettre à jour l'utilisateur. Comme il s'agit d'un test de désactivation de l'utilisateur, le champ actif est toujours vrai.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080/ -method deactivateUser -file data/deactivateUser.json

Réponse :

[ 10-10-2013 14:32:51.211 ] [ INFO] - requête PUT faite à http://localhost:8080/Users/101 [ 10-10-2013 14:32:52.171 ] [ INFO] - NOTE : deactivateUser ne retourne pas l'utilisateur renvoyé par le connecteur à Okta. Okta suppose une réponse sans erreur de votre connecteur signifie que les méthodes deactivateUser ont réussi. [ 10-10-2013 14:32:52.598 ] [ INFO] - OK!

reactivateUser

reactivateUser demande à votre connecteur d'activer un utilisateur précédemment désactivé. Il teste la méthode SCIMService.updateUser du connecteur.

Le test suivant envoie une requête à votre connecteur SCIM vous demandant de mettre à jour l'utilisateur. Comme il s'agit d'un test de réactivation de l'utilisateur, le champ actif sera toujours vrai.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080/ -method reactivateUser -file data/reactivateUser.json

Réponse :

[ 10-10-2013 14:35:04.704 ] [ INFO] - requête PUT faite à http://localhost:8080/Users/101 [ 10-10-2013 14:35:04.828 ] [ INFO] - NOTE : reactivateUser ne retourne pas l'utilisateur renvoyé par le connecteur à Okta. Okta suppose qu'une réponse sans erreur de votre connecteur signifie que les méthodes reactivateUser ont réussi [ 10-10-2013 14:35:04.828 ] [ INFO] - OK!

pushPasswordUpdate

pushPasswordUpdate demande à votre connecteur de mettre à jour le mot de passe d'un utilisateur existant. Il teste la méthode SCIMService.updateUser du connecteur.

Le test suivant envoie une requête à votre connecteur SCIM vous demandant de mettre à jour l'utilisateur. Même si le mot de passe a changé, l'objet utilisateur complet vous sera transmis.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080/ -method pushPasswordUpdate -file data/pushPasswordUpdate.json

Réponse :

[ 10-10-2013 14:36:52.029] [ INFO] - requête PUT faite à http://localhost:8080/Users/101 [ 10-10-2013 14:36:52.124 ] [ INFO] - NOTE : pushPasswordUpdate ne retourne pas l'utilisateur renvoyé par le connecteur à Okta. Okta suppose qu'une réponse non erronée de votre connecteur signifie que les méthodes pushPasswordUpdate ont réussi. [ 10-10-2013 14:36:52.124 ] [ INFO] - OK!

pushProfileUpdate

pushProfileUpdate demande à votre connecteur de mettre à jour les propriétés d'un utilisateur existant. Il teste la méthode SCIMService.updateUser du connecteur.

Le test suivant envoie une requête à votre connecteur SCIM vous demandant de mettre à jour l'utilisateur. L'objet utilisateur complet vous est transmis au lieu d'un objet contenant uniquement les champs modifiés.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080/ -method pushProfileUpdate -file data/pushProfileUpdate.json

Réponse :

[ 10-10-2013 14:39:44.693] [ INFO] - requête PUT faite à http://localhost:8080/Users/101 [ 10-10-2013 14:39:44.785] [ INFO] - NOTE : pushProfileUpdate ne retourne pas l'utilisateur renvoyé par le connecteur à Okta. Okta suppose qu'une réponse non erronée de votre connecteur signifie que les méthodes pushProfileUpdate ont réussi. [ 10-10-2013 14:39:44.786 ] [ INFO] - OK!

downloadGroups

downloadGroups demande à votre connecteur de renvoyer la liste complète des groupes. Il teste la méthode SCIMService.getGroups du connecteur.

Le test suivant envoie une requête à votre connecteur SCIM afin d'obtenir tous les groupes. Les groupes renvoyés sont enregistrés sur le disque. Si plusieurs pages de groupes existent, le test peut envoyer plusieurs requêtes à votre connecteur.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method downloadGroups

Réponse :

[ 10-10-2013 14:40:55.598 ] [ INFO] - requête GET faite à http://localhost:8080/ groupes?startIndex=1&count=100 [ 10-10-2013 14:40:55.816 ] [ INFO] - downloadGroups : 2 groupes renvoyés. [ 10-10-2013 14:40:55.819 ] [ INFO] - downloadGroups : groupes renvoyés par le connecteur connecté à downloadGroups-20131010-144055.txt [ 10-10-2013 14:40:55.820 ] [ INFO] - OK!

getGroupById

getGroupById demande à votre connecteur de renvoyer un groupe à partir de l'ID indiqué. Il teste la méthode SCIMService.getGroup du connecteur. Il requiert la propriété supplémentaire suivante : id.

Le test suivant envoie une requête à votre connecteur SCIM pour lui demander de renvoyer le groupe. Toutes les propriétés du groupe seront imprimées.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method getGroupById -arg id=1002

Réponse :

[ 17-10-2013 18:03:17.270 ] [ INFO] - requête GET faite à http://localhost:8080/Groups/1002 [ 17-10-2013 18:03:17.381 ] [ INFO] - getGroupById : Groupe retourné du connecteur : schemas: "urn:scim:schemas:core:1.0", "urn:okta:custom:group:1.0" Id : "1002" Membres : Valeur : "User-001" Sffichage : "First User" Valeur : "User-002" Affichage : "Second User" Nom d'affichage : "AppGroup-Changed" Urn :okta:custom:group:1.0: Description : "This is the changed first group" [ 17-10-2013 18:03:17.381 ] [ INFO] - OK!

Si aucun groupe n'est trouvé pour cet ID, le résultat est similaire à la réponse suivante :

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method getGroupById -arg id=3455

Réponse :

[ 18-10-2013 10:22:40.733 ] [ INFO] - requête GET faite à http://localhost:8080/Groups/3455 [ 18-10-2013 10:22:40.833 ] [ WARN] - état d'erreur 404 reçu de http://localhost:8080/Groups/3455 [ 18-10-2013 10:22:40.833 ] [ ERROR] - Résultats attendus de getGroupById, mais rien n'a été obtenu

createGroup

createGroup envoie un groupe au connecteur pour qu'il soit créé. Il teste la méthode SCIMService.createGroup du connecteur.

Si le même groupe existe au sein de votre système, vous devrez lever une exception DuplicateGroupException.

Le test ci-dessous envoie une requête à votre connecteur SCIM pour lui demander de créer le groupe et de le renvoyer. Toutes les propriétés du groupe seront imprimées.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method createGroup -file data/createGroup.json

Réponse :

[ 17-10-2013 18:09:02.457 ] [ INFO] - requête POST faite à http://localhost:8080/Groups [ 17-10-2013 18:09:02.564 ] [ INFO] - Okta utilisera l'ID 1004 pour identifier ce groupe à l'avenir. [ 17-10-2013 18:09:02.564 ] [ INFO] - Groupe retourné du connecteur : schémas : "urn:scim:schemas:core:1.0", "urn:okta:custom:group:1.0" Id : "1004" Membres : Valeur : "User-003" Affichage : "Third User" Valeur : "User-004" Affichage : "Fourth User" Valeur : "User-005" Affichage : "Fifth User" Nom d'afichage : "AppGroup-02" Urn :okta:custom:group:1.0: Description : "This is the second group" [ 17-10-2013 18:09:02.565 ] [ INFO] - OK!

L'exemple suivant montre le résultat lorsque le connecteur génère une DuplicateGroupException lorsqu'on lui demande de créer un groupe :

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method createGroup -file data/createGroup.json

Réponse :

[ 18-10-2013 10:29:49.473 ] [ INFO] - requête POST faite à http://localhost:8080/Groups [ 18-10-2013 10:29:49.576 ] [ WARN] - état d'erreur 409 reçu de http://localhost:8080/Groups [ 18-10-2013 10:29:49.577 ] [ ERROR] - Impossible de créer le groupe [{ "schemas": ["urn:scim:schemas:core:1.0", "urn:okta:custom:group:1.0"], "displayName": "AppGroup-02", "id" : "1004", "membres" : [{"valeur" : "User-003", "affichage" : "Third User"},{"valeur" : "User-004", "affichage" : "Fourth User"},{"value": "User-005", "affichage" : "Fifth User"}], "urn :okta:custom:group:1.0":{ "description" :"Il s'agit du deuxième groupe" } }]. Il y a déjà [ 18-10-2013 10:29:49.577 ] [ ERROR] - Groupe en double trouvé. Impossible de créer le groupe

updateGroup

updateGroup envoie un groupe au connecteur pour qu'il soit mis à jour. Il teste la méthode SCIMService.updateGroup du connecteur.

Le test suivant envoie une requête à votre connecteur SCIM pour lui demander de mettre à jour le groupe et de le renvoyer.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method updateGroup -file data/updateGroup.json

Réponse :

[ 17-10-2013 18:11:11.842 ] [ INFO] - requête PUT faite à http://localhost:8080/Groups/1002 [ 17-10-2013 18:11:11.939 ] [ INFO] - NOTE : updateGroup ne retourne pas le groupe retourné par le connecteur à Okta. Okta suppose qu'une réponse non erronée de votre connecteur signifie que les méthodes updateGroup ont réussi. [ 17-10-2013 18:11:11.939 ] [ INFO] - OK!

deleteGroup

deleteGroup envoie un ID au connecteur afin que le groupe correspondant à cet ID puisse être supprimé. Il teste la méthode SCIMService.deleteGroup du connecteur. Il requiert la propriété supplémentaire suivante : id.

Utilisez EntityNotFoundException si un groupe ayant l'ID spécifié n'existe pas.

Le test suivant envoie une requête à votre connecteur SCIM pour lui demander de supprimer le groupe.

$ java -jar scim-sdk-tests.jar -url http://localhost:8080 -method deleteGroup -arg id=1003

Réponse :

[ 17-10-2013 18:16:27.553 ] [ INFO] - requête DELETE faite à http://localhost:8080/Groups/1003 [ 17-10-2013 18:16:27.646 ] [ INFO] - NOTE : deleteGroup ne retourne aucune donnée à Okta. Okta suppose qu'une réponse sans erreur de votre connecteur signifie que le groupedeleteGroup a réussi et que le groupe avec l'ID 1003 a été supprimé. [ 17-10-2013 18:16:27.646 ] [ INFO] - OK

Étapes suivantes

Se connecter à un connecteur SCIM