Authentifizierung für REST- und SOAP-Aufrufe
Es ist ratsam, Anmeldeberechtigungsnachweise in einer gesonderten Datei zu speichern und die Nachweise von Ihrer Anwendung während der Authentifizierung aufrufen zu lassen. Bei dieser Vorgehensweise ist es nicht notwendig, bei jeder Änderung Ihrer Berechtigungsnachweise den Code Ihrer Anwendung zu modifizieren. Eine alternative Herangehensweise ist das direkte Hinzufügen der Berechtigungsnachweise zu Ihrer Anwendung. Dabei können sich jedoch Fehler in den Code einschleichen. Zudem müssen Sie die Anwendung bei jeder Aktualisierung der Berechtigungsnachweise neu implementieren.
Das Cloudportal bietet zwei Arten von Berechtigungsnachweisen an:
- Serviceberechtigungsnachweise: Diese Berechtigungsnachweise unterliegen nicht den Kennworterneuerungsrichtlinien des Cloudportals. Die Nachweise sind nur für den Aufruf von REST- und SOAP-APIs gültig. Benutzer können sie nicht verwenden, um sich am Portal oder seinen Komponenten anzumelden.Hinweis: Operational Decision Manager on Cloud unterstützt SOAP 1.1. Spätere SOAP-Versionen werden nicht unterstützt.
- Lokale Konten: Diese Benutzerkonten verwenden Berechtigungsnachweise, die den Richtlinien für Kennworterneuerung des Cloudportals unterliegen. Benutzer und Anwendungen können diese Berechtigungsnachweise verwenden, um sich am Portal und seinen Komponenten anzumelden.
Verwenden Sie für die Authentifizierung Ihrer Anwendungen Serviceberechtigungsnachweise. Diese Nachweise bieten einen besseren Schutz und ermöglichen Ihnen, eigene Richtlinien für die Aktualisierung von Anmeldeberechtigungsnachweisen anzuwenden.
SAML-Benutzer
Für die Authentifizierung eines Entscheidungsservice können Sie keine SAML-Anmeldeberechtigungsnachweise verwenden. Wenn Sie SAML für die Anmeldung beim Cloudportal verwenden, müssen Sie Serviceberechtigungsnachweise für REST-oder SOAP-Aufrufe anfordern. IBM® interne Benutzer verwenden automatisch SAML für die Anmeldung am Portal und müssen Serviceberechtigungsnachweise anfordern.
Serviceberechtigungsnachweise aufrufen
Nachfolgend ist beschrieben, wie Sie Ihre Anwendung so einrichten, dass sie Serviceberechtigungsnachweise aus einer gesonderten Datei aufruft. Je nach IT-Strategie können Sie anstelle der Serviceberechtigungsnachweise auch die Berechtigungsnachweise eines lokalen Kontos verwenden.
- Erfragen Sie Ihre Serviceberechtigungsnachweise bei Ihrem Cloudadministrator. Nur ein Cloudadministrator kann Serviceberechtigungsnachweise generieren. Die Serviceberechtigungsnachweise umfassen eine Funktions-ID und ein Kennwort.
- Speichern Sie die Serviceberechtigungsnachweise in einer Eigenschaftendatei, z. B. sc.properties:
odmoc.url=https://mytenant.bpm.ibmcloud.com/odm/dev odmoc.functionalId=api1.fid@t1023 odmoc.password=xfmptNJsQONCvRXB1bYS1AxlIcYyh1UR2y/LMpyxDie Eigenschaften in diesem Beispiel sind wie folgt definiert:
Eigenschaft Beschreibung odmoc.urlURL Ihres Cloudportalnutzers odmoc.functionalIdFunktions-ID der Serviceberechtigungsnachweise odmoc.passwordKennwort der Serviceberechtigungsnachweise - Fügen Sie in Ihrer Anwendung den Code hinzu, der die Serviceberechtigungsnachweise aus der Datei sc.propertiesaufruft. Der folgende Code stammt aus einem Java™ -Client:
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); } } }
Die HTTP-Clientseite kann während der Authentifizierung die folgenden Codes zurückgeben:
| Code erstellen | Beschreibung |
|---|---|
Code 200 |
Dieser Code zeigt ein korrektes Ausführungsergebnis an. Das zurückgegebene Ergebnis ist die Antwort auf den API-Aufruf. Sie können auch bei falschen Berechtigungsnachweisen den Code 200 empfangen, wenn die Umleitungshandhabung nicht inaktiviert ist. Für eine ordnungsgemäße Diagnose von Verbindungsproblemen müssen Sie die Umleitungshandhabung inaktivieren. |
Code 302 |
Die HTTP-Anforderung gibt Code 302 zurück, wenn die Funktions-ID oder das Kennwort falsch oder das Konto gesperrt ist. Der Code gibt keine Ursache für den Authentifizierungsfehler an. Wenn das Konto gesperrt ist, können Sie eine Stunde warten. Danach wird das Konto automatisch wieder freigegeben. Falls das Konto nicht automatisch freigegeben wird, wenden Sie sich an Ihren Cloudadministrator. Dieser Code wird zurückgegeben, wenn die Umleitungshandhabung inaktiviert ist. |
Code 401 |
Sie empfangen diesen Code, wenn die Berechtigungsnachweise korrekt sind, Ihnen aber keinen Zugriff auf die URL gewähren. Sie müssen die erforderliche Autorisierung bei Ihrem Cloudadministrator anfordern. (Hinweis: Dieser Code wird zurzeit nicht zurückgegeben, könnte aber künftig bei einer Erweiterung der Autorisierung zurückgegeben werden.) |
| Andere Codes | Wenn Sie weiteren Code erhalten, wenden Sie sich an IBM , um Unterstützung zu erhalten (siehe Fehlerbehebung und Unterstützung). |