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 à l'Admin Console et sélectionnez Paramètres > Té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.

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.

Méthodes

GET /Users?filter=userName=myemail@domain.com&startIndex=1&count=100

POST /Users

POST /Users

GET /Users?startIndex=1&count=100

GET /Users?filter=userName=myemail@domain.com&startIndex=1&count=100

GET /Users/<Id>

PUT /Users/<id>

PUT /Users/<id>

PUT /Users/<id>

PUT /Users/<id>

PUT /Users/<id>

DELETE /Groups/<id>

PUT /Groups/<id>

POST /Groups

GET /Groups/<id>

GET  /Groups?startIndex=1&count=100

GET /ServiceProviderConfigs

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

• createPendingUser

• downloadUsers

• checkUserExists

• importUserProfile

• activateUser

• deactivateUser

• reactivateUser

• pushPasswordUpdate

• pushProfileUpdate

• downloadGroups

• getGroupById

• createGroup

• updateGroup

• deleteGroup

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] - making POST request to http://localhost:8080/Users
            [ 04-10-2013 13:23:01.449 ] [ INFO] - Okta will use the ID 103 to identify this User in the future.
            [ 04-10-2013 13:23:01.450 ] [ INFO] - User returned from connector:
            schemas: "urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:enterprise:1.0"
            phoneNumbers:
            value: "123-444-5555"
            type: "mobile"
            userName: "myemail@domain.com"
            name:
            familyName: "LastName"
            givenName: "FirstName"
            active: true
            emails:
            primary: true
            value: "myemail@domain.com"
            type: "primary"
            primary: false
            value: "mypersonalemail@domain.com"
            type: "secondary"
            password: "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, à ceci près que le champ active pour tous les utilisateurs est false.

$ 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] - making GET request to http://localhost:8080/Users?startIndex=1&count=100
            [ 04-10-2013 14:14:19.003 ] [ INFO] - downloadUsers: 3 Users returned.
            [ 04-10-2013 14:14:19.007 ] [ INFO] - downloadUsers: Users returned from connector logged to 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 ayant myemail@domain.com comme userName.

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] - making GET request to http://localhost:8080/Users?filter=userName%20eq%20%22myemail%40dom...
            [ 03-10-2013 14:54:16.846 ] [ INFO] - checkUserExists: No users returned from server. This should be expected.
            [ 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] - making GET request to http://localhost:8080/Users?filter=userName%20eq%20%22myemail%40dom...
            [ 03-10-2013 14:57:41.319 ] [ ERROR] - Expected results from checkUserExists but did not get anything.

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] - making GET request to http://localhost:8080/Users?filter=id%20eq%20%22102%22&startInd...
[ 03-10-2013 15:01:14.217 ] [ INFO] - checkUserExists: 1 users returned.
[ 03-10-2013 15:01:14.217 ] [ INFO] - checkUserExists: User returned from Connector:
schemas: "urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:enterprise:1.0", "urn:okta:onprem_app:1.0:user"
id: "102"
userName: "admin"
name:
formatted: "SCIM firstname2 SCIM lastname2"
givenName: "SCIM first2"
familyName: "SCIM last2"
middleName: "SCIM middle2"
emails:
value: "SCIM_admin@okta.com"
primary: true
type: "work"
active: false
password: "fakepassword"
groups:
value: "1002"
display: "secondGroup"
urn:okta:onprem_app:1.0:user:
isAdmin: true
isOkta: false
departmentName: "Administration"
[ 03-10-2013 15:01:14.217 ] [ INFO] - checkUserExists: The ID 102 will be used as the id for this user in Okta
[ 03-10-2013 15:01:14.217 ] [ INFO] - checkUserExists: The user will be returned as INACTIVE
[ 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] - making GET request to http://localhost:8080/Users/101
            [ 04-10-2013 13:57:54.203 ] [ INFO] - importUserProfile: User returned from Connector:
            schemas: "urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:enterprise:1.0", "urn:okta:onprem_app:1.0:user"
            id: "101"
            userName: "okta"
            name:
            formatted: "SCIM firstname SCIM lastname"
            givenName: "SCIM first"
            familyName: "SCIM last"
            middleName: "SCIM middle"
            emails:
            value: "SCIM_okta@okta.com"
            primary: true
            type: "work"
            active: true
            password: "inSecure"
            groups:
            value: "1001"
            display: "firstGroup"
            value: "1002"
            display: "secondGroup"
            urn:okta:onprem_app:1.0:user:
            isAdmin: false
            isOkta: true
            departmentName: "Cloud Service"
            [ 04-10-2013 13:57:54.204 ] [ INFO] - importUserProfile: The ID 101 will be used as the id for this user in 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] - making GET request to http://localhost:8080/Users/invalidExternalId
            [ 04-10-2013 14:00:01.245 ] [ WARN] - error status of 404 received from http://localhost:8080/Users/invalidExternalId
            [ 04-10-2013 14:00:01.245 ] [ INFO] - importUserProfile: No users returned from server. This should be expected.
            [ 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] - making GET request to http://localhost:8080/Users/103
            [ 04-10-2013 14:00:52.191 ] [ WARN] - error status of 404 received from http://localhost:8080/Users/103
            [ 04-10-2013 14:00:52.191 ] [ ERROR] - Expected results from importUserProfile but did not get anything.
        

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] - making PUT request to http://localhost:8080/Users/101
            [ 10-10-2013 14:29:00.598 ] [ INFO] - activateUser: will return to Okta that the user's active state is: true
            [ 10-10-2013 14:29:00.598 ] [ INFO] - OK!
        

deactivateUser

deactivateUser demande à votre connecteur d'activer 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] - making PUT request to http://localhost:8080/Users/101
[ 10-10-2013 14:32:52.171 ] [ INFO] - NOTE: deactivateUser does not send the user returned from the connector back to Okta. Okta assumes that a
                                            non-error response from your connector means the deactivateUser methods was successful.
[ 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] - making PUT request to http://localhost:8080/Users/101
[ 10-10-2013 14:35:04.828 ] [ INFO] - NOTE: reactivateUser does not send the user returned from the connector back to Okta. Okta assumes that a
                                            non-error response from your connector means the reactivateUser methods was successful.
[ 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] - making PUT request to http://localhost:8080/Users/101
[ 10-10-2013 14:36:52.124 ] [ INFO] - NOTE: pushPasswordUpdate does not send the user returned from the connector back to Okta. Okta assumes that a
                                            non-error response from your connector means the pushPasswordUpdate methods was successful.
[ 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] - making PUT request to http://localhost:8080/Users/101
[ 10-10-2013 14:39:44.785 ] [ INFO] - NOTE: pushProfileUpdate does not send the user returned from the connector back to Okta. Okta assumes that a
                                            non-error response from your connector means the pushProfileUpdate methods was successful.
[ 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] - making GET request to http://localhost:8080/Groups?startIndex=1&count=100
            [ 10-10-2013 14:40:55.816 ] [ INFO] - downloadGroups: 2 Groups returned.
            [ 10-10-2013 14:40:55.819 ] [ INFO] - downloadGroups: Groups returned from connector logged to 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] - making GET request to http://localhost:8080/Groups/1002
            [ 17-10-2013 18:03:17.381 ] [ INFO] - getGroupById : Group returned from connector:
            schemas: "urn:scim:schemas:core:1.0", "urn:okta:custom:group:1.0"
            id: "1002"
            members:
            value: "User-001"
            display: "First User"
            value: "User-002"
            display: "Second User"
            displayName: "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] - making GET request to http://localhost:8080/Groups/3455
            [ 18-10-2013 10:22:40.833 ] [ WARN] - error status of 404 received from http://localhost:8080/Groups/3455
            [ 18-10-2013 10:22:40.833 ] [ ERROR] - Expected results from getGroupById but did not get anything.
        

createGroup

createGroup envoie un groupe au connecteur en vue de sa création. 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] - making POST request to http://localhost:8080/Groups
            [ 17-10-2013 18:09:02.564 ] [ INFO] - Okta will use the ID 1004 to identify this Group in the future.
            [ 17-10-2013 18:09:02.564 ] [ INFO] - Group returned from connector:
            schemas: "urn:scim:schemas:core:1.0", "urn:okta:custom:group:1.0"
            id: "1004"
            members:
            value: "User-003"
            display: "Third User"
            value: "User-004"
            display: "Fourth User"
            value: "User-005"
            display: "Fifth User"
            displayName: "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] - making POST request to http://localhost:8080/Groups
[ 18-10-2013 10:29:49.576 ] [ WARN] - error status of 409 received from http://localhost:8080/Groups
[ 18-10-2013 10:29:49.577 ] [ ERROR] - Cannot create the group [{
  "schemas": ["urn:scim:schemas:core:1.0", "urn:okta:custom:group:1.0"],
  "displayName": "AppGroup-02",
  "id": "1004",
  "members" : [{"value": "User-003", "display": "Third User"},{"value": "User-004", "display": "Fourth User"},{"value": "User-005",
                "display": "Fifth User"}],
  "urn:okta:custom:group:1.0":{
    "description":"This is the second group"
  }
}]. It already exists
[ 18-10-2013 10:29:49.577 ] [ ERROR] - Duplicate group found. Cannot create the group

updateGroup

updateGroup envoie un groupe au connecteur en vue de sa mise à 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] - making PUT request to http://localhost:8080/Groups/1002
[ 17-10-2013 18:11:11.939 ] [ INFO] - NOTE: updateGroup does not send the group returned from the connector back to Okta. Okta assumes that a
                                            non-error response from your connector means the updateGroup methods was successful.
[ 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] - making DELETE request to http://localhost:8080/Groups/1003
[ 17-10-2013 18:16:27.646 ] [ INFO] - NOTE: deleteGroup does not send any data back to Okta. Okta assumes that a non-error response from your connector
                                            means the deleteGroup was successful and the group with the Id 1003 was deleted
[ 17-10-2013 18:16:27.646 ] [ INFO] - OK

Étapes suivantes

Se connecter à un connecteur SCIM