Verwalten von Webservices

Dieser Artikel enthält die folgenden Themen:
casm173
Dieser Artikel enthält die folgenden Themen:
Bei
Webservices
handelt es sich um einen Satz von Datenaustauschstandards für die Kommunikation zwischen Produkten, die sich in unterschiedlichen Betriebsumgebungen befinden können. Dies verhält sich analog zum Browsen im Internet vom PC aus: Es kann auf alle Remote-Websites zugegriffen werden, unabhängig davon, ob diese sich auf Solaris-, AIX-, Windows- oder anderen Hosts befinden. Auf die gleiche Weise können Produkte mithilfe von Webservices über HTTP mit unterschiedlichen Servern kommunizieren, und zwar unabhängig von der Betriebsumgebung. So kann z. B. eine Microsoft Office-Anwendung mit einem Programm auf einem UNIX-Server kommunizieren, und eine Java-Serverseite hat Zugriff auf einen Server, der unter Windows gehostet wird. Dank dieser plattformunabhängigen Kommunikation sind umfassende Integrationsmöglichkeiten gegeben.
Die WebServices nutzen diese Technologie und ermöglichen fast jedem Produkt den Zugriff auf CA SDM und Knowledge Management. Webservices-Clients können Tickets erstellen, Assets aktualisieren, die Knowledge Base durchsuchen und vieles mehr.
Weitere Informationen zu WebServices finden Sie in der CA SDM-Referenz.
CA SDM-Komponenten
CA SDM stellt die Installationsdateien für diese Version von J2EE-Webservices im folgenden Verzeichnis bereit:
<NX_ROOT>/sdk/websvc/R11
<NX_ROOT> gibt den Stamminstallationspfad für CA SDM an.
Webserviceoptionen
Diese Optionen steuern die Webservice-Sitzung:
  • rest_webservice_access_duration
    Gibt die Anzahl der Stunden an, die der REST-Webservice-Zugriffsschlüssel vor Ablauf aktiv bleibt. Das Zeitlimit des Zugriffsschlüssels basiert nicht auf Inaktivitätszeit, sondern auf den Zeitraum seit der Erstellung des Zugriffsschlüssels. Nachdem der Zugriffsschlüssel die angegebene Dauer erreicht hat, endet der Zugriffsschlüssel, unabhängig davon, ob er verwendet wird.
    Optional kann der REST-Client auch den Zeitraum für den Zugriffsschlüssel für den bestimmten Zugriffsschlüssel während der Zugriffsschlüssel-Request angeben. Um den Zeitraum anzugeben, legen Sie ihn direkt im Attribut "expiration_date" der Ressource "rest_access" als Inhaltsteil der POST-Request fest.
    Gültiger Bereich:
    1-8760 Stunden
    Standard
    : 168
  • rest_webservice_disable_basic_auth
    Deaktiviert Basisauthentifizierung in REST-Webservices.
    Standardwert
    : Nein
  • rest_webservice_list_max_length
    Gibt die maximale Anzahl der Zeilen an, die eine REST-Webservice-Abfrage zurückgibt.
    Standard
    : 500
  • rest_webservice_list_page_length
    Gibt die standardmäßige Anzahl der Zeilen an, die eine REST-Webservice-Abfrage pro Seite zurückgibt.
    Gültiger Bereich
    : 1 - 500
    Standard
    : 25
  • rest_webservice_resources_to_expose
    Gibt die Liste von Majic-Factorys (Ressourcen) an, die CA SDM über REST-Webservices zur Verfügung stellt. Diese Option überschreibt das Standardverhalten. Standardmäßig stellt CA SDM alle Factorys über REST-Webservices zur Verfügung.
    Wenn Sie keine Werte in diese Option eingeben, stellt das Standardverhalten eine beliebige Majic-Factory zur Verfügung, bei der die Eigenschaft "REST_OPERATIONS" nicht auf "NONE" festgelegt ist. Standardmäßig ist bei keiner Majic-Factory diese Eigenschaft auf "NONE" festgelegt.
    Verwenden Sie die Eigenschaft "REST_OPERATIONS", um die bestimmten HTTP-CRUD-Methoden (CREATE, READ, UPDATE, DELETE) festzulegen, die CA SDM auf einer bestimmten Majic-Factory zur Verfügung stellt.
    Standard
    : rest_access
    Beispiel:
    rest_access, cnt, grp, cr, crs, pri, alg, urg, imp, pcat, org
  • hmac_algorithm
    Gibt den Algorithmus an, den Sie verwenden, um die Signatur für "Custom/Secret Key Auhentication" in REST-Webservices zu berechnen.
    Standard:
    HmacSHA1
  • string_to_sign_fields
    Gibt die Felder an, die Sie verwenden, um die Signatur für "Custom/Secret Key Auhentication" in REST-Webservices zu berechnen, zusätzlich zu den Standardfeldern "REQUEST_METHOD", "REQUEST_URI" und "QUERY_STRING".
    Standard:
    Leer
  • webservice_domsrvr
    Gibt den Namen der Objekt-Engine an, die von den SOAP-Webservices verwendet wird. Falls diese Option nicht installiert ist, wird von den SOAP-Webservices "domsrvr" verwendet.
    Der Wert der Option muss aus einer Zeichenfolge bestehen, die mit den Zeichen "domsrvr:" beginnt.
  • webservice_session_timeout
    Legt den Wert für die Zeitüberschreitung (in Minuten) für SOAP-Webservice-Sitzungen fest. Wenn die Zeit zwischen aufeinanderfolgenden Web-Methoden-Aufrufe größer ist als der angegebene Wert, dann wird die Sitzungs-ID als abgelaufen markiert. Die Sitzung ist dann nicht mehr gültig.
    Um Sitzungen vor dem Ablauf aufgrund von Aktivität zu bewahren, setzen Sie den Wert dieser Option auf 0 (Null). Andere Methoden, wie z. B. Abmelderoutinen, können Sitzungen weiterhin ungültig machen.
Diese Optionen erfordern einen Neustart des CA SDM-Servers.
Installation von Webservices
Abhängig von Ihrem Konfigurationstyp installiert CA DSM Webdienste für folgende Server:
  • Konventionell: Sowohl Primärserver als auch Sekundärserver. Damit Webservice-Clients eine URL auf einem Sekundärserver verwenden können, fügen Sie dem Sekundärserver eine Web-Engine hinzu.
  • Erweiterte Verfügbarkeit: Anwendungsserver
Webservices verwenden den Standard-Objekt-Manager, der auf dem CA SDM-Server installiert ist. Um einen anderen Objektmanager zu verwenden, installieren Sie diesen, und stellen Sie im Optionsmanager die Option
webservice_domsrvr
ein.
Informationen zum Hinzufügen und Konfigurieren von Objektmanager, Web-Directors und Web-Engines finden Sie im Abschnitt Optionsmanager.
Aktivieren der Entwicklungszeit
Die Webservices von CA SDM umfassen eine Methodenkonfigurationsfunktion für Entwickler in der Java-Version. Ist diese aktiviert, ignorieren die Webservices den CA SDM-Server und geben simulierte Daten für Methodenaufrufe zurück, damit Webservices-Aufrufe ohne Ausführung eines CA SDM-Servers möglich sind.
Gehen Sie folgendermaßen vor:
  1. Bearbeiten Sie "deploy.wsdd", um die Kommentare der Abschnitte für "design_mode_stubs" zu entfernen.
  2. Kehren Sie die Bereitstellung um, und stellen Sie den Server erneut bereit.
  3. Starten Sie den Anwendungsserver neu.
    Die Entwicklungszeitfunktion wird aktiviert.
Die Entwicklungszeitfunktion gilt ausschließlich für die Webservices-Methoden von CA SDM.
Sicherheit von Webservices
Wenn Sie Webservices bereitstellen, sollten Sie sich mit den wichtigen Sicherheitsüberlegungen vertraut machen. Die Standardkonfiguration bei der Verwendung von HTTP ist unsicher, da sie für alle Daten in Webservice-Aufrufen verwendet wird, die zwischen Client und Server im Nur-Text-Format mit dem HTTP-Protokoll über ein Netzwerk übertragen werden. Eingeschlossen sind nicht nur Anwendungsdaten wie Ticket-Beschreibungen und Kontaktnamen, sondern auch Sitzungs-IDs für Web Services (SID). Je nach den verwendeten Anmeldemethoden für Web Service-Anwendungen können auch Kennwörter dazugehören.
Wir empfehlen, dass Administratoren, die Webservices bereitstellen, diesen Abschnitt gründlich lesen und zusätzliche Konfigurationsschritte auf der Anwendungs- und der Netzwerkebene ausführen, um die Sicherheit der Webservice-Umgebung zu gewährleisten.
Die Standardkonfiguration für Webservices mit HTTP ist unsicher und anfällig für Sicherheitsbedrohungen wie Kennwortermittlung, Session Fixation und Datenspionage.
Beim Bereitstellen von Webservices sind drei wichtige Sicherheitsüberlegungen zu berücksichtigen, die in einer Wechselbeziehung stehen:
  • Welche Arten der Zugriffsauthentifizierung (Anwendungsebene) soll diese Bereitstellung unterstützen?
  • Welche zusätzlichen Sicherheitsfunktionen auf Netzwerkebene erfordert diese Bereitstellung?
  • Wie werden diese Erfordernisse durch die Web Services-Konfigurationsoptionen durchgesetzt?
Im Folgenden werden die einzelnen Sicherheitsfunktionen beschrieben:
  • Webservice-Authentifizierungsschemata auf Anwendungsebene
    - Für den Zugriff auf Webservices muss eine Webservice-Clientanwendung mit der Webservice-Anwendung authentifiziert werden. Die Webservices bieten zwei Arten der Zugriffsauthentifizierung. Die erste erfordert die Angabe von Anwendername und Kennwort, während die zweite die PKI-Technologie (Public Key Infrastructure) nutzt. Für beide Arten wird die Zugriffssteuerungs- und -verwaltungskomponente in den Webservices unter Verwendung von Zugriffsrichtlinien herangezogen. Zugriffsauthentifizierung und Zugriffsverwaltung sind die wichtigsten Sicherheitsfunktionen von Webservices.
    Die Authentifizierung über Anwendernamen/Kennwort kann mithilfe des folgenden Sicherheitskonfigurationbefehls deaktiviert werden:
    disable_user_logon
    Vor dem Aktivieren dieser Option muss der Administrator bestimmen, ob jeder Web Service-Client, für den ein Unternehmen den Zugriff auf Web Services anfordert, die alternative Authentifizierungsmethode (die PKI-basierte Anmeldemethode) tatsächlich unterstützt. Der Hauptvorteil der PKI-Technologie besteht darin, dass Webservices-Clientanwendungen keine
    verwalteten
    Systemanwenderkonten erfordern, d. h. ohne Verwaltung, Speicherung und Übertragung ihrer Kennwörter auskommen.
  • Sicherheitskonfiguration auf Netzwerkebene
    - In beiden Authentifizierungsschemata - Anwendername/Kennwort und Public Key Infrastructure (PKI) - wird die von der jeweiligen Anmeldemethode zurückgegebene Sitzungskennung (sowie alle folgenden Informationen) bei Verwendung von HTTP im Nur-Text-Format übertragen. Des Weiteren wird bei Verwendung des Authentifizierungsschemas Anwendername/Kennwort das Kennwort ungeschützt (im Nur-Text-Format) von der Web Service-Client-Anwendung an die Web Services gesendet. Während der Produktentwicklung lagen keine Empfehlungen des W3C zu Standards für die Webservices-Sicherheit vor. Daher wird WS-Security von diesen Webservices-Implementierungen nicht zur Schaffung eines Sicherheitskontexts verwendet. Stattdessen werden Point-to-Point-Protokolle wie SSL/TLS (Secure Sockets Layer/Transport Layer Security) und andere Sicherheitsmechanismen auf Netzwerkebene (zum Beispiel IPSec) empfohlen, um den Austausch von Authentifizierungsdaten auf Anwendungsebene und nachfolgend von Sitzungs-IDs und Daten, der andernfalls im Nur-Text-Format stattfinden würde, zu schützen.
    Beim Bereitstellen von Webservices wird SSL (oder HTTPS) empfohlen, um den Austausch von Authentifizierungsdaten auf Anwendungsebene und die nachfolgende Übertragung von Sitzungskennungen und Daten zu schützen.
  • Webservices- Konfiguration
    - Um Administratoren zu ermöglichen, die Sicherheit der Kommunikationsprotokollebene auf der Ebene der Webservices-Anwendung zu erzwingen, werden die beiden folgenden Befehle zur Sicherheitskonfiguration unterstützt:
    require_secure_logon
    Diese Sicherheitsfunktion macht SSL (oder HTTPS) für den Aufruf der Methoden „login()“ und „loginService()“ erforderlich. Diese Funktion bietet außerdem eine einfache Methode zum Schutz des Anwendernamens und des Kennworts, während der zusätzliche Aufwand einer Verwendung von SSL für alle anderen Webservices vermieden wird.
    Wenn Sie den Befehl "require_secure_logon" verwenden, bestätigt die Webservices-Anwendung nicht, dass die Sicherheit der Kommunikationsprotokollebene für andere Methoden als "Login()" und "LoginService()" durchgesetzt wird. Falls keine anderen Vorsichtsmaßnahmen getroffen werden, ist es möglich, dass die anderen Webservices-Methoden auf unsichere Weise aufgerufen werden, woraus sich eine größere Anfälligkeit gegenüber Sicherheitsbedrohungen ergibt.
    require_secure_connection
    Diese Sicherheitsfunktion macht die Verwendung von SLL für den Zugriff auf jeden beliebigen Teil der Web Services erforderlich. Sofern HTTPS erforderlich ist, aber nicht verwendet wird, wird ein SOAP-Fault mit dem Code „UDS_SECURE_CHANNEL_REQUIRED“ zurückgegeben.
    Weitere Informationen über die Konfiguration von SSL finden Sie in der Dokumentation zu J2EE-Servlet-Containern.
Verwenden der Webservices
Die Informationen in diesem Abschnitt beschreiben die Grundlagen zur Verwendung der Webservices von CA SDM. Beispielcode, in dem die Webservices verwendet werden, befindet sich im folgenden CA SDM-Installationsverzeichnis:
<NX_ROOT>/samples/sdk/websvc/java
Der Beispielcode wurde mit Apache Axis-for-SOAP-Messaging in Java geschrieben.
Anmeldungen
Bevor eine Webservices-Methode verwendet werden kann, muss eine SID (Sitzungs-ID) aus einer der folgenden Methoden abgerufen werden: "login()", "loginService()" und "loginServiceManaged()". Für die ersten beiden Methoden sind ein Benutzername und ein Kennwort erforderlich, die auf die gleiche Weise wie die CA SDM-Web-Schnittstelle validiert werden. Durch den Zugriffstyp des Kontakts wird die Validierungsmethode festgelegt. Für die dritte Methode ist ein Schlüsselpaar aus öffentlichem und privatem Schlüssel erforderlich, wobei anhand des privaten Schlüssels verschlüsselte Anmeldeanfragen nur mit dem öffentlichen Schlüssel entschlüsselt werden können und umgekehrt.
Durchführen allgemeiner Aufgaben
Die Webservices stellen eine flexible und leistungsstarke API in CA SDM bereit. Für ihre Verwendung sind aber gewisse Kenntnisse der vom Produkt verwendeten Objektstruktur erforderlich:
  1. Machen Sie sich mit den Informationen über Objekte und Attribute in CA Service Desk Manager-Informationen zu den Referenzbefehlen vertraut.
    In diesem Handbuch werden die Attribute der einzelnen Objekte im System aufgelistet, was sehr wichtig ist, da für viele der Webservices-Methoden Attributnamen erforderlich sind.
  2. Gehen Sie die Webservices-Methoden durch, insbesondere die generischen. Wenn Ihre Anwendung beispielsweise alle Aktivitätsprotokolle für einen Request anzeigen muss, ermitteln Sie zunächst, auf welche Art die Aktivitätsprotokolle mit dem Request verbunden sind.
    Im Abschnitt CA Service Desk Manager-Informationen zu den Referenzbefehlen ist
    ersichtlich, dass für das Request-Objekt zwei Listen von Aktivitätsprotokollen vorhanden sind: "act_log" (nur nicht interne Protokolle) und "act_log_all" (alle Aktivitätsprotokolle).
  3. Ermitteln Sie, welche Webservices-Methoden für Sie erforderlich sind. Um Listen abzurufen, die an ein Objekt angehängt sind, verwenden Sie „getRelatedList()“ oder „getRelatedListValues()“.
Standardkennungen
Einige im Produkt bereitgestellte Standarddaten werden häufig verwendet. Anstatt Kennungen für diese Objekte zu suchen, können Sie einige der häufiger verwendeten Kennungen in den folgenden Tabellen in Erfahrung bringen.
Während Kennungen unveränderlich sind, können die lesbaren Symbole bearbeitet werden.
Kontakttyp (Objektname: "ctp")
Kennung
Hinweis
ctp:2307
Der „Analytiker“-Typ
ctp:2310
Der „Kunde“-Typ
ctp:2305
Der „Mitarbeiter“-Typ
ctp:2308
Der „Gruppe“-Typ
Auswirkung (Objektname:"imp")
Kennung
Hinweis
imp:1605
Auswirkung „Keine“
imp:1600
Niedrige Auswirkung „5“
imp:1601
Mittlere bis niedrige Auswirkung „4“
imp:1602
Mittlere Auswirkung „3“
imp 1603
Mittlere bis hohe Auswirkung „2“
imp:1604
Hohe Auswirkung „1“
Priorität (Objektname: "pri")
Kennung
Hinweis
pri:505
Nicht zugewiesene Priorität „Keine“
pri:500
Niedrige Priorität „5“
pri:501
Mittlere bis niedrige Priorität „4“
pri:502
Mittlere Priorität „3“
pri:503
Mittlere bis hohe Priorität „2“
pri:504
Hohe Priorität „1“
Schweregrad (Objektname: "sev")
Kennung
Hinweis
sev:800
Niedriger Schweregrad „1“
sev:801
Mittlerer bis niedriger Schweregrad „2“
sev:802
Mittlerer Schweregrad „3“
sev:803
Mittlerer bis hoher Schweregrad „4“
sev:804
Hoher Schweregrad „5“
Aufrufanforderungstyp (Objektname: "crt")
Kennung
Hinweis
crt:180
Request
crt:181
Problem
crt:182
Incident (Störung)
Abfrage für einem Kontakt zugeordneten Anfragen, Issues oder Changes
Einer der häufigsten Vorgänge ist der Abruf der aktiven Anfragen, die einem Analysten (Zuständigen) zugewiesen sind. Sie können eine von mehreren Methoden verwenden, wie z. B. "doQuery()" (zum Abruf einer Listenreferenz) oder "doSelect()" (zum umgehenden Abruf der Werte). Unter der Annahme, dass die Kennung des Zuständigen bereits bekannt ist, ist folgende Where-Klausel zu verwenden:
assignee.id = U'<assigneeID>' AND active = 1
In dieser WHERE-Klausel ist "<assigneeID>" der ID-Teil einer Kontaktkennung, ein Wert wie z. B. "555A043EDDB36D4F97524F2496B35E75".
Diese Where-Klausel funktioniert für Anfragen, Changes und Issues, da sie alle die Attribute "assignee" und "active" aufweisen, die für alle drei Objekttypen die gleiche Bedeutung haben. Mit "active = 1" in der Where-Klausel werden Suchvorgänge auf aktive Anfragen beschränkt.
Die Markierung für aktive Elemente
Die meisten CA SDM-Objekte weisen das Feld "aktiv" oder "Delete_flag" auf. Hierbei handelt es sich um einen SREL-Verweis auf das Objekt „Active_Boolean_Table“ oder „Boolean_Table“. Ziehen Sie das Hinzufügen dieser Felder zu Ihren Abfragen in Betracht, um vom Systemadministrator als inaktiv markierte Objekte auszufiltern. Suchen Sie für Abfragezwecke nach „delete_flag = 0“, um aktive Datensätze zu finden, und „delete_flag = 1“, um inaktive Datensätze zu finden. Am Beispiel des folgenden Pseudocodes wird die Verwendung von "doSelect()" zum Abrufen von Werten für alle aktiven Anfragestatusobjekte veranschaulicht:
doSelect(SID, "crs", "delete_flag = 0", -1, new String[0]);
Um ein Objekt als aktiv oder inaktiv festzulegen, müssen Sie die Kennung des booleschen Objekts übergeben, die den Wert „True“ oder „False“ wiedergibt. Diese Kennungen sind unveränderlich und können damit bedenkenlos hartcodiert werden. Es handelt sich dabei um folgende Kennungen:
Active_Boolean_Table
Boolean_Table
actbool:4551 = 'Active'
bool:200 = 'False'
actbool:4552 = 'Inactive'
bool:201 = 'True'
Abrufen der Länge verbundener Listen
Beim Anfragen von Attributwerten aus einem Objekt, z. B. mit "getObjectValues()", können Sie die Länge der verbundenen Liste durch Anfragen des folgenden Attributs abrufen:
"<listName>.length"
Um beispielsweise die Anzahl der Aktivitätsprotokolle für eine bestimmte Anfrage zu erhalten, übergeben Sie Folgendes an "getObjectValues()":
"act_log_all.length"
Dies ist die einzige Möglichkeit der Verwendung von Listennamen bei diesen Methodentypen.