Authentification pour les appels REST et SOAP
Il est conseillé de conserver les identifiants de connexion dans un fichier à part et de les appeler depuis l'application au moment où se déroule le processus d'authentification. Avec cette approche, nul besoin de modifier le code de votre application chaque fois que vous changez vos identifiants. L'autre approche serait d'ajouter les identifiants directement à l'application, mais cela risquerait d'introduire des données erronées dans le code et obligerait à redéployer l'application à chaque changement des identifiants.
Le portail cloud offre deux types d'identifiants :
- Identifiants de service : les identifiants de ce type échappent à la politique de renouvellement des mots de
passe du portail cloud. Leur validité est limitée aux appels des API REST et SOAP. Les utilisateurs ne peuvent pas les utiliser pour se connecter au portail ou à ses composants.Remarque: Operational Decision Manager on Cloud prend en charge SOAP 1.1. Il ne prend pas en charge les versions ultérieures de SOAP.
- Comptes locaux : ces comptes d'utilisateur ont des données d'identification (combinaisons d'un nom d'utilisateur et d'un mot de passe) soumises à la politique de renouvellement des mots de passe du portail cloud. Les utilisateurs et les applications peuvent utiliser ces données d'identification pour se connecter au portail et à ses composants.
Authentifiez vos applications en utilisant de préférence des identifiants de service. Ils offrent un meilleur niveau de sécurité et peuvent être mis à jour selon votre propre politique de renouvellement.
Utilisateurs SAML
Il n'est pas possible d'utiliser les identifiants de connexion SAML pour authentifier un service de décision. Si vous utilisez SAML pour vous connecter au portail cloud, vous devez demander des données d'identification de service pour l'appel REST ou SOAP. Les utilisateurs internes d' IBM® utilisent automatiquement SAML pour se connecter au portail et doivent demander des données d'identification de service.
Appel des identifiants de service
Les étapes suivantes montrent comment configurer votre application pour qu'elle aille chercher les identifiants de service dans un fichier à part. Selon votre stratégie des TI, vous pouvez utiliser les identifiants d'un compte local à la place des identifiants de service.
- Obtenez vos identifiants de service auprès de votre administrateur cloud. Seul un administrateur cloud peut générer des identifiants de service. Les identifiants de service incluent un ID fonctionnel et un mot de passe.
- Placez les identifiants de service dans un fichier de propriétés ; par exemple, sc.properties :
odmoc.url=https://mytenant.bpm.ibmcloud.com/odm/dev odmoc.functionalId=api1.fid@t1023 odmoc.password=xfmptNJsQONCvRXB1bYS1AxlIcYyh1UR2y/LMpyxDans cet exemple, les propriétés sont définies comme suit :
Propriété Description odmoc.urlL'URL de votre locataire ("tenant") du portail cloud odmoc.functionalIdLa partie ID fonctionnel des identifiants de service odmoc.passwordLa partie mot de passe des identifiants de service - Dans votre application, ajoutez le code servant à obtenir les identifiants de service du fichier sc.properties. Le code suivant provient d'un client Java™ :
package test; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.util.Properties; import org.apache.commons.codec.binary.Base64; import org.apache.http.HttpResponse; import org.apache.http.Header; import org.apache.http.client.HttpClient; import org.apache.http.client.methods.HttpGet; import org.apache.http.conn.ssl.NoopHostnameVerifier; import org.apache.http.conn.ssl.TrustSelfSignedStrategy; import org.apache.http.impl.client.HttpClientBuilder; import org.apache.http.impl.client.HttpClients; import org.apache.http.ssl.SSLContextBuilder; import org.apache.http.util.EntityUtils; import com.ibm.json.java.JSONObject; public class OdmRestClient { public static void main(String[] args) throws Exception { // The builder should be configured to connect using HTTPS to ODM on Cloud, // and must use a secure cipher with hostname verification. The following // code does not reflect all the required settings. HttpClientBuilder builder = HttpClients.custom(); builder.disableRedirectHandling(); HttpClient client = builder.build(); // This code calls the service credentials from the file sc.properties. //It reads the url, functional Id and password from a property file. String configFile = "sc.properties"; FileInputStream fistream = null; try { fistream = new FileInputStream(configFile); } catch (FileNotFoundException e) { System.out.println("Could not open file: " + configFile); System.exit(0); } Properties props = new Properties(); props.load(fistream); String baseurl = props.getProperty("odmoc.url"); String fid = props.getProperty("odmoc.functionalId"); String pwd = props.getProperty("odmoc.password"); String url = baseurl + "/res/api/v1/ruleapps?count=true"; // Basic Authentication header value String baHeader = fid + ":" + pwd; System.out.println("BA header is: " + baHeader); baHeader = Base64.encodeBase64String(baHeader.getBytes()); // execute request HttpResponse response = null; System.out.println("** Calling: " + url); HttpGet request = new HttpGet(url); request.setHeader("Authorization", "Basic " + baHeader); try { response = client.execute(request); } catch (Exception e) { throw new Exception("Could not execute API call, reason: " + e.getMessage()); } int httpRespCode = response.getStatusLine().getStatusCode(); System.out.println("Response code is: " + httpRespCode); if (httpRespCode==302) { // We are in one of these 3 cases: wrong ID, wrong password, account locked System.out.println("Basic auth access denied."); System.out.println("Reason1: Wrong ID or password"); System.out.println("Reason2: Account locked after some unsuccessful attempts"); } else if (httpRespCode==401) { // Aithorization is not granted to access the URL System.out.println("ODM API access was denied: you are not authorized"); } else if (httpRespCode==200){ // Correct execution result, extract the HTTP response String json = EntityUtils.toString(response.getEntity(), "UTF-8"); System.out.println("Successful invocation, result : " + json); } else { // Diagnose why such a code. Contact IBM support with all the details. System.out.println("Unexpected return code: " + httpRespCode); } } }
Le côté client HTTP peut retourner les codes suivants lors de l'authentification :
| Coder | Description |
|---|---|
Code 200 |
Ce code indique un résultat d'exécution correct. Le résultat renvoyé est la réponse proprement dite à l'appel d'API. Il est possible d'obtenir un code 200 même avec des données d'identification incorrectes si le traitement des redirections n'a pas été désactivé. Désactivez ce traitement pour diagnostiquer précisément un problème de connexion. |
Code 302 |
La demande HTTP retourne le code 302 si l'ID fonctionnel ou le mot de passe sont incorrects ou si le compte est bloqué. Le code ne fournit pas la cause de l'échec d'authentification. Si le compte est bloqué, il est possible qu'il soit débloqué automatiquement après une heure. Si le compte n'est pas débloqué automatiquement passé ce délai, contactez votre administrateur de cloud. Ce code est retourné lorsque le traitement des redirections est désactivé. |
Code 401 |
Ce code est obtenu lorsque les identifiants sont corrects mais n'autorisent pas l'accès à l'URL. Vous devez demander à votre administrateur cloud d'accorder les autorisations requises. (Notez que ce code n'est pas actuellement retourné, mais qu'il pourrait l'être dans le futur si le mécanisme d'autorisation bénéficie d'évolutions dans une prochaine version du produit.) |
| Autres codes | Si vous obtenez un autre code, contactez IBM pour obtenir de l'aide (voir Identification des incidents et support). |