Authentifizierung für REST- und SOAP-Aufrufe

Das Cloudportal unterstützt die Verwendung der Basisauthentifizierung beim Aufrufen von REST-und SOAP-APIs. Sie sollten Anmeldeberechtigungsnachweise nicht fest in Ihrer Anwendung codieren, sondern die Nachweise per Pull-Operation aus einer gesonderten Datei übertragen.

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.
Tipp:

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.

  1. Erfragen Sie Ihre Serviceberechtigungsnachweise bei Ihrem Cloudadministrator. Nur ein Cloudadministrator kann Serviceberechtigungsnachweise generieren. Die Serviceberechtigungsnachweise umfassen eine Funktions-ID und ein Kennwort.
  2. 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/LMpyx

    Die Eigenschaften in diesem Beispiel sind wie folgt definiert:

    Eigenschaft Beschreibung
    odmoc.url URL Ihres Cloudportalnutzers
    odmoc.functionalId Funktions-ID der Serviceberechtigungsnachweise
    odmoc.password Kennwort der Serviceberechtigungsnachweise
  3. 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).