DE102014119363A1 - Autorisierungsverwaltungsserver und autorisierungsverwaltungsverfahren - Google Patents

Autorisierungsverwaltungsserver und autorisierungsverwaltungsverfahren Download PDF

Info

Publication number
DE102014119363A1
DE102014119363A1 DE102014119363.6A DE102014119363A DE102014119363A1 DE 102014119363 A1 DE102014119363 A1 DE 102014119363A1 DE 102014119363 A DE102014119363 A DE 102014119363A DE 102014119363 A1 DE102014119363 A1 DE 102014119363A1
Authority
DE
Germany
Prior art keywords
authorization
access
access token
resource
api
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102014119363.6A
Other languages
English (en)
Inventor
c/o Canon Kabushiki Kaisha Kobayashi Makoto
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Publication of DE102014119363A1 publication Critical patent/DE102014119363A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation

Abstract

Es wird ein API-Zählprozess ausgeführt, der eine Grenzzahl für eine durch einen Client benutzte API einstellt und, wenn ein Zugriffstoken in Erwiderung auf eine Anforderung von einem Autorisierungsübertragungsziel abgegeben wird und eine Anforderung zum Verifizieren des abgegebenen Zugriffstokens empfangen wird, eine API-Benutzungsgrenzzahl pro Client gemäß der Benutzungsgrenzzahl für jede API verwaltet, die für das Autorisierungsübertragungsziel eingestellt ist. Die API-Benutzungszahl wird inkrementiert (S5.2), mit der Benutzungsgrenzzahl verglichen (S5.3), und die Zugriffstokenverifikation wird in dem Fall, dass die Grenze überschritten wurde, als fehlgeschlagen betrachtet.

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf Verfahren zum Verwaltung von API-Aufrufgrenzen für einen Client in einem Autorisierungsübertragungssystem, und insbesondere bezieht sie sich auf Autorisierungsverwaltungsserver und Autorisierungsverwaltungsverfahren hinsichtlich API-Aufrufen von mehreren Clients in dem gleichen Mandanten.
  • Beschreibung der verwandten Technik
  • In den letzten Jahren war ein Anstieg in der Benutzung dessen zu verzeichnen, was als Cloud-basierte Dienste bekannt ist, die über das Internet implementiert sind. Für Unternehmer ebenso wie für Einzelpersonen wird es immer gebräuchlicher, zum Beispiel Kundenbeziehungen unter Verwendung eines CRM-Diensts (CRM: "Customer Relationship Management") zu verwalten, Informationen in Echtzeit unter Verwendung eines SNS (SNS: "Social Networking Service") zu verteilen und zu sammeln, und so weiter. Viele dieser Cloud-basierten Dienste machen APIs einzelner Webdienste öffentlich, und es ist nunmehr möglich, durch derartige Dienste bereitgestellte Funktionen von anderen Anwendungen, Cloud-basierten Diensten, und so weiter aus über die APIs zu benutzen. Als Folge hiervon gibt es einen kontinuierlichen Anstieg in "Mashup"-Funktionen, in denen mehrere APIs, die durch mehrere Cloud-basierte Dienste öffentlich gemacht sind, kombiniert werden, um einen Dienst zu konfigurieren, der so arbeitet, als ob er ein einzelnen Webdienst wäre.
  • Die Zunahme von Möglichkeiten zur Benutzung von "Mashup"-Funktionen, durch die mehrere Cloud-basierte Dienste zusammenarbeiten, hat jedoch auch mehrere Probleme verursacht. Zum Beispiel besteht ein Risiko darin, dass mehr Informationen zwischen den mehreren Cloud-basierten Diensten ausgetauscht werden, als ein Benutzer zu teilen beabsichtigt, was das Risiko erhöht, dass Benutzerdaten, persönliche Informationen und dergleichen durchsickern. Es ist im Allgemeinen wünschenswert, nicht mehr Benutzerdaten, persönliche Informationen, und so weiter zu sammeln, als für jeden Cloud-basierten Dienst erforderlich ist, und es ist weiterhin notwendig, zu verhindern, dass Benutzerdaten, persönliche Informationen, und so weiter an Cloud-basierte Dienste bereitgestellt werden, mit denen der Benutzer nicht zusammenarbeiten möchte. Indessen ist es aus Sicht von Dienstanbietern wünschenswert, es einfacher zu machen, ein System zur Zusammenarbeit von Cloud-basierten Diensten zu realisieren. Angesichts derartiger Gegebenheiten wurde ein Standardprotokoll zur Kooperation von Autorisierungen entwickelt, das als OAuth 2.0 bezeichnet wird (siehe "The Oauth 2.0 Authorization Framwork", (online), D. Hardt, Mai 2013, abgerufen von http://tools.ietf.org/html/rfc6749).
  • Gemäß OAuth 2.0 kann, wenn es zum Beispiel eine API gibt, die die Daten eines durch einen Dienst A verwalteten Benutzers erfasst, ein Dienst B, der durch diesen Benutzer autorisiert ist, auf die besagte API zugreifen. Dabei wird ein Bereich/Rahmen bzw. Umfang deutlich gemacht, in dem durch den Dienst B zugegriffen wird, woraufhin der Dienst A explizite Autorisierung von dem Benutzer für den Dienst B zum Zugriff auf die API erhält. Das Vornehmen dieser expliziten Autorisierung durch den Benutzer wird als Autorisierungsvorgang bezeichnet.
  • Wenn der Benutzer den Autorisierungsvorgang vornimmt, empfängt der Dienst B ein Token bzw. Zeichnen/Symbol (das hierin nachstehend als "Zugriffstoken" bezeichnet wird), das einen Zugriff von dem Dienst A autorisiert, und kann der Dienst B anschließend durch Verwendung dieses Zugriffstokens auf die API des Diensts A zugreifen. Der Prozess, durch den der Autorisierungsvorgang durch den Benutzer einem Dienst erlaubt, auf durch einen anderen Dienst verwaltete Benutzerressourcen zuzugreifen, wird als die Übertragung bzw. Delegierung von Autorisierungen bezeichnet. Wenn das Zugriffstoken benutzt wird, kann der Dienst B unter der Autorisierung bzw. Berechtigung des Benutzers, der die Autorisierung vorgenommen hat, auf die API des Diensts A zugreifen, ohne Berechtigungsnachweise bzw. Zugangs-/Anmeldedaten von diesem Benutzer zu benötigen. Insofern hat der Dienst B, der durch den Benutzer autorisiert wurde und das Zugriffstoken erhalten hat, eine Verpflichtung, das Zugriffstoken angemessen und sorgfältig zu verwalten bzw. handzuhaben.
  • Gemäß OAuth 2.0 ist es für den Dienst B notwendig, authentisiert zu werden, um eine Manipulation bzw. Verschleierung des Diensts B zu verhindern. Zum Authentisieren des Diensts B ist es für den Dienst A notwendig, die Berechtigungsnachweise bzw. Anmelde-/Zugangsdaten des Diensts B, und insbesondere eine Client-ID und ein Geheimnis, im Voraus abzugeben bzw. auszustellen, die Berechtigungsnachweise bzw. Anmelde-/Zugangsdaten zu verwalten, und weiterhin diese Berechtigungsnachweise bzw. Anmelde-/Zugangsdaten in dem Dienst B einzustellen. Nachstehend wird hierin der Dienst A, der eine Ressource bereitstellt, als ein "Ressourcenserver" bezeichnet, wohingegen aus Sicht des Diensts A der Dienst B, oder mit anderen Worten der andere Dienst, der den Ressourcenserver unter der durch den Benutzer dieses Diensts übertragenen Autorisierung benutzt, als ein "Client" (dieses Ressourcenservers) bezeichnet wird. Gemäß OAuth 2.0 ist es möglich, einen Autorisierungsserver, der die vorgenannten Benutzerautorisierungsvorgänge, die Abgabe bzw. Ausstellung von Zugriffstokens und die Authentisierung von Clients vornimmt, und einen Ressourcenserver, der Benutzerdaten als Ressourcen verwaltet und APIs als Webdienste öffentlich macht, separat zu konfigurieren. In einem solchen Fall akzeptiert der Dienst B die Übertragung einer Autorisierung bzw. Berechtigung von dem Benutzer, erhält er das Zugriffstoken von dem Autorisierungsserver, und benutzt er dieses Zugriffstoken, um auf die API des Ressourcenservers zuzugreifen. Der Ressourcenserver ist konfiguriert, den Autorisierungsserver aufzufordern, das erhaltene Zugriffstoken zu verifizieren, Zugriff auf die Ressource nur in dem Fall zu erteilen, dass der Zugriff autorisiert wurde, und dann Daten an den Dienst B zurückzugeben.
  • Typischerweise überwacht bei einem Cloud-basierten Dienst eine durch einen Webdienst öffentlich gemachte API eine Anzahl von Benutzungen bzw. eine Benutzungszahl/-häufigkeit pro Zeiteinheit für jeden Client (siehe zum Beispiel japanische Patentoffenlegung Nr. 2007-328417 ). Dies erfolgt, um einen Abfall in der Gesamtqualität des Diensts zu verhindern, der daraus resultiert, dass die API durch einen bestimmten Client übermäßig benutzt wird. Insbesondere Bezahldienste, die basierend auf dem Umfang verrechnet werden, in dem der Dienst benutzt wird, stellen häufig Grenzen bezüglich der Häufigkeit auf, mit der der Dienst in einer Zeiteinheit benutzt werden kann, und lehnen sie einen Zugriff ab, nachdem dem die Grenze erreicht wurde. Dies ist deshalb so, da ein Bezahldienst grundsätzlich unter einem Vertrag mit einem Benutzer benutzbar gemacht wird, und der Betreiber eines Bezahldiensts eine Verpflichtung hat, den Dienst in einer stabilen Art und Weise gemäß den Einzelheiten dieses Vertrags bereitzustellen. Als ein Beispiel eines solchen Systems zur Gewährleistung der Qualität eines Diensts ist eine SLA (SLA: "Service Level Agreement" bzw. Dienstgütevereinbarung) bekannt. Eine SLA definiert Elemente wie etwa eine bereitgestellte Minimalgeschwindigkeit des Diensts, eine Grenze bezüglich des Zeitumfangs, für den der Dienst benutzt werden kann, und so weiter. Ein Benutzer zahlt dann eine Gebühr als Vergütung für die in der SLA definierte Dienstqualität. Die SLA definiert auch Strafen für den Dienstanbieter, Benutzergarantien wie etwa Ermäßigungen in Benutzungsgebühren, und so weiter für Fälle, in denen die versprochene Qualität nicht bereitgestellt wird. Insofern ist es bei einem Bezahldienst extrem wichtig, dass die in der SLA definierte Qualität eingehalten wird, was bedeutet, dass es wichtig ist, Abfälle in der Dienstqualität zu verhindern, indem Grenzen bezüglich API-Benutzungsumfängen eingestellt werden und ein Zugriff abgelehnt wird, wenn die Grenzen erreicht wurden.
  • Die folgende Konfiguration kann für eine Situation in Betracht gezogen werden, in der ein internes System einer Firma, nämlich mehrere Clients, die einem Mandanten vorhanden sind, mit einem Cloud-basierten Dienst zusammenarbeitet. Ein "Mandant" ist eine Einheit, die zum Unterscheiden von Instanzen verwendet wird, denen eine Ressource bereitgestellt wird, und ist eine Einheit, durch die Benutzer die Cloud benutzen und verwalten. Zum Beispiel in einem Fall, in dem mehrere Benutzer den gleichen Ressourcenserver nutzen, werden die Informationen der Benutzer, die durch den Ressourcenserver verwaltetet werden, in unabhängige Einheiten unterteilt, und entsprechend diese unterteilten Einheiten "Mandanten". Mit anderen Worten kann eine Konfiguration in Betracht gezogen werden, in der jeder Client als ein Mandantenclient für einen bestimmten Mandanten in dem Cloud-basierten Dienst (nämlichen dem Ressourcenserver) fungiert, und mehrere Clients über den bestimmten Mandanten mehrere Dienste benutzen können. In dieser Konfiguration sind zum Beispiel ein Datenhochladeclient, ein Formularclient und ein Druckclient für einen Cloud-basierten Dienst, zu dem ein Mandant gehört, in diesem Mandanten bereitgestellt. Es wird angenommen, dass die Verwaltung der API-Benutzungsgrenze als Grenzverwaltung über OAuth auf Mandantenbasis implementiert ist.
  • Die vorgenannte OAuth-Konfiguration oder mit anderen Worten eine Konfiguration mit dem Autorisierungsserver, der Zugriffstokens abgibt bzw. ausstellt, und dem Ressourcenserver, der die API öffentlich macht, hat das folgende Problem. Wenn eine API-Benutzungsgrenzzahl in einem bestimmten Mandanten besteht, und ein Client die API des Diensts A übermäßig benutzt und die Benutzungsgrenze erreicht, kann die API des Diensts B nicht mehr aufgerufen werden. Mit anderen Worten wird die Häufigkeit, mit der eine API in einem bestimmten Dienst benutzt werden kann, durch die Benutzungssituation von einer API in einem anderen Dienst beeinträchtigt.
  • KURZFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung weist die folgende Konfiguration auf.
  • Gemäß einem Aspekt der vorliegenden Erfindung ist ein Autorisierungsverwaltungsserver bereitgestellt, der aufweist: eine Verwaltungseinrichtung zum Verwalten einer Zugriffsautorisierung eines Benutzers für eine Ressource; eine Abgabeeinrichtung zum, in Erwiderung auf eine Autorisierungsanforderung von einem Client, die eine Übertragung der Zugriffsautorisierung des Benutzers für eine Ressource anfordert, Verifizieren der Autorisierungsanforderung und Abgeben eines Zugriffstokens an den Client in dem Fall, dass die Verifikation erfolgreich ist; und eine Verifikationseinrichtung zum Verifizieren des Zugriffstokens und Zurückgeben einer Verifikationsantwort in dem Fall, dass die Verifikation erfolgreich ist, falls eine Ressourcenanforderung zusammen mit dem Zugriffstoken vorliegt, wobei sowohl die durch die Abgabeeinrichtung durchgeführte Autorisierungsanforderungsverifikation als auch die durch die Verifikationseinrichtung durchgeführte Zugriffstokenverifikation bestimmen, ob eine Anzahl von Zugriffen auf die Ressource eine eingestellte Zugriffsgrenzzahl überschritten hat oder nicht, und in dem Fall, dass die Zugriffsgrenzzahl nicht überschritten ist, das Zugriffstoken als gültig bestimmen.
  • Gemäß einem weiteren Aspekt weist die vorliegende Erfindung die folgende Konfiguration auf.
  • Ein Autorisierungsverwaltungsserver weist auf: eine Verwaltungseinrichtung zum Verwalten einer Zugriffsautorisierung eines Benutzers für eine Ressource; eine Abgabeeinrichtung zum, in Erwiderung auf eine Autorisierungsanforderung von einem Client, die eine Übertragung der Zugriffsautorisierung des Benutzers für eine Ressource anfordert, Abgeben eines Zugriffstokens an den Client; und eine Verifikationseinrichtung zum Verifizieren des Zugriffstokens und Zurückgeben einer Verifikationsantwort in dem Fall, dass die Verifikation erfolgreich ist, falls eine Ressourcenanforderung zusammen mit dem Zugriffstoken vorliegt, wobei die durch die Verifikationseinrichtung durchgeführte Zugriffstokenverifikation bestimmt, ob eine Anzahl von Zugriffen auf die angeforderte Ressource eine eingestellte Zugriffsgrenzzahl überschritten hat oder nicht, und in dem Fall, dass die Zugriffsgrenzzahl nicht überschritten ist, das Zugriffstoken als gültig bestimmt.
  • Gemäß der vorliegenden Erfindung werden in einem einzelnen Mandanten Benutzungsgrenzen für APIs in individuellen Diensten nicht durch die Benutzungssituation von APIs in anderen Diensten beeinträchtigt. Dies erhöht die Benutzbarkeit der Dienste.
  • Zusätzlich kann in dem Fall, dass mehrere Dienste in einer kooperierenden Art und Weise arbeiten, eine API-Benutzungsgrenze für eine Reihe von Funktionen, die von den mehreren Diensten konfiguriert sind, eingestellt werden, was es möglich macht, die Funktionen ohne Fehler auszuführen und die Benutzbarkeit der Dienste zu erhöhen.
  • Weitere Merkmale der vorliegenden Erfindung werden aus der folgenden Beschreibung von beispielhaften Ausführungsbeispielen (unter Bezugnahme auf die beigefügten Zeichnungen) deutlich.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist eine Systemkonfigurationsdarstellung.
  • 2 ist eine Darstellung, die die Hardwarekonfiguration von jeder Vorrichtung veranschaulicht.
  • 3 ist eine Darstellung, die Softwaremodule in jeweiligen Vorrichtungen veranschaulicht.
  • 4A–4D sind Darstellungen, die Tabellenstrukturen in Bezug auf durch einen Autorisierungsserver verwaltete Clients veranschaulichen.
  • 5A–5G sind Darstellungen, die Tabellenstrukturen in Bezug auf durch den Autorisierungsserver verwaltete Zugriffstokens veranschaulichen.
  • 6 ist ein Ablaufdiagramm, das eine API-Grenzzahl-Einstellung veranschaulicht.
  • 7A und 7B sind Darstellungen, die Beispiele von Login- und API-Grenzeinstellung-Bildschirmen veranschaulichen.
  • 8 ist eine Darstellung, die eine Sequenz von einer Clientregistrierung bis zu einem Ressourcenzugriff veranschaulicht.
  • 9 ist eine Darstellung, die eine Zugriffstoken-Abgabesequenz im Fall einer Clientberechtigungsnachweiserteilung veranschaulicht.
  • 10 ist ein Ablaufdiagramm, das einen Zugriffstoken-Verifikationsprozess veranschaulicht.
  • 11 ist ein Ablaufdiagramm, das einen API-Zählprozess veranschaulicht.
  • 12 ist eine Darstellung, die eine API-Mehrfachaufrufsequenz gemäß einem zweiten Ausführungsbeispiel veranschaulicht.
  • 13 ist ein Ablaufdiagramm, das einen API-Zählprozess gemäß dem zweiten Ausführungsbeispiel veranschaulicht.
  • 14 ist eine Darstellung, die eine Zugriffstoken-Abgabesequenz im Fall einer Autorisierungscodeerteilung veranschaulicht.
  • 15A–15C sind Darstellungen, die eine Benutzerschnittstelle veranschaulichen, die in der Zugriffstoken-Abgabesequenz im Fall einer Autorisierungscodeerteilung eingesetzt wird.
  • BESCHREIBUNG DER AUSFÜHRUNGSBEISPIELE
  • Nachstehend werden hierin Ausführungsbeispiele der vorliegenden Erfindung unter Bezugnahme auf die Zeichnungen beschrieben.
  • Ein Autorisierungsübertragungssystem mit einer API-Benutzungszahlgrenze-Verwaltungsfunktion gemäß dem vorliegenden Ausführungsbeispiel ist über ein Netzwerk implementiert, das so konfiguriert ist, wie es in 1 gezeigt ist. Es ist zu beachten, dass das Autorisierungsübertragungssystem ein System ist, das durch Server und Clients konfiguriert ist, und ein System ist, das Dienste an autorisierte bzw. berechtigte Clients bereitstellt. Die übertragene bzw. delegierte Autorisierung bzw. Berechtigung entspricht der Autorisierung bzw. Berechtigung zum Zugreifen auf durch einen Ressourcenserver bereitgestellte Ressourcen, was nachstehend ausgeführt wird. Da das System ein System ist, das Ressourcen bereitstellt, kann das System gemäß dem vorliegenden Ausführungsbeispiel auch als Ressourcenbereitstellungssystem bezeichnet werden.
  • Konfiguration von Autorisierungsübertragungssystem
  • Gemäß 1 ist ein Weitverkehrsnetzwerk (WAN) 100 ein Netzwerk für lokale Netzwerke und dergleichen, um sich miteinander zu verbinden, und entspricht es zum Beispiel dem Internet. Ein WWW-System (WWW: "World Wide Web") ist zum Beispiel in dem WAN 100 konfiguriert. Ein lokales Netzwerk (LAN) 101 verbindet Netzwerkbestandteile wie etwa zum Beispiel Computer. Eine öffentliche Leitung 102 ist eine öffentliche Leitung, die das WAN 100 mit Bestandteilen wie etwa Computern verbindet, und sie wird in dem Fall, dass das WAN 100 das Internet ist, als "Zugangs- bzw. Anschlussleitung" bezeichnet.
  • Ein Autorisierungsserver 200 ist ein Server zum Implementieren von OAuth 2.0, und er ist mit einem Autorisierungsservermodul ausgestattet. Der Autorisierungsserver ist ein Server, der Benutzer- und Clientautorisierungen zum Zugreifen auf Ressourcen verwaltet, und er wird auch als "Autorisierungsverwaltungsserver" bezeichnet. Ein Ressourcenserver 300 ist mit Ressourcenservermodulen wie etwa einem Benutzerbereitstellungsdienst, einem bezahlten Datenwandlungsdienst, einem kostenlosen Datenwandlungsdienst, und so weiter ausgestattet. Es ist zu beachten, dass ein oder mehrere Ressourcenservermodule in einem einzelnen Ressourcenserver bereitgestellt sein können. Der Ressourcenserver 300 speichert und verwaltet Ressourcen für jeden Benutzer, und er stellt die Ressourcen über Dienst-APIs an autorisierte bzw. berechtigte Clients bereit. Eine "Ressource" bezieht sich zum Beispiel auf Speicherplatz, Verarbeitungsfähigkeiten oder bestimmte Anwendungen. Ein Endgerät 400 ist eine Vorrichtung, die ein Anwendungsprogramm ausführt, das auf eine durch den Ressourcenserver 300 bereitgestellte Ressource zugreift, und es ist zum Beispiel ein mobiles Endgerät wie etwa ein Smartphone, eine Bilderzeugungsvorrichtung oder dergleichen. Ein oder mehrere Anwendungsmodule sind in dem Endgerät 400 installiert. Ein Benutzer kommuniziert mit dem Ressourcenserver unter Verwendung des Anwendungsmoduls. Ein Datenbankserver 500 ist über das LAN 101 mit dem Autorisierungsserver 200 verbunden, und er speichert durch das Autorisierungsservermodul verwendete Daten. Der Autorisierungsserver 200, der Ressourcenserver 300 und die Endgeräte 400 sind über das WAN 100 und das LAN 101 miteinander verbunden. Es ist zu beachten, dass der Autorisierungsserver 200, der Ressourcenserver 300 und die Endgeräte 400 in separaten einzelnen LANs bereitgestellt sein können oder in dem gleichen LAN bereitgestellt sein können. Zusätzlich können der Autorisierungsserver 200, der Ressourcenserver 300 und der Datenbankserver 500 in einem einzelnen Server konfiguriert sein.
  • Server- und Endgerätekonfiguration
  • Das Autorisierungsübertragungssystem gemäß dem vorliegenden Ausführungsbeispiel ist als ein System implementiert, das Server und Endgeräte umfasst, die so konfiguriert sind, wie es in 2 angedeutet ist. 2 veranschaulicht die Hardwarekonfiguration des Autorisierungsservers 200, des Ressourcenservers 300, der Endgeräte 400 und des Datenbankservers 500. Es ist zu beachten, dass das in 2 gezeigte Hardwareblockschaltbild einem Hardwareblockschaltbild für eine typische Informationsverarbeitungsvorrichtung entspricht, und die Hardwarekonfiguration einer solchen typischen Informationsverarbeitungsvorrichtung in den Servern und Endgeräten gemäß dem vorliegenden Ausführungsbeispiel angewandt werden kann.
  • Gemäß 2 führt eine CPU 201 Programme wie etwa ein OS oder Anwendungen aus, die in einem Programm-ROM in einem ROM 203 gespeichert sind oder von einem externen Speicher 211 wie etwa einer Festplatte (HD) in einen RAM 202 geladen werden, und steuert sie die jeweiligen Blöcke, die mit einem Systembus 204 verbunden sind. Hier ist "OS" ein Akronym für "Operating System" bzw. Betriebssystem, das auf einem Computer läuft, und das Betriebssystem wird hierin nachstehend als "OS" bezeichnet. Die Prozesse der nachstehend aufgeführten Sequenzen werden durch Ausführungen dieser Programme implementiert. Der RAM 202 fungiert als der Hauptspeicher, ein Arbeitsbereich, und so weiter für die CPU 201. Eine Tastatursteuereinheit (KBC) 205 steuert Tasteneingaben von einer Tastatur 209, einer (nicht gezeigten) Zeigevorrichtung oder dergleichen. Eine CRT-Steuereinheit (CRTC) 206 steuert Anzeigen auf einer CRT-Anzeige 210. Eine Plattensteuereinheit (DKC) 207 steuert einen Datenzugriff in dem externen Speicher 211 wie etwa einer Festplatte (HD), der verschiedene Datentypen speichert. Eine Netzwerksteuereinheit (NC) 208 ist über das WAN 100, das LAN 101 oder die öffentliche Leitung 102 verbunden, und sie führt Kommunikationssteuerprozesse mit den anderen Vorrichtungen aus.
  • Soweit es nicht anderweitig angegeben ist, nehmen die folgenden Beschreibungen an, dass die CPU 201 die Haupthardwareinstanz ist, die Prozesse in dem Server ausführt, und dass das in dem externen Speicher 211 installierte Anwendungsprogramm die Hauptsoftwareinstanz ist.
  • Softwaremodulkonfiguration
  • 3 ist eine Darstellung, die Modulkonfigurationen in dem Autorisierungsserver 200, dem Ressourcenserver 300 und den Endgeräten 400 gemäß dem vorliegenden Ausführungsbeispiel veranschaulicht. Es ist zu beachten, dass der Autorisierungsserver 200, der Ressourcenserver 300 und die Endgeräte 400 gleich denjenigen sind, die in 2 gezeigt sind.
  • Gemäß 3 umfasst der Autorisierungsserver 200 ein Autorisierungsservermodul 600 und ein HTTP-Servermodul 610. Das HTTP-Servermodul 610 ist ein Modul zum Durchführen einer HTTP-Kommunikation mit einem HTTP-Client (zum Beispiel einem Web-Browser) in dem Endgerät 400, das über das WAN 100 verbunden ist, als Server. Das Modul ist so konfiguriert, dass es zu einer SSL/TLS-Kommunikation fähig ist, und es weist einen (nicht gezeigten) Zertifikatsspeicher auf. Bei dem vorliegenden Ausführungsbeispiel ist die Konfiguration derart, dass an einem Endpunkt, an dem eine Clientregistrierungsanforderung empfangen wird, was nachstehend beschrieben wird, eine Anforderung zur Authentisierung unter Verwendung eines X.509-Zertifikats an den Ausgangspunkt der besagten Anforderung abgegeben wird. Das Autorisierungsservermodul 600 ist eine Web-Anwendung, die auf oder in Zusammenarbeit mit dem HTTP-Servermodul 610 läuft, und über das HTTP-Servermodul 610 Anforderungen von dem Endgerät 400 annimmt und verarbeitet und Antworten an das Endgerät 400 zurückgibt. Das vorliegende Ausführungsbeispiel ist so konfiguriert, dass zu dieser Zeit, wenn eine Clientregistrierungsanforderung empfangen wird und der Ausgangspunkt der Anforderung in dem HTTP-Servermodul 610 erfolgreich authentisiert wurde, das empfangene Zertifikat an das Autorisierungsservermodul 600 kommuniziert wird.
  • Der Ressourcenserver 300 umfasst ein Ressourcenservermodul 700 und ein HTTP-Servermodul 710. Das HTTP-Servermodul 710 weist die gleichen Funktionen wie das HTTP-Servermodul 610 auf. Das Ressourcenservermodul 700 ist eine Web-Anwendung, die auf oder in Zusammenarbeit mit dem HTTP-Servermodul 710 läuft, und über das HTTP-Servermodul 710 Anforderungen von dem Endgerät 400 annimmt und verarbeitet und Antworten an das Endgerät 400 zurückgibt.
  • Das Endgerät 400 umfasst ein Anwendungsverwaltungsmodul 810 und einen Web-Browser 820, und es weist außerdem ein oder mehrere Anwendungsmodule 800 auf. Das Anwendungsverwaltungsmodul 810 hat eine Funktion zum Verwalten des Lebenszyklus des Anwendungsmoduls 800, das auf dem Endgerät 400 läuft, welches zu verwalten ist. Ein "Lebenszyklus" bezieht sich auf einen Anwendungszustand, der Installation, Start, Schließung und Deinstallation umfasst. OSGI (eingetragene Marke), definiert durch die OSGi-Allianz (OSGi: "Open Services Gateway initiative), kann als ein Beispiel des Anwendungsverwaltungsmoduls 810 betrachtet werden. Das Anwendungsmodul 800 ist eine Anwendung, die in einer Anwendungsausführungsumgebung läuft, die durch das Endgerät 400 bereitgestellt wird. Der Lebenszyklus dieser Anwendung wird durch das Anwendungsverwaltungsmodul 810 verwaltet. Hier kann das Anwendungsmodul 810 in dem Endgerät 400 im Voraus bereitgestellt werden/sein oder später über das Anwendungsverwaltungsmodul 810 installiert werden/sein. Das Endgerät 400 umfasst weiterhin den Web-Browser 820, der ein Benutzer-Agent für einen Zugang zu dem World Wide Web darstellt. Das Anwendungsmodul 800 hält ein X.509-Zertifikat zur Selbstidentifikation und einen privaten Schlüssel für das Zertifikat. Diese können verwendet werden, wenn eine Kommunikation mit dem HTTP-Servermodul 610 hergestellt wird, was nachstehend beschrieben wird, damit das HTTP-Servermodul 610 authentisieren kann, dass die Anforderung von dem Anwendungsmodul stammt.
  • Datenbankserver-Datentabellen
  • 4A, 4B, 4C und 4D veranschaulichen Datentabellen, die in einem externen Speicher des Datenbankservers 500 gespeichert sind, der so konfiguriert ist, dass er zur Kommunikation mit dem Autorisierungsserver 200 über das LAN 101 fähig ist. Diese Datentabellen können auch in einem externen Speicher des Autorisierungsservers 200 konfiguriert sein.
  • 4A veranschaulicht eine Zertifikat-Verwaltungstabelle 1200. Bei dem vorliegenden Ausführungsbeispiel werden X.509-Zertifikate als die besagten Zertifikate verwendet. Die Zertifikat-Verwaltungstabelle 1200 umfasst eine Zertifikatseriennummer 1201, einen Zertifikataussteller 1202, einen Besitzer 1203, ein Anfangsdatum 1204, ein Enddatum 1205 und einen eindeutigen Namen (DN: "Distinguished Name") 1206, der als ein Bezeichner für einen Master-Benutzer eines zugehörigen Mandanten dient, was nachstehend beschrieben wird. Wie es in dem vorstehenden Abschnitt der verwandten Technik beschrieben ist, ist ein "Mandant" eine Einheit, die zum Unterscheiden von Instanzen verwendet wird, an die eine Ressource bereitgestellt wird, und eine Einheit, durch die Benutzer die Cloud benutzen und verwalten.
  • 4B veranschaulicht eine Client-Verwaltungstabelle 1300. Die Client-Verwaltungstabelle 1300 umfasst eine Client-ID 1301, ein Clientgeheimnis 1302, eine Mandant-ID 1303, einen Typ 1304, einen DN 1305, einen Clientnamen 1306 und eine Umleitung-URL 1307. Der Autorisierungsserver 200 hat eine Funktion zum Authentisieren von Clients durch Verifikation der Authentizität eines Clients, der eine Authentisierung oder dergleichen anfordert, durch Vergleich von einem Satz aus ID und privaten Informationen, der von dem Client empfangen wird, mit einem Satz aus Informationen, die die Client-ID 1301 und das Geheimnis 1302 umfassen, und zum Erzeugen von Berechtigungsnachweisen, wenn der Client erfolgreich authentisiert wird. Der Clientname 1306 und die Umleitung-URL 1307 sind Werte, die in nachstehend beschriebenen Sequenzen verwendet werden. Indessen hält der Typ 1304 Daten zum Identifizieren, ob der Client in diesem Datensatz der Master-Benutzer eines Mandanten ist oder nicht.
  • 4C veranschaulicht eine Standardautorisierung-Verwaltungstabelle 1400. Die Standardautorisierung-Verwaltungstabelle 1400 umfasst eine Mandant-ID 1401 und eine Standardautorisierung-ID 1402. Die Mandant-ID 1401 ist so konfiguriert, dass sie mit der Mandant-ID 1303 der Client-Verwaltungstabelle 1300 in Zuordnung gebracht werden kann.
  • 4D veranschaulicht eine Clientautorisierungstabelle 1500. Die Clientautorisierungstabelle 1500 umfasst eine Client-ID 1501 und eine Autorisierung-ID 1502. Die Client-ID 1501 ist so konfiguriert, dass sie mit der Client-ID 1301 der Client-Verwaltungstabelle 1300 in Zuordnung gebracht werden kann. Die Autorisierung-ID 1502 hält eine Autorisierung-ID, die für die Standardautorisierung-ID 1402 der Standardautorisierung-Verwaltungstabelle 1400 eingestellt ist. Die Registrierung der Autorisierung-ID in der Autorisierung-ID 1502 wird nachstehend beschrieben.
  • Autorisierungsserver-Datentabellen
  • 5A, 5B, 5C, 5D und 5E veranschaulichen Datentabellen, die in einem externen Speicher des Datenbankservers 500 gespeichert sind, der so konfiguriert ist, dass er zur Kommunikation mit dem Autorisierungsserver 200 über das LAN 101 fähig ist. Diese Datentabellen können auch in einem externen Speicher des Autorisierungsservers 200 konfiguriert sein.
  • 5A veranschaulicht eine Umfangstabelle 1600. In einem Autorisierungsübertragungsprotokoll unter Verwendung von OAuth 2.0 bezieht sich "Umfang" bzw. "Scope" auf einen Bereich/Rahmen bzw. eine Auswahl von Ressourcen, auf die unter Verwendung eines Zugriffstokens Bezug genommen werden kann, wenn dieses Zugriffstoken abgegeben bzw. ausgestellt wird. Es ist zu beachten, dass der Umfang bei dem vorliegenden Ausführungsbeispiel einer Zugriff-API mit Bezug auf eine Ressource entspricht, auf die durch den Umfang Bezug genommen werden kann, oder einer Gruppe entspricht, die eine Reihe von Zugriff-APIs umfasst. Der Umfang und die Zugriff-API entsprechen auch verschiedenen Typen von Diensten bei dem vorliegenden Ausführungsbeispiel. Ein Beispiel von einer durch den Umfang definierten Zugriff-API wird nachstehend beschrieben.
  • Die Umfangstabelle 1600 umfasst eine Umfang-ID 1601, einen Umfangstyp 1602, eine Umfangsbeschreibung 1603, die in einem nachstehend aufgeführten Bildschirmbeispiel benutzt wird, und einer Autorisierung-ID 1604. Hier bezieht sich "Umfang" bzw. "Scope" auf einen Bereich/Rahmen bzw. eine Auswahl, auf den bzw. die durch ein Autorisierungsübertragungsziel (einen Client) in dem Autorisierungsübertragungsablauf gemäß OAuth, der nachstehend aufgeführt wird, zugegriffen werden kann. Es ist zu beachten, dass sich ein "Ressourcenbesitzer", auf den hier Bezug genommen wird, abhängig von dem Ablauf in OAuth 2.0 unterscheidet. Im Speziellen wird bei dem vorliegenden Ausführungsbeispiel ein Zugriffstokenerlangungsablauf gemäß Clientberechtigungsnachweiserteilung bzw. "Client Credentials Grant" durchgeführt. Im Fall des Zugriffstokenerlangungsablaufs gemäß der Clientberechtigungsnachweiserteilung ist der Ressourcenbesitzer der Client selbst. Die Autorisierung-ID 1604 in der Umfangstabelle 1600 bezeichnet eine Autorisierung bzw. Berechtigung, die zum Zugreifen auf den durch die Umfang-ID bezeichneten Umfang erforderlich ist, und null oder mehrere Autorisierung-IDs können damit assoziiert sein. In dem Fall, dass mehrere Autorisierung-IDs assoziiert sind, kann auf die durch den Umfang bezeichneten Ressourcen zugegriffen werden, wenn zumindest eine der mehreren Autorisierung-IDs die erforderliche Autorisierung bzw. Berechtigung hat. In dem Fall, dass null Autorisierung-IDs assoziiert sind, oder mit anderen Worten in dem Fall, dass nicht mal eine Autorisierung-ID assoziiert ist, ist jedes Objekt, das für diesen Umfang authentisiert ist, zum Zugriff fähig. Der Umfangstyp 1602 gibt an, ob der Umfang einer einzelnen API oder einer Reihe von APIs, die als eine Gruppe dienen, entspricht. Eine API-Gruppe bezieht sich auf einen Fall, in dem eine Anwendung, die eine Reihe von APIs benutzt, wie etwa Datenerzeugung, Formularverarbeitung und Druck davon, als ein Client dient. Obwohl zwischen dem Fall, in dem eine einzelne API vorliegt, und dem Fall, in dem eine Gruppe von APIs vorliegt, bei dem vorliegenden Ausführungsbeispiel kein Unterschied in der Verarbeitung besteht, wird die API-Benutzungsgrenzzahl bei dem zweiten Ausführungsbeispiel, das nachstehend beschrieben wird, unterschiedlich behandelt.
  • 5B veranschaulicht eine Benutzer-Verwaltungstabelle 1700. Die Benutzer-Verwaltungstabelle 1700 umfasst eine Benutzer-ID 1701, ein Passwort 1702 und eine Mandant-ID 1703. Der Autorisierungsserver 200 hat eine Funktion zum Authentisieren von jedem Benutzer durch Verifikation der Authentizität von einem Benutzer durch Vergleich von einer Benutzer-ID und einem Passwort, die durch einen Benutzer eingegeben werden, mit einem Satz aus Informationen, die die Benutzer-ID 1701 und das Passwort 1702 umfassen, und zum Erzeugen von Berechtigungsnachweisen, wenn der Benutzer erfolgreich authentisiert wird.
  • 5C veranschaulicht eine Benutzerautorisierungstabelle 1800. Die Benutzerautorisierungstabelle 1800 umfasst eine Benutzer-ID 1801 und eine Autorisierung-ID 1802. Die Benutzer-ID 1801 ist so konfiguriert, dass sie mit der Benutzer-ID 1701 der Benutzer-Verwaltungstabelle 1700 in Zuordnung gebracht werden kann. Obwohl das vorliegende Ausführungsbeispiel die Benutzerautorisierungstabelle 1800 und die Clientautorisierungstabelle 1500 als Tabellen beschreibt, die voneinander unabhängig sind, können die Elemente in diesen auch unter Verwendung einer einzigen Tabelle verwaltet werden.
  • 5D veranschaulicht eine Zugriffstoken-Verwaltungstabelle 1900. Die Zugriffstoken-Verwaltungstabelle 1900 umfasst eine Zugriffstoken-ID 1901, einen Tokentyp 1902, ein Ablaufdatum 1903, eine Umfang-ID 1904 und eine Client-ID 1905. Einzelheiten einer Verarbeitung mit Bezug auf die Zugriffstoken-Verwaltungstabelle 1900 werden nachstehend angegeben.
  • 5E veranschaulicht eine API-Benutzungszahl-Verwaltungstabelle 1950. Die API-Benutzungszahl-Verwaltungstabelle 1950 umfasst eine Mandant-ID 1951, eine Umfang-ID 1952, einen Dienstnamen 1953, eine API-Benutzungsgrenzzahl 1954, eine API-Benutzungszahl 1955 und eine API-ID-Liste 1956. Die Mandant-ID 1951 ist so konfiguriert, dass sie mit der Mandant-ID 1703 der Benutzer-Verwaltungstabelle 1700 in Zuordnung gebracht werden kann. Die Umfang-ID 1952 ist so konfiguriert, dass sie mit der Umfang-ID 1601 der Umfangstabelle 1600 in Zuordnung gebracht werden kann. Der Dienstname 1953 bezeichnet den Namen eines Diensts, der der Umfang-ID 1952 entspricht. Der Dienstname bezeichnet indessen einen Dienst, der durch Zugriff auf eine Ressource realisiert wird, die durch das Ressourcenservermodul 700 in dem Ressourcenserver 300 bereitgestellt wird. Bei dem vorliegenden Ausführungsbeispiel stellt der Ressourcenserver 300 vielfältige Dienste über einen Zugriff auf das Ressourcenservermodul 700 in dem Ressourcenserver 300 bereit. Ein solcher Dienst ist zum Beispiel ein Formulardienst, der durch das Ressourcenservermodul 700 als eine API bereitgestellt wird. Die API-Benutzungsgrenzzahl 1954 bezeichnet Benutzungsgrenzzahlen für APIs von verschiedenen Typen von Diensten, die durch das Ressourcenservermodul 700 als APIs bereitgestellt werden. Dieser Wert wird durch einen gemäß 6 veranschaulichten Vorgang eingestellt. Bei dem vorliegenden Ausführungsbeispiel wird eine Einschränkung bezüglich einer Benutzungszahl bzw. -häufigkeit von jeder API (die als "API-Benutzungszahl" bezeichnet wird) innerhalb einer eingestellten Periode für jeden Mandanten basierend auf dem Konzept von QoS ("Quality of Service" bzw. Dienstgüte) gesetzt. Dies erfolgt, um einen Abfall in der Qualität der verschiedenen Typen von Diensten, die durch das Ressourcenservermodul 700 bereitgestellt werden, in Folge von Mandantendiensten, oder mit anderen Worten APIs, die übermäßig benutzt werden, zu verhindern. Bei dem vorliegenden Ausführungsbeispiel wird eine API-Benutzungseinschränkung bezüglich der Bereitstellung von Diensten für einen einzelnen Mandanten gesetzt. Im Speziellen wird die Einschränkung durch Einstellen einer Grenze bezüglich der Benutzungszahl bzw. -häufigkeit der APIs, die verschiedene Typen von Diensten bereitstellen, innerhalb einer Einheitsperiode für jeden Mandanten vorgenommen. Wenn die Einheitsperiode eine vorbestimmte Zeitdauer ist, kann die Periode zum Beispiel ein Tag, ein Monat oder dergleichen sein. Die Einheitsperiode kann universell eingestellt werden oder pro Mandant oder pro Dienst eingestellt werden. Diese Einheitsperiode wird so lange aktualisiert, wie der Vertrag zur Bereitstellung des Diensts fortbesteht, und eine neue Einheitsperiode wird zu dem Zeitpunkt begonnen, wenn die vorherige Einheitsperiode endet. Die API-Benutzungszahl 1955 zeichnet auf, wie oft die durch die Umfang-ID 1952 bezeichnete API durch den durch die aktuelle Mandant-ID 1954 bezeichneten Mandanten benutzt wurde. Dies wird zum Beispiel jedes Mal dann, wenn eine neue Einheitsperiode begonnen wird, auf 0 zurückgesetzt. Zum Beispiel wird ein Zeitgeber oder dergleichen verwendet, um zu verwalten, ob die Einheitsperiode erreicht wurde, und wird die API-Benutzungszahl 1955 auf 0 zurückgesetzt und der Lauf der nächsten Einheitsperiode gemessen, wenn die Einheitsperiode erreicht wurde. Die API-ID-Liste 1956 ist eine Liste der Namen der speziellen APIs, die den durch die Umfang-ID 1952 bezeichneten Dienst konfigurieren. Bei dem vorliegenden Ausführungsbeispiel gibt es Fälle, in denen ein einzelner Dienst unter Verwendung einer einzelnen API konfiguriert ist, und Fälle, in denen ein einzelner Dienst unter Verwendung von mehreren APIs konfiguriert ist. In jedem Fall wird jedoch ein einzelner Dienst durch eine einzelne Umfang-ID bezeichnet. Einzelheiten einer Verarbeitung mit Bezug auf die API-Benutzungszahl-Verwaltungstabelle 1950 werden nachstehend gegeben.
  • API-Grenzzahl-Einstellungsprozess
  • Unter Verwendung von 6, 7A und 7B wird ein Ablaufdiagramm beschrieben, das einen API-Grenzzahl-Einstellungsprozess angibt, der durch das Autorisierungsservermodul 600 gemäß dem vorliegenden Ausführungsbeispiel durchgeführt wird. Dieses Ablaufdiagramm veranschaulicht einen Ablauf, der durchgeführt wird, wenn ein Master-Benutzer die API-Benutzungsgrenzzahl in dem Autorisierungsservermodul 600 über das Endgerät 400 einstellt. Gemäß 6 bezeichnen Schritte S6.1, S6.2, S6.5 und S6.7 Prozesse, die bei Eingaben an das Endgerät und beim Senden von Informationen an einen Server involviert sind, wohingegen die anderen Schritte Prozesse bezeichnen, die durch den Autorisierungsserver 200, der das Autorisierungsservermodul 600 und das HTTP-Servermodul 610 umfasst, durchgeführt werden. Es ist zu beachten, dass in dem Fall, dass ein separater Authentisierungsserver vorliegt, ein Authentisierungsvorgang von Schritt S6.3 durch diesen Authentisierungsserver durchgeführt wird.
  • In S6.1 benutzt der Master-Benutzer den Web-Browser 820 des Endgeräts 400, um eine Anforderung zum Einstellen der API-Grenzzahl an das HTTP-Servermodul 610 des Autorisierungsservers 200 vorzunehmen. Es ist zu beachten, dass ein Auslöser dafür, dass der Web-Browser 820 des Endgeräts 400 die API-Grenzzahl-Einstellungsanforderung vornimmt, wie folgt ist. Die Beschreibungen des vorliegenden Ausführungsbeispiels nehmen an, dass der Master-Benutzer des Endgeräts 400 den Web-Browser 820 benutzt, um auf eine URL zuzugreifen, die einen API-Grenzzahl-Einstellungsbildschirm bereitstellt (wobei angenommen wird, dass diese URL bereits bekannt ist). Der API-Grenzzahl-Einstellungsbildschirm ist in dem Autorisierungsservermodul 600 des Autorisierungsserver 200 umfasst.
  • Das HTTP-Servermodul 610, das die API-Grenzzahl-Einstellungsanforderung von dem Web-Browser 820 angenommen hat, empfängt eine Autorisierungsanforderung. Dann gibt das HTTP-Servermodul 610 in S6.2 einen Login-Bildschirm zum Authentisieren des Benutzers an den Web-Browser 820 zurück. 7A veranschaulicht ein Beispiel des Login-Bildschirms, der durch das HTTP-Servermodul 610 zurückgegeben wird. Der Bildschirm gemäß 7A umfasst ein Benutzer-ID-Eingabefeld 2001, in das eine Benutzer-ID eingegeben wird, ein Passwort-Eingabefeld 2002, in das ein Passwort eingegeben wird, und eine Login-Schaltfläche 2003 zum Ausführen des Login-Vorgangs.
  • In S6.2 gibt der Benutzer die erforderlichen Informationen, nämlich eine Benutzer-ID und ein Passwort, in den gemäß 7A gezeigten Bildschirm ein, der in dem Web-Browser 820 angezeigt wird, und drückt er die Login-Schaltfläche 2003, woraufhin der Web-Browser 820 die eingegebenen Informationen an das HTTP-Servermodul 610 sendet. In S6.3 erhält das HTTP-Servermodul 610 die Benutzer-ID und das Passwort von dem Web-Browser 820, und authentisiert es den Benutzer durch Verifikation, ob ein Satz aus Informationen, die mit der Benutzer-ID 1701 und dem Passwort 1702 in der Benutzer-Verwaltungstabelle 1700 übereinstimmen, vorliegt oder nicht. In dem Fall, dass die Benutzerauthentisierung fehlschlägt, oder mit anderen Worten in dem Fall, dass die Informationen, die erhalten wurden, nicht in der Benutzer-Verwaltungstabelle 1700 registriert sind, gibt das HTTP-Servermodul 610 einen (nicht gezeigten) Authentisierungsfehlerbildschirm in S6.9 an den Web-Browser 820 zurück. Es ist möglich, ein anderes Verfahren zum Authentisieren des Benutzers zu benutzen, wie etwa eine Benutzung eines X.509-Zertifikats, einer mehrstufigen Authentisierung, in der mehrere Passwörter eingegeben werden, oder dergleichen, und das Verfahren zum Authentisieren des Benutzers ist nicht auf das hierin beschriebene Verfahren beschränkt.
  • In dem Fall, dass das Login in S6.3 erfolgreich ist, zeigt das Autorisierungsservermodul 600 des Autorisierungsservers 200 in S6.4 einen Dienstlistenbildschirm 2400, der gemäß 7B gezeigt ist, über das HTTP-Servermodul 610 an. Der Dienstlistenbildschirm 2400 ist ein Eingabebildschirm, der in einem Mandanten-/Benutzer-Anzeigebereich 2401 die Mandant-ID und die Benutzer-ID des Benutzers anzeigt, der in S6.2 erfolgreich eingeloggt wurde. Eine Liste von Diensten, die durch den Benutzer benutzt werden kann, der in S6.2 erfolgreich eingeloggt wurde, wird auch in einem API-Grenzzahlliste-Anzeigbereich 2402 angezeigt. Der API-Grenzzahlliste-Anzeigebereich 2402 ist durch Dienstnamen 2403 und API-Grennzahlen 2404 konfiguriert. Von diesen zeigen die Dienstnamen 2403 eine Liste der Namen von Diensten an, die durch den durch die Mandant-ID bezeichneten Mandanten benutzt werden können, der zu dem eingeloggten Benutzer gehört, der aktuell in dem Mandanten-/Benutzer-Anzeigebereich 2401 angezeigt wird. Im Speziellen wird die API-Benutzungszahl-Verwaltungstabelle 1950 unter Verwendung der Mandant-ID des eingeloggten Benutzers durchsucht, und werden alle Dienstnamen 1953 angezeigt, die der übereinstimmenden Mandant-ID entsprechen.
  • In S6.5 benutzt der eingeloggte Benutzer den Web-Browser 820, um einen Dienstnamen 2403 auszuwählen, für den die API-Grenzzahl einzustellen ist, und gibt er eine API-Grenzzahl in dem Feld für die API-Grenzzahl 2404 in der gleichen Zeile wie der Dienstname unter Verwendung der Benutzerschnittstelle ein. Mit Bezug auf einen Bereich für Werte, die für die API-Grenzzahl eingestellt werden können, besteht ein Maximalwert, der durch Einschränkungen von Rechenressourcen wie etwa von CPU, Speicher und dergleichen des Autorisierungsservers 200, die Anzahl von Mandanten, an die Dienste bereitzustellen sind, und so weiter definiert ist, und daher kann der Benutzer die Grenzzahl innerhalb eines Bereichs einstellen, der den maximalen Einstellwert nicht überschreitet. Sobald die API-Grenzzahlen 2404 für jeden Dienst eingestellt wurden, der in den Dienstnamen 2403 angezeigt wird, wird die API-Grenzzahleinstellung für die Dienste abgeschlossen, indem eine OK-Schaltfläche 2405 gedrückt wird.
  • In S6.6 bestimmt das Autorisierungsservermodul 600 des Autorisierungsservers 200, ob die durch den Benutzer eingestellte API-Grenzzahl den maximalen Einstellwert überschreitet. Wenn die eingestellte API-Grenzzahl den maximalen Einstellwert nicht überschreitet, zeigt das Autorisierungsservermodul 600 des Autorisierungsservers 200 in S6.7 den Einstellwert an, und beendet es den Prozess. Wenn jedoch die eingestellte Zahl den maximalen Einstellwert überschreitet, wird ein (nicht gezeigter) Fehler angezeigt, der angibt, dass der maximale Einstellwert überschritten wurde, und endet dann der Prozess.
  • Es ist zu beachten, dass das vorliegende Ausführungsbeispiel annimmt, dass die Summe der Grenzzahlen, die für einzelne Dienste (nämlich einzelne APIs) für einen bestimmten Mandanten eingestellt werden, eine Maximalzahl für diesen Mandanten nicht überschreiten darf. Dementsprechend wird zum Beispiel die Maximalzahl gleichmäßig für jede API aufgeteilt und als der Standardwert in den API-Grenzzahlen 2404 eingestellt und angezeigt. Wenn ein API-Grenzzahl-Einstellwert für einen bestimmten Dienst eingegeben wurde, wird eine Differenz zwischen diesem Einstellwert und dem Standardwert automatisch an die anderen Dienste zugewiesen, eingestellt und erneut angezeigt. Die Zuweisung an die anderen Dienste wird zum Beispiel als nahezu gleichmäßig angenommen. Dadurch werden die Benutzungsgrenzzahlen für einzelne Dienste nicht durch die Benutzungssituationen von anderen Diensten beeinträchtigt. Es ist zu beachten, dass die Summe der Grenzzahlen, die für einzelne Dienste (mit anderen Worten APIs) für einen bestimmten Mandanten eingestellt werden, die Maximalzahl für diesen Mandanten auch überschreiten dürfen können. Wenn jedoch die Grenzzahlen der jeweiligen Dienste alle auf die Maximalzahl eingestellt werden, wird als Folge hiervon das gleiche Problem wie bei der verwandten Technik auftreten. Um dies zu vermeiden, kann die Konfiguration derart sein, dass ein Maximalwert für die API-Grenzzahl, die für jeden Dienst eingestellt werden kann, bereitgestellt wird (Dienst-bezogene Maximalzahl genannt), oder die Summe der API-Grenzzahlen, die für jeden Dienst in einem bestimmten Mandanten eingestellt werden können, die Maximalzahl dieses Mandanten um einen vorbestimmten Prozentsatz oder einen vorbestimmten Wert überschreiten darf.
  • Durch den vorstehend beschriebenen Vorgang wird eine Grenze für die API-Benutzungszahl pro Dienst innerhalb einer Einheitsperiode eingestellt.
  • Ressourcenerlangungssequenz
  • Unter Verwendung von 8 wird eine Sequenz beschrieben, die in dem Anwendungsmodul 800 von einer Clientregistrierung bis zu einer Ressourcenerlangung gemäß dem vorliegenden Ausführungsbeispiel durchgeführt wird. Diese Sequenz veranschaulicht einen Ablauf, der durchgeführt wird, wenn ein Benutzer das Endgerät 400 benutzt, um ein Anwendungsmodul 800 zu benutzen, das in dem Autorisierungsservermodul 600 noch nicht registriert ist. Die Konfiguration kann auch so implementiert werden, dass zum Beispiel eine Clientregistrierung nur das erste Mal in dem Anwendungsmodul 800 des Endgeräts 400 durchgeführt wird, und der Prozess danach ausgehend von der Sequenz zur Erlangung eines Zugriffstokens ausgeführt wird.
  • Zunächst wird unter Verwendung von 8 eine Clientregistrierungssequenz beschrieben, die in dem Anwendungsmodul 800 durchgeführt wird. In S.1.1 nimmt das Anwendungsmodul 800 des Endgeräts 400 eine Clientregistrierungsanforderung an dem HTTP-Servermodul 610 des Autorisierungsservers 200 vor. Es ist zu beachten, dass das vorliegende Ausführungsbeispiel als Auslöser dafür, dass das Anwendungsmodul 800 die Clientregistrierungsanforderung vornimmt, beschreibt, dass der Benutzer das Anwendungsmodul 800 installiert und das Anwendungsmodul 800 in dem Endgerät 400 das erste Mal startet. Es ist zu beachten, dass der Zeitpunkt, zu dem der Benutzer eine Funktion in dem Anwendungsmodul 800 auswählt und eine Ressourcenanforderung an den Ressourcenserver 300 abgegeben wird, als ein weiterer Auslöser erachtet werden kann. Das Anwendungsmodul 800 kann mit einem Vorgang zum expliziten Starten ausgestattet sein, und der Zeitpunkt, zu dem der Benutzer diesen Vorgang unter Verwendung des Endgeräts 400 durchführt, kann als ein weiterer Auslöser erachtet werden. Es ist zu beachten, dass die Clientregistrierungsanforderung einen Clientnamen und eine Umleitung-URL zur Verwendung einer Autorisierungscodeerteilung bzw. "Authorization Code Grant" umfasst. Die Konfiguration kann derart sein, dass Attributinformationen wie etwa eine Zeichenfolge zur Beschreibung des Clients, die URL einer Stelle, die eine Beschreibung bereitstellt, oder dergleichen als weitere Informationen umfasst sind. Die Autorisierungscodeerteilung ist ein Vorgang, durch den eine Autorisierung bzw. Berechtigung von einem Benutzer mit der Autorisierung bzw. Berechtigung zur Benutzung eines Diensts übertragen bzw. delegiert wird, so dass eine kooperierende Anwendung (ein Client) eine durch den Dienst öffentlich gemachte API benutzen kann, und sie ist in OAuth 2.0 definiert. Der Vorgang einer Autorisierungscodeerteilung wird nachstehend unter Bezugnahme auf 14 und dergleichen beschrieben.
  • Nachdem es die Clientregistrierungsanforderung von dem Anwendungsmodul 800 angenommen hat, beginnt das HTTP-Servermodul 610 eine Verhandlung für eine SSL/TLS-Kommunikation. Zu dieser Zeit wird, mit Bezug auf eine Vorrichtungsregistrierungsanforderung, eine Einstellung zum Anfordern einer Clientauthentisierung vorgenommen, und wird daher eine Anforderung für ein Zertifikat an das Anwendungsmodul 800 abgegeben. In S1.2 verifiziert das HTTP-Servermodul 610 unter Verwendung eines in einem (nicht gezeigten) Zertifikatsspeicher eingestellten Zertifikats das von dem Anwendungsmodul 800 erhaltene Zertifikat, und authentisiert es das Anwendungsmodul 800 als die Quelle der Vorrichtungsregistrierungsanforderung. Obwohl das vorliegende Ausführungsbeispiel ein Authentisierungsverfahren beschreibt, das ein SSL/TLS-Zertifikat als das Verfahren zum Authentisieren des Ausgangspunkts der Clientregistrierungsanforderung verwendet, kann zum Beispiel ebenso ein Verfahren in Betracht gezogen werden, das eine ID und ein Passwort verwendet, wie etwa eine Basic-Authentisierung und eine Digest-Authentisierung. Außerdem ist auch eine Konfiguration möglich, in der ein Mittel zum Authentisieren dieser Objekte eingerichtet ist, ein Mittel zum Abgeben eines Zugriffstokens zur Registrierung des Client an die authentisierten Objekte bereitgestellt ist, und die Clientregistrierung durch Verfikation dieses Zugriffstoken akzeptiert wird. Das HTTP-Servermodul 610 gibt in dem Fall, dass die Authentisierung fehlschlägt, einen Fehler an das Anwendungsmodul 800 zurück.
  • In S1.3, nachdem das Anwendungsmodul 800 authentisiert wurde, kommuniziert das HTTP-Servermodul 610 die von dem Anwendungsmodul 800 empfangene Clientregistrierungsanforderung an das Autorisierungsservermodul 600. Zu dieser Zeit werden auch Informationen zum Identifizieren des authentisierten Anwendungsmoduls 800 kommuniziert. Im Speziellen werden Informationen des erhaltenen Zertifikats kommuniziert.
  • In S1.4 erhält das Autorisierungsservermodul 600 die Informationen des Zertifikats, die von dem HTTP-Servermodul 610 kommuniziert werden. Als Nächstes spezifiziert das Autorisierungsservermodul 600 in S1.5 Informationen der Zertifikat-Verwaltungstabelle 1200 unter Verwendung der Seriennummer, des Ausstellers und des Besitzers des erhaltenen Zertifikats als Schlüssel, und erhält es Informationen des Mandant-Master-DN 1206. Die Konfiguration kann auch derart sein, dass die Verifikation unter Verwendung des Anfangsdatums 1204 und des Enddatums 1205 als Gültigkeitsperiode durchgeführt wird. In dem Fall, dass keine Datensätze in der Zertifikat-Verwaltungstabelle 1200 vorhanden sind, die Gültigkeitsperiode nicht erfolgreich verifiziert wurde, oder dergleichen, gibt das Autorisierungsservermodul 600 hier einen Fehler über das HTTP-Servermodul 610 an das Anwendungsmodul 800 zurück.
  • Als Nächstes erhält das Autorisierungsservermodul 600 in S1.6 die Mandant-ID 1303 aus der Client-Verwaltungstabelle 1300 unter Verwendung des erhaltenen Mandant-Master-DN 1206 als Schlüssel. Die Standardautorisierung-ID 1402 wird dann aus der Standardautorisierung-Verwaltungstabelle 1400 unter Verwendung der erhaltenen Mandant-ID 1303 als Schlüssel erhalten. Es kann der Fall sein, dass mehrere Standardautorisierung-IDs 1402 erhalten werden. In dem Fall, dass nicht einmal eine ID in der Standardautorisierung-Verwaltungstabelle 1400 registriert ist, wird indessen nichts in der Clientautorisierungstabelle 1500 registriert, was nachstehend beschrieben wird.
  • Als Nächstes registriert das Autorisierungsservermodul 600 in S1.7 den Client basierend auf den enthaltenen Informationen neu in der Client-Verwaltungstabelle 1300. Im Speziellen werden die Client-ID und das Geheimnis abgegeben bzw. ausgestellt, wird der DN erzeugt, und werden diese Informationen in 1301, 1302 und 1305 gehalten. Der erhaltene Clientname, die Umleitung-URL und die Mandant-ID, die durch den Mandant-Master-DN 1206 spezifiziert werden, werden dann in 1306, 1307 und 1303 gespeichert. Der Typ 1304 wird zu dieser Zeit auf "allgemein" eingestellt. Dann speichert das Autorisierungsservermodul 600 in S1.8 die Client-ID, die abgegeben und registriert wurde, und die Standardautorisierung-ID, die aus der Standardautorisierung-Verwaltungstabelle 1400 erhalten wird, in der Clientautorisierungstabelle 1500. Zu dieser Zeit werden in dem Fall, dass mehrere Standardautorisierung-IDs erhalten wurden, mehrere Datenstücke gespeichert.
  • Nachdem die Registrierung abgeschlossen ist, gibt das Autorisierungsservermodul 600 in S1.9 die abgegebene Client-ID und das abgegebene Geheimnis über das HTTP-Servermodul 610 an das Anwendungsmodul 800 zurück.
  • Das Vorstehende hat eine Clientregistrierung beschrieben. Durch diese Sequenz kann, wenn ein Client online registriert wird, das Anwendungsmodul 800 identifiziert und die geeignete Autorisierung bzw. Berechtigung bereitgestellt werden.
  • Als Nächstes wird unter Verwendung von 8 eine Sequenz beschrieben, die in dem Anwendungsmodul 800 von der Erlangung des Zugriffstokens bis zu der Erlangung einer Ressource unter Verwendung des Zugriffstokens durchgeführt wird. Es ist zu beachten, dass in 8 "Ref" eine Referenz bezeichnet, die unter Verwendung eines anderen Diagramms beschrieben wird. "Alt" bezeichnet indessen einen Zweig und bezeichnet eine Verzweigung basierend auf Bedingungen, wie etwa einem Ergebnis eines vorhergehenden Prozesses. Der nach der Verzweigung durchgeführte Prozess ist einer der Prozesse, die innerhalb des mit "Alt" bezeichneten Kastens angegeben sind.
  • In S1.10 startet das Anwendungsmodul 800 die Erlangung des Zugangstokens. Es ist zu beachten, dass ein Fall, in dem der Benutzer das Endgerät 400 zum Starten des Anwendungsmoduls 800 benutzt, als ein Auslöser dafür erachtet werden kann, dass die Erlangung des Zugriffstokens startet. Das Anwendungsmodul 800 kann mit einem Vorgang zum expliziten Starten ausgestattet sein, und der Zeitpunkt, zu dem der Benutzter diesen Vorgang unter Verwendung des Endgeräts 400 durchführt, kann als ein weiterer Auslöser erachtet werden. Hier wird der Prozess zum Abgeben des Zugriffstokens gemäß dem in OAuth 2.0 definierten Ablauf durchgeführt. Bei dem vorliegenden Ausführungsbeispiel umfasst der Ablauf von S1.10 zwei Fälle, nämlich Autorisierungscodeerteilung bzw. "Authorization Code Grant" und Clientberechtigungsnachweiserteilung bzw. "Client Credentials Grant", und diese jeweiligen Prozesse werden beschrieben. Der Zugriffstoken-Abgabeprozess durch den Autorisierungscodeerteilungsablauf wird nachstehend unter Verwendung von 14, 15A, 15B und 15C beschrieben. Gleichermaßen wird der Zugriffstoken-Abgabeprozess durch den Clientberechtigungsnachweiserteilungsablauf nachstehend unter Verwendung von 9 beschrieben. Der Zugriffstoken-Abgabeprozess gemäß dem vorliegenden Ausfürungsbeispiel wird unter Verwendung von einem dieser Abläufe durchgeführt. In S1.11 erhält das Anwendungsmodul 800 das Zugriffstoken durch den entsprechenden Zugriffstoken-Erlangungsablauf. In S1.12 nimmt das Anwendungsmodul 800 eine Ressourcenanforderung an dem Ressourcenservermodul 700 unter Verwendung des erhaltenen Zugriffstokens vor. Die Ressourcenanforderung kann durch Auslesen der der Ressource entsprechenden API vorgenommen werden. Das Ressourcenservermodul 700 empfängt die Anforderung und gibt die Antwort zurück, und zwar jeweils über das HTTP-Servermodul 710, das in 8 nicht gezeigt ist.
  • Bei dem vorliegenden Ausführungsbeispiel entspricht die Ressourcenanforderung einer Dienstanforderung durch einen REST-API-Aufruf. Es ist auch eine Konfiguration möglich, in der alle API-Vorgänge bei dem vorliegenden Ausführungsbeispiel über SSL ausgeführt werden und eine gegenseitige Authentisierung unter Verwendung von X.509-Zertifikaten vorgenommen wird.
  • Das Anwendungsmodul 800 kann auf die verschiedenen Typen APIs zugreifen, die durch das Ressourcenservermodul 700 bereitgestellt werden, indem es das erhaltene Zugriffstoken in "Authorization: Bearer" des HTTP-Headers einfügt. Zum Beispiel wird Folgendes erhalten, wenn eine Formularerzeugung-API aufgerufen wird.
    POST /oauth2/v1/form/create HTTP/1.1
    Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw
    Host: example.com
    Hier ist "7Fjfp0ZBr1KtDRbnfVdmIw" das Zugriffstoken.
  • Indessen ist der REST-API-Header wie folgt, wenn zum Beispiel eine API aufgerufen wird, die eine CSV-Datei hochlädt und einen Datensatz erzeugt.
    POST /oauth2/v1/dataset/upload HTTP/1.1
    Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw
    Host: example.com
  • Mit Bezug auf die CSV-Datei, die tatsächlich hochgeladen wird, imitiert diese API das Verhalten des Benutzers beim Eingeben von Daten in das Formular in dem Web-Browser und Drücken einer Schaltfläche "Senden". Das heißt, dass POST-Daten als „Content-Type: multipart/form-data“ gemäß RFC 2388 gesendet werden. Indessen wird Folgendes erhalten, wenn zum Beispiel eine API aufgerufen wird, die die erzeugten Daten druckt.
    GET /oauth2/v1/print?printerid=xxxx&jobid=yyyy HTTP/1.1
    Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw
    Host: example.com
  • In S1.13 nimmt das Ressourcenservermodul 700 eine Zugriffstoken-Verifikationsanforderung an dem Autorisierungsservermodul 600 vor. Obwohl das vorliegende Ausführungsbeispiel die Kommunikation zwischen dem Ressourcenservermodul 700 und dem Autorisierungsservermodul 600 so beschreibt, dass diese über das LAN 101 vorgenommen wird, ist auch eine Konfiguration möglich, in der diese Kommunikation über das WAN 100 vorgenommen wird. Dabei wird die Kommunikation über die jeweiligen HTTP-Servermodule 610 und 710 durchgeführt. Die Verarbeitung, durch die das Autorisierungsservermodul 600 dieses Zugriffstoken verifiziert, die durchgeführt wird, wenn die Zugriffstoken-Verifikationsanforderung empfangen wird, wird nachstehend unter Verwendung von 10 beschrieben. In dem Fall, dass die Zugriffstokenverifikation darin resultiert hat, dass das Zugriffstoken als authentisch verifiziert wird, darf auf die Ressourcen zugegriffen werden, ohne dass gefordert wird, dass Berechtigungsnachweise eingegeben werden.
  • In S1.14 empfängt das Ressourcenservermodul 700 eine Zugriffstoken-Verifikationsantwort von dem Autorisierungsservermodul 600. In dem Fall, dass das Verfikationsergebnis in S1.14 "gültig" bezeichnet, wird ein Ressourcenerlangungsprozess in S1.15 durchgeführt. Dann wird die erhaltene Ressource in S1.16 an das Anwendungsmodul 800 zurückgegeben, und endet der Prozess. Andererseits, in dem Fall, dass das Zugriffstoken-Verifikationsantwortergebnis "ungültig" bezeichnet oder ein API-Grenzenverwaltungsfehler vorliegt, wird in S1.17 eine Fehlerantwort an das Anwendungsmodul 800 gesendet, woraufhin der Prozess endet.
  • Vorstehend wurde eine in dem Anwendungsmodul 800 durchgeführte Sequenz von der Erlangung des Zugriffstokens bis zu der Erlangung einer Ressource unter Verwendung des Zugirffstokens beschrieben.
  • Zugriffstoken-Abgabeprozess durch Autorisierungscodeerteilung
  • Als Nächstes wird unter Verwendung von 14, 15A, 15B und 15C ein Zugriffstoken-Abgabeprozess in dem Fall von Autorisierungscodeerteilung gemäß OAuth 2.0 beschrieben. In S2.1 von 14 nimmt das Anwendungsmodul 800 eine Autorisierungsanforderung an dem HTTP-Servermodul 610 über den Web-Browser 820 vor. In dem HTTP-Servermodul 610 ist der Endpunkt, der die Autorisierungsanforderung annimmt, eingestellt, eine Benutzerauthentisierung anstelle einer Clientauthentisierung anzufordern. Es ist zu beachten, dass die Autorisierungsanforderung zumindest eine Client-ID, die als Ergebnis einer Clientregistrierung erhalten wird, und eine registrierte Umleitung-URL umfasst, ebenso wie ein oder mehrere Umfang-IDs, die zumindest einen Benutzerumfang umfassen, der einen Bereich/Rahmen bzw. eine Auswahl von Ressourcen bezeichnet, von denen erwartet wird, dass sie erhalten werden. Die notwendigen Umfang-IDs sind dem Anwendungsmodul 800 im Voraus bekannt.
  • In S2.2 empfängt das HTTP-Servermodul 610 die Autorisierungsanforderung. Dann gibt das HTTP-Servermodul 610 in S2.3 einen Login-Bildschirm zum Authentisieren des Benutzers an den Web-Browser 820 zurück. 15A veranschaulicht ein Beispiel des durch das HTTP-Servermodul 610 zurückgegebenen Login-Bildschirms. Der Bildschirm gemäß 15A umfasst das Benutzer-ID-Eingabefeld 2001, in das eine Benutzer-ID eingegeben wird, das Passwort-Eingabefeld 2002, in das ein Passwort eingegeben wird, und die Login-Schaltfläche 2003 zum Ausführen des Login-Vorgangs.
  • In S2.4 gibt der Benutzer die erforderlichen Informationen in den gemäß 15A gezeigten Bildschirm ein, der in dem Web-Browser 820 angezeigt wird, und drückt er die Login-Schaltfläche 2003. In S2.5 sendet der Web-Browser 820 die eingegebenen Informationen an das HTTP-Servermodul 610. In S2.6 erhält das HTTP-Servermodul 610 die Benutzer-ID und das Passwort von dem Web-Browser 820, und authentisiert es den Benutzer durch Verifikation, ob ein Satz aus Informationen vorliegt, die mit der Benutzer-ID 1701 und dem Passwort 1702 in der Benutzer-Verwaltungstabelle 1700 übereinstimmen. Die Authentisierung ist erfolgreich, wenn eine Übereinstimmung vorliegt. In dem Fall, dass die Benutzerauthentisierung fehlschlägt, oder mit anderen Worten in dem Fall, dass die Informationen, die erhalten wurden, nicht in der Benutzer-Verwaltungstabelle 1700 registriert sind, gibt das HTTP-Servermodul 610 einen (nicht gezeigten) Authentisierungsfehlerbildschrim an den Web-Browser 820 zurück. In dem Fall, dass die Benutzerauthentisierung erfolgreich ist, erzeugt das HTTP-Servermodul 610 ein Authentisierungstoken. Dieses Authentisierungstoken wird in einem nichtflüchtigen Speicher in dem HTTP-Servermodul 610 in Zusammenhang bzw. Assoziation mit der Benutzer-ID gespeichert. Dann kommuniziert das HTTP-Servermodul 610 in S2.7 die von dem Anwendungsmodul 800 empfangene Autorisierungsanforderung an das Autorisierungsservermodul 600. Dabei wird auch das erzeugte Authentisierungstoken kommuniziert. Obwohl das vorliegende Ausführungsbeispiel eine Passwortauthentisierung verwendet, ist das Verfahren nicht darauf beschränkt, und es kann ebenso eine Konfiguration eingesetzt werden, in der ein anderes Verfahren verwendet wird, das als eine Art und Weise zum Authentisieren eines Benutzers dient, wie etwa eine Verwendung eines X.509-Zertifikats, einer mehrstufigen Authentisierung, in der mehrere Passwörter eingegeben werden, oder dergleichen.
  • In S2.8 verifiziert das Autorisierungsservermodul 600, ob der Satz aus der Client-ID und der Umleitung-URL in der Autorisierungsanforderung korrekt ist. Im Speziellen wird verifiziert, ob ein Satz, der mit dem Satz aus der Client-ID 1301 und der Umleitung-URL 1307 übereinstimmt, die in der Client-Verwaltungstabelle 1300 registriert sind, registriert wurde. In dem Fall, dass keine Übereinstimmung vorliegt, gibt das Autorisierungsservermodul 600 einen (nicht gezeigten) Fehlerbildschirm über das HTTP-Servermodul 610 an den Web-Browser 820 zurück. In dem Fall, dass eine Übereinstimmung vorliegt, erhält jedoch das Autorisierungsservermodul 600 in S2.9 Benutzerinformationen. Im Speziellen wird die zugehörige Benutzer-ID von dem HTTP-Servermodul 610 unter Verwendung des Authentisierungstokens erhalten, das von dem HTTP-Servermodul 610 kommuniziert wird. Zum Beispiel wird, da das HTTP-Servermodul 610 die Login-Informationen einschließlich der Benutzer-ID zusammen mit dem Zugriffstoken empfangen hat, die mit dem Zugriffstoken in Zusammenhang bzw. Assoziation stehende Benutzer-ID von dem HTTP-Servermodul 610 erhalten. Basierend auf dieser Benutzer-ID wird die Autorisierung-ID 1802 aus der Benutzerautorisierungstabelle 1800 erhalten. Dabei ist die erhaltene Autorisierung-ID 1802 nicht auf eine einzelne ID beschränkt und können 0 oder mehrere Autorisierung-IDs 1802 erhalten werden. Obwohl das vorliegende Ausführungsbeispiel die Erlangung der Benutzerinformationen so beschreibt, dass diese durch ein Verfahren durchgeführt wird, das die Benutzer-ID basierend auf dem Authentisierungstoken erhält, woraufhin das Autorisierungsservermodul 600 die Benutzerinformationen erhält, ist das Verfahren nicht darauf beschränkt. Zum Beispiel ist auch eine Konfiguration möglich, in der die erforderlichen Benutzerinformationen von dem HTTP-Servermodul 610 kommuniziert werden, ebenso wie eine Konfiguration, in der die erforderlichen Benutzerinformationen erhalten werden, indem das Authentisierungstoken an das HTTP-Servermodul 610 weitergegeben wird.
  • In S2.10 erhält das Autorisierungsservermodul 600 die Autorisierung-ID 1604 von jedem Umfang aus der Umfangstabelle 1600 unter Verwendung der Umfang-ID des Umfangs, der in der Autorisierungsanforderung umfasst ist, als Schlüssel. Dann verifiziert das Autorisierungsservermodul 600 in S2.11, ob die für jeden Umfang erhaltene Autorisierung-ID 1604 in der Autorisierung-ID 1802 umfasst ist, die der Benutzer-ID entspricht, die in S2.9 aus der Benutzerautorisierungstabelle 1800 erhalten wird. Die Autorisierungsanforderung wird in dem Fall angenommen, dass alle Autorisierungen, die zu dem Umfang gehören, der in der Autorisierungsanforderung von dem Benutzer umfasst ist, dem Benutzer bereitgestellt bzw. zur Verfügung gestellt wurden, und wird abgelehnt, wenn dies nicht der Fall ist. Im Speziellen werden Autorisierung-IDs, die mit der in der Autorisierungsanforderung umfassten Umfang-ID in Zusammenhang bzw. Assoziation stehen, aus der Umfangstabelle 1600 erhalten, und wird die Autorisierungsanforderung in dem Fall, dass die Autorisierung-IDs eingestellt bzw. gesetzt sind, die in Zusammenhang bzw. Assoziation mit dem Benutzer der Benutzerautorisierungstabelle 1800 erhalten werden, als gültig bestimmt. In dem Fall, dass mehrere Autorisierung-IDs 1604 vorliegen, die mit der Umfang-ID in der Umfangstabelle 1600 in Zusammenhang bzw. Assoziation stehen, wird hier, wenn zumindest eine Autorisierung-ID dieser mehreren Autorisierung-IDs 1604 für den in Frage stehenden Benutzer eingestellt bzw. gesetzt ist, die Autorisierungsanforderung hinsichtlich dieser Autorisierung als gültig betrachtet. Wahlweise kann in dem Fall, dass alle Autorisierung-IDs, die mit dem angeforderten Umfang in Zusammenhang bzw. Assoziation stehen, für den in Frage stehenden Benutzer eingestellt bzw. gesetzt sind, die Autorisierungsanforderung hinsichtlich dieser Autorisierung das erste Mal als gültig betrachtet werden. Indessen wird in dem Fall, dass eine Autorisierung-ID, die mit der Umfang-ID in Zusammenhang bzw. Assoziation steht, für diesen Benutzer nicht eingestellt bzw. gesetzt ist, die Autorisierungsanforderung hinsichtlich dieser Autorisierung ungeachtet der Autorisierung des Benutzers als ungültig betrachtet. In dem Fall, dass zumindest eine Autorisierung-ID in dem in der Autorisierungsanforderung umfassten Umfang ungültig ist, gibt das Autorisierungsservermodul 600 in S2.28 einen Autorisierungsfehler an den Web-Browser 820 zurück. Dann gibt der Web-Browser 820 in S2.29 den Autorisierungsfehler an das Anwendungsmodul 800 zurück. Im Speziellen wird eine Umleitung an den Web-Browser 820 zurückgegeben, so dass der Web-Browser 820 eine Umleitung an die Umleitung-URL vornimmt, die zu der Zeit der Autorisierungsanforderung erhalten wird. In S2.30 gibt das Anwendungsmodul 800 einen Autorisierungsfehlerbildschirm, von dem ein Beispiel gemäß 15C gezeigt ist, an den Web-Browser 820 zurück, woraufhin der Prozess endet.
  • In dem Fall, dass die Autorisierung-IDs für alle Umfänge gültig sind, die in der Autorisierungsanforderung umfasst sind, gibt das Autorisierungsservermodul 600 in S2.12 einen Autorisierungsbestätigungsbildschirm an den Web-Browser 820 zurück. 15B veranschaulicht ein Beispiel des hier zurückgegebenen Autorisierungsbestätigungsbildschirms. Ein Autorisierungsbestätigungsbildschirm 2100 umfasst einen Zugriffsquelle-Anzeigebereich 2101, der ein Bereich ist, der den Clientnamen 1306 anzeigt, der aus der Client-Verwaltungstabelle 1300 unter Verwendung der in der Autorisierungsanforderung umfassten Client-ID als Schlüssel erhalten wird. Der Autorisierungsbestätigungsbildschirm 2100 umfasst auch einen Umfang-Anzeigebereich 2102, der ein Bereich ist, der die Beschreibung 1603 des Umfangs anzeigt, der aus der Umfangstabelle 1600 unter Verwendung der in der Autorisierungsanforderung umfassten Umfang-ID als Schlüssel erhalten wird. Außerdem umfasst der Autorisierungsbestätigungsbildschirm 2100 eine Zulassen-Schaltfläche 2103, durch die ein Benutzer einen Autorisierungsvorgang für die Einzelheiten der vorgenannten Informationen ausführt, und eine Ablehnen-Schaltfläche 2104, die eine Ablehnung ausführt. In dem Fall, dass der Benutzer die Ablehnen-Schaltfläche 2104 gedrückt hat, gibt das Autorisierungsservermodul 600 in S2.28 einen Autorisierungsfehler an das Anwendungsmodul 800 zurück, und zwar auf die gleiche Art und Weise, als wenn ein Ergebnis einer Verifikation der Besitzerautorisierung "ungültig" angibt. Die Konfiguration kann derart sein, dass die Autorisierungsfehlerantworten auf einem Bildschirm durch das Anwedungsmodul 800 angezeigt werden, das die Antworten empfängt, oder Text so geändert wird, dass die Einzelheiten der Fehlerantworten unterschieden werden können.
  • In S2.13 wird in dem Fall, dass der Benutzer die Zulassen-Schaltfläche 2103 auf dem Autorisierungsbestätigungsbildschirm 2100 gedrückt hat, oder mit anderen Worten in dem Fall, dass der Autorisierungsvorgang durchgeführt wurde, das Autorisierungsservermodul 600 in S2.14 über den Web-Browser 820 darüber benachrichtigt, dass die Autorisierung erfolgreich ist.
  • In S2.15 gibt das Autorisierungsservermodul 600 einen Zugriffscode ab. Im Speziellen wird eine Zugriffstoken-ID abgegeben, werden die in den Autorisierungsanforderungen umfassten Umfang-ID und Client-ID authentisiert, und wird die Benutzer-ID des Benutzers, für den eine Autorisierung erlangt wurde, in der Zugriffstoken-Verwaltungstabelle 1900 als eine Besitzer-ID 1906 registriert. Dabei wird der Tokentyp 1902 als der Zugriffscode verwendet, und wird ein Datum, bis zu dem der Zugriffscode gültig ist, in dem Ablaufdatum 1903 registriert. Dann sendet das Autorisierungsservermodul 600 in S2.16 und S2.17 eine Autorisierungsantwort, die die Zugriffstoken-ID des abgegebenen Zugriffscodes umfasst, über den Web-Browser 820 an das Anwendungsmodul 800. Im Speziellen wird eine Umleitung an den Web-Browser 820 zurückgegeben, so dass der Web-Browser 820 eine Umleitung auf die Umleitung-URL vornimmt, die zu der Zeit der Autorisierungsanforderung erhalten wird.
  • In S2.18 fordert das Anwendungsmodul 800 ein Zugriffstoken von dem Autorisierungsservermodul 600 an. Diese Zugriffstokenanforderung umfasst zumindest den erhaltenen Zugriffscode, die Client-ID, das Geheimnis und die Umleitung-URL, die zu der Zeit der Autorisierungsanforderung gesendet wird/werden.
  • In S2.19 verwendet das Autorisierungsservermodul 600 einen Satz, der die erhaltene Client-ID und das Geheimnis umfasst, um den Client zu authentisieren. Im Speziellen wird die Authentisierung durch Verifikation einer Übereinstimmung mit einem Satz aus der Client-ID 1301 und dem Geheimnis 1302 in der Client-Verwaltungstabelle 1300 vorgenommen. In dem Fall, dass eine Clientauthentisierung fehlgeschlagen ist, gibt das Anwendungsmodul 800 einen Authentisierungsfehler zurück. In dem Fall, dass die Clientauthentisierung erfolgreich ist, verifiziert das Autorisierungsservermodul 600 den erhaltenen Zugriffscode in S2.20. Der Zugriffscode wird verifiziert, indem bestimmt wird, ob die Zugriffstoken-ID in dem erhaltenen Zugriffscode in der Zugriffstoken-Verwaltungstabelle 1900 registriert ist, und verifiziert wird, ob das Ablaufdatum 1903 noch nicht verstrichen ist, falls die Zugriffstoken-ID registriert ist. Falls die Zugriffstoken-ID nicht registriert ist, wird ein Autorisierungsfehler in S2.26 zurückgegeben. Außerdem wird unter Verwendung der mit der Zugriffstoken-ID in Zusammenhang bzw. Assoziation stehenden Client-ID 1905 als Schlüssel verifiziert, ob die durch die Zugriffstokenanforderung erhaltenen Umleitung-URL mit der in der Client-Verwaltungstabelle 1300 registrierten Umleitung-URL 1307 übereinstimmt. In dem Fall, dass das Zugriffscode-Verifikationsergebnis "ungültig" angibt, gibt das Autorisierungsservermodul 600 einen Tokenungültigkeitsfehler an das Anwendungsmodul 800 zurück. In dem Fall, dass das Zugriffscode-Verifikationsergebnis "gültig" angibt, erhält jedoch das Autorisierungsservermodul 600 in S2.21 die Clientinformationen. Im Speziellen wird die Autorisierung-ID 1502 aus der Clientautorisierungstabelle 1500 unter Verwendung der authentisierten Client-ID als Schlüssel erhalten. Dabei können null oder mehrere Autorisierung-ID 1502 erhalten werden.
  • In S2.22 erhält das Autorisierungsservermodul 600 die Umfang-ID 1904 aus der Zugriffstoken-Verwaltungstabelle 1900 unter Verwendung der Zugriffstoken-ID des erhaltenen Zugriffscodes als Schlüssel. Als Nächstes wird die Autorisierung-ID 1604 von jedem Umfang aus der Umfangstabelle 1600 unter Verwendung der Umfang-ID des erhaltenen Umfangs als Schlüssel erhalten. Zu dieser Zeit gibt das Clientautorisierung-Verifikationsergebnis "gültig" an, falls der Umfang nicht in der Umfang-ID umfasst ist, die aus der Zugriffstoken-Verwaltungstabelle 1900 erhalten wird. Jedoch kann die in Schritt S2.23 durchgeführte standardmäßige Verarbeitung durchgeführt werden, anstatt diesen Fall als Ausnahme zu behandeln. In einer solchen Situation wird der besagte Fall als ungültig bestimmt.
  • In S2.23 verifiziert das Autorisierungsservermodul 600, ob die Autorisierung-ID 1604 für jeden in S2.22 erhaltenen Umfang in der Autorisierung-ID 1502 umfasst ist, die aus der Clientautorisierungstabelle 1500 erhalten wird. Die Autorisierungsanforderung wird in dem Fall angenommen, dass alle Autorisierungen, die zu dem Umfang gehören, der in dem durch den Client angeforderten Zugriffstoken umfasst ist, diesem Client bereitgestellt bzw. zur Verfügung gestellt wurden, und wird abgelehnt, wenn dies nicht der Fall ist. Genauer gesagt wird daher die Autorisierung-ID, die der mit dem angeforderten Zugriffstoken in Zusammenhang bzw. Assoziation stehenden Umfang-ID entspricht, aus der Umfangstabelle 1600 erhalten, und wird die Autorisierungsanforderung in dem Fall als gültig bestimmt, dass die in Zusammenhang bzw. Assoziation mit diesem Client erhaltene Autorisierung-ID in der Clientautorisierungstabelle 1500 in dieser Autorisierung-ID eingestellt bzw. gesetzt ist. In dem Fall, dass es mehrere Autorisierung-IDs 1604 gibt, die mit der Umfang-ID in der Umfangstabelle 1600 in Zusammenhang bzw. Assoziation stehen, wird hier die Autorisierungsanforderung als gültig betrachtet, wenn zumindest eine Autorisierung-ID von diesen mehreren Autorisierung-IDs 1604 für den Client eingestellt bzw. gesetzt ist. Wahlweise kann in dem Fall, dass alle Autorisierung-IDs, die mit dem angeforderten Umfang in Zusammenhang bzw. Assoziation stehen, für den in Frage stehenden Client eingestellt bzw. gesetzt sind, die Autorisierungsanforderung hinsichtlich dieser Autorisierung das erste Mal als gültig betrachtet werden. In dem Fall, dass eine mit der Umfang-ID in Zusammenhang bzw. Assoziation stehende Autorisierung-ID nicht eingestellt bzw. gesetzt ist, wird jedoch die Autorisierungsanforderung ungeachtet der Clientautorisierung als ungültig betrachtet. In dem Fall, dass die Verifikation für zumindest eine Autorisierung-ID in dem mit dem Zugriffscode in Zusammenhang bzw. Assoziation stehenden Umfang ungültig angibt, gibt das Autorisierungsservermodul 600 in S2.26 einen Autorisierungsfehler an das Anwendungsmodul 800 zurück. Dann gibt das Anwendungsmodul 800 in S2.27 den Autorisierungsbildschirm, von dem ein Beispiel gemäß 15C gezeigt ist, an den Web-Browser 820 zurück, woraufhin der Prozess endet.
  • In dem Fall, dass alle mit dem Zugriffscode in Zusammenhang bzw. Assoziation stehende Umfänge gültig sind, führt das Autorisierungsservermodul 600 in S2.30 einen API-Zählprozess aus. Dabei wird der Prozess unter Verwendung des Umfangs und der authentisierten Client-ID ausgeführt. Der API-Zählprozess ist ein Prozess zum Bestimmen, ob die Benutzungszahl bzw. -häufigkeit der benutzen API den Grenzwert überschreiten wird. Der API-Zählprozess wird gemäß dem in 11 gezeigten Vorgang durchgeführt, der nachstehend ausführlich beschrieben wird. In dem Fall, dass der API-Zählprozess fehlschlägt, gibt das Autorisierungsservermodul 600 einen Fehler an das Anwendungsmodul 800 zurück, und endet der Prozess.
  • In dem Fall, dass der API-Zählprozess erfolgreich ist, gibt das Autorisierungsservermodul 600 jedoch in S2.24 das Zugriffstoken ab. Im Speziellen wird die Zugriffstoken-ID abgegeben und werden die Umfang-ID, die Benutzer-ID die authentisierte Client-ID in Zusammenhang bzw. Assoziation mit dem Zugriffscode in der Zugriffstoken-Verwaltungstabelle 1900 registriert. Dabei wird der Tokentyp 1902 als das Zugriffstoken verwendet, und wird ein Datum, bis zu dem das Zugriffstoken gültig ist, in dem Ablaufdatum 1903 registriert. Dann gibt das Autorisierungsservermodul 600 in S2.24 die Zugriffstoken-ID des abgegebenen Zugriffstokens an das Anwendungsmodul 800 zurück, und endet der Prozess. Es kann auch eine Konfiguration eingesetzt werden, in der das Ablaufdatum des Zugriffstokens zu dieser Zeit zurückgegeben wird. Obwohl das vorliegende Ausführungsbeispiel ein Beispiel beschreibt, in dem ein Auffrischungstoken zum Aktualisieren des Zugriffstokens nicht abgegeben wird, kann auch eine Konfiguration eingesetzt werden, in der eine Auffrischungstoken-ID und ein Ablaufdatum in der Zugriffstoken-Verwaltungstabelle 1900 verwaltet werden. Hier kann eine Konfiguration eingesetzt werden, in der das Auffrischungstoken zu der gleichen Zeit wie das Zugriffstoken abgegeben wird und die ID des Auffrischungstokens, das abgegeben wurde, in der Antwort auf das Zugriffstoken umfasst ist.
  • Zugriffstoken-Abgabeprozess durch Clientberechtigungsnachweiserteilung.
  • Als Nächstes wird unter Verwendung von 9 ein Zugriffstoken-Abgabeprozess in dem Fall von Clientberechtigungsnachweiserteilung gemäß OAuth 2.0 beschrieben.
  • In S3.1 fordert das Anwendungsmodul 800 ein Zugriffstoken von dem Autorisierungsservermodul 600 an. Diese Zugriffstokenanforderung umfasst eine oder mehrere Umfang-IDs, die zumindest die Client-ID, ein Geheimnis und zumindest einen Umfang umfassen, der einen Bereich/Rahmen bzw. eine Auswahl von Ressourcen angibt, von denen erwartet wird, dass sie erhalten werden.
  • Der Umfang gemäß dem vorliegenden Ausführungsbeispiel entspricht einer Zugriff-API mit Bezug auf eine Ressource, auf die durch den Umfang Bezug genommen werden kann, oder eine Gruppe, die eine Reihe von Zugriff-APIs umfasst. Der Umfang und die Zugriff-API entsprechen auch verschiedenen Typen von Diensten gemäß dem vorliegenden Ausführungsbeispiel. Ein Zugriffstoken mit einer einzelnen Umfang-ID ist erforderlich, wenn eine API für eine einzelne Ressource und ein einzelnen Dienst aufgerufen wird. Indessen ist ein Zugriffstoken mit mehreren Umfang-IDs erforderlich, wenn eine API für eine Reihe von Diensten aufgerufen wird, in der mehrere Dienste zusammenarbeiten.
  • In S3.2 verwendet das Autorisierungsservermodul 600 einen Satz, der die erhaltene Client-ID und das Geheimnis umfasst, um den Client zu authentisieren. Im Speziellen wird die Authentisierung durch Verifikation einer Übereinstimmung mit einem Satz aus der Client-ID 1301 und dem Geheimnis 1302 in der Client-Verwaltungstabelle 1300 durchgeführt. In dem Fall, dass eine Clientauthentisierung fehlschlägt, gibt das Anwendungsmodul 800 einen Authentisierungsfehler zurück. In dem Fall, dass die Clientauthentisierung erfolgreich ist, erhält das Autorisierungsservermodul 600 in S.3.3 die Clientinformationen. Im Speziellen wird die Autorisierung-ID 1502 aus der Clientautorisierungstabelle 1500 unter Verwendung der authentisierten Client-ID als Schlüssel erhalten. Dabei können null oder mehrere Autorisierung-IDs 1502 erhalten werden.
  • In S3.4 erhält das Autorisierungsservermodul 600 die Autorisierung-ID 1604 von jedem Umfang aus der Umfangstabelle 1600 unter Verwendung der Umfang-ID des in der Zugriffstokenanforderung umfassten Umfangs als Schlüssel. Dabei gibt das Clientautorisierung-Verifikationsergebnis in dem Fall, dass der Umfang nicht in der in der Zugriffstokenanforderung umfassten Umfang-ID umfasst ist, "gültig" an. Die standardmäßige Verarbeitung, die in Schritt S3.5 durchgeführt wird, kann jedoch ausgeführt werden, anstatt diesen Fall als Ausnahme zu behandeln. In einer solchen Situation wird der besagte Fall als ungültig bestimmt.
  • In S3.5 verifiziert das Autorisierungsservermodul 600, ob die Autorisierung-ID 1604 für jeden erhaltenen Umfang in der aus der Clientautorisierungstabelle 1500 erhaltenen Autorisierung-ID 1502 umfasst ist. Dabei wird in dem Fall, dass es mehrere Autorisierung-ID 1604 gibt, die mit der Umfang-ID in der Umfangstabelle 1600 in Zusammenhang bzw. Assoziation stehen, die Autorisierungsanforderung als gültig betrachtet, wenn zumindest eine Autorisierung-ID von diesen mehreren Autorisierung-IDs 1604 für den Client eingestellt bzw. gesetzt ist. In dem Fall, dass eine mit der Umfang-ID in Zusammenhang bzw. Assoziation stehende Autorisierung-ID nicht eingestellt bzw. gesetzt ist, wird jedoch die Autorisierungsanforderung ungeachtet der Clientautorisierung als ungültig betrachtet.
  • Der Prozess schreitet in dem Fall, dass das Verifikationsergebnis für zumindest eine Autoriserung-ID in den in der Zugriffstokenanforderung umfassten Umfängen "ungültig" angibt, zu S3.10 voran. In S3.10 gibt das Autorisierungsservermodul 600 einen Autorisierungsfehler an das Anwendungsmodul 800 zurück, und endet der Prozess.
  • In dem Fall, in dem die Verifikation für alle in der Zugriffstokenanforderung umfassten Umfänge "gültig" angibt, führt das Autorisierungsservermodul 600 in S3.6 den API-Zählprozess aus. Dabei wird der Prozess unter Verwendung des Umfangs und der authentisierten Client-ID ausgeführt. Einzelheiten des API-Zählprozesses werden nachstehend gegeben. In dem Fall, dass der API-Zählprozess fehlgeschlagen ist, gibt das Autorisierungsservermodul 600 einen Fehler an das Anwendungsmodul 800 zurück, und endet der Prozess.
  • In dem Fall, dass der API-Zählprozess erfolgreich ist, gibt das Autorisierungsservermodul 600 jedoch in S3.8 das Zugriffstoken ab. Im Speziellen wird die Zugriffstoken-ID gegeben und werden die in der Zugriffstokenanforderung umfasste Umfang-ID, die Client-ID des authentisierten Clients und die Client-ID, die als die Benutzer-ID dient, in der Zugriffstoken-Verwaltungstabelle 1900 registriert. Dabei wird der Tokentyp 1902 als das Zugriffstoken verwendet, und wird ein Datum, bis zu dem der Zugriffscode gültig ist, in dem Ablaufdatum 1903 registriert. Dann gibt das Autorisierungsservermodul 600 in S3.9 die Zugriffstoken-ID des abgegebenen Zugriffstokens an das Anwendungsmodul 800 zurück, und endet der Prozess. Es kann auch eine Konfiguration eingesetzt werden, in der das Ablaufdatum des Zugriffstokens zu dieser Zeit zurückgegeben wird.
  • Zugriffstoken-Verifikationsprozess
  • Als Nächstes wird unter Verwendung von 10 ein Zugriffstoken-Verifikationsprozess beschrieben. 10 veranschaulicht den Ablauf eines Zugriffstoken-Verifikationsprozesses, der durch das Autorisierungsservermodul 600 ausgeführt wird. In dem gemäß 8 gezeigten Ablauf nimmt das Anwendungsmodul 800 eine Ressourcenanforderung (einen API-Aufruf) in S1.12 vor, nachdem es in S1.11 das Zugriffstoken erhält. Wenn dann eine Verifikationsanforderung von dem Ressourcenservermodul 700 in Erwiderung auf die besagte Anforderung an das Autorisierungsservermodul 600 abgegeben wird, führt das Autorisierungsservermodul 600 den Zugriffstoken-Verifikationsprozess durch, und verwaltet es weiterhin die API-Benutzungszahlgrenze mittels Durchführung des API-Zählprozesses. Der Verifikationsprozess, der den API-Zählprozess umfasst, wird als Nächstes beschrieben.
  • In Schritt S4.1 empfängt das Autorisierungsservermodul 600 eine Zugriffstoken-Verifikationsanforderung von dem Ressourcenservermodul 700. Die Zugriffstoken-Verifikationsanforderung umfasst die Zugriffstoken-ID des zu verifizierenden Zugriffstokens und zumindest eine Umfang-ID. In Schritt S4.2 erhält das Autorisierungsservermodul 600 die Zugriffstoken-ID und die Umfang-ID. Als Nächstes erhält das Autorisierungsservermodul 600 in Schritt S4.3 Informationen des Zugriffstokens basierend auf der erhaltenen Zugriffstoken-ID. Im Speziellen wird das Ablaufdatum 1903 aus der Zugriffstoken-Verwaltungstabelle 1900 unter Verwendung der Zugriffstoken-ID und eines Tokentyps "Zugriffstoken" als Schlüssel erhalten. Dann wird in Schritt S4.4 verifiziert, ob das Zugriffstoken vorhanden ist, oder mit anderen Worten, ob das Zugriffstoken in der Zugriffstoken-Verwaltungstabelle vorhanden ist, und ob das Zugriffstoken noch innerhalb des Ablaufdatums liegt. In dem Fall, dass die Verifikation angibt, dass das Zugriffstoken nicht vorhanden ist, oder vorhanden ist, aber nicht innerhalb des Ablaufdatums liegt, wird das Zugriffstoken als ungültig bestimmt, wird in Schritt S4.5 ein Tokenungültigkeitsfehler zurückgegeben, und endet der Prozess. In dem Fall, dass das Verifikationsergebnis angibt, dass das Zugriffstoken vorhanden ist und innerhalb des Ablaufdatums liegt, wird der Prozess fortgesetzt.
  • In Schritt S4.6 erhält das Autorisierungsservermodul 600 Informationen des in der Verifikationsanforderung umfassten Umfangs. In Speziellen werden der Typ 1602 und die Autorisierung-ID 1604 von jedem Umfang aus der Umfangstabelle 1600 unter Verwendung der Umfang-ID als Schlüssel erhalten.
  • Als Nächstes bestimmt das Autorisierungsservermodul 600 in Schritt S4.11, ob zumindest ein Clientumfang in dem Typ 1602 der ein oder mehrere Umfänge, die in S4.6 erhalten werden, umfasst ist. Der Prozess schreitet in dem Fall, dass nicht einmal ein Umfang vorliegt, zu Schritt S4.15 voran. In dem Fall, dass zumindest ein Umfang vorliegt, erhält das Autorisierungsservermodul 600 jedoch in Schritt S4.12 die Clientinformationen. Im Speziellen wird eine Client-ID 1907 aus der Zugriffstoken-Verwaltungstabelle 1900 unter Verwendung der Zugriffstoken-ID als Schlüssel erhalten, und wird die Autorisierung-ID 1502 aus der Clientautorisierungstabelle 1500 unter Verwendung der erhaltenen Client-ID als Schlüssel erhalten. Dabei können 0 oder mehrere Autorisierung-IDs 1502 erhalten werden.
  • Als Nächstes führt das Autorisierungsservermodul 600 in Schritt S4.13 eine Autorisierungsverifikation bezüglich des in Schritt S4.6 erhaltenen Clientumfangs durch. Im Speziellen wird die Autorisierung-ID 1604 von jedem Clientumfang aus der Umfangstabelle 1600 unter Verwendung der in S4.6 erhaltenen Clientumfang-ID als Schlüssel erhalten. Es wird dann verifiziert, ob die Autorisierung-ID 1604 für jeden erhaltenen Clientumfang in der in Schritt S4.12 erhaltenen Autorisierung-ID 1502 umfasst ist. Das Zugriffstoken wird in dem Fall angenommen, dass alle Autorisierungen, die zu dem Umfang gehören, der mit dem Client des zu verifizierenden Zugriffstokens in Zusammenhang bzw. Assoziation steht, diesem Zugriffstoken bereitgestellt bzw. zur Verfügung gestellt wurden, und abgelehnt, wenn dies nicht der Fall ist. Dementsprechend wird zum Beispiel die Autorisierung-ID, die der Umfang-ID entspricht, die mit dem zu verifizierenden Zugriffstoken in Zusammenhang bzw. Assoziation steht, aus der Umfangstabelle 1600 erhalten, und wird in dem Fall, dass die Autorisierung-ID, die in Zusammenhang bzw. Assoziation mit dem Client dieses Zugriffstokens erhalten wird, in dieser Autorisierung-ID eingestellt bzw. gesetzt ist, diese Autorisierungsanforderung als gültig bestimmt. In dem Fall, dass es mehrere Autorisierung-IDs 1604 gibt, die mit der Clientumfang-ID in der Umfangstabelle 1600 in Zusammenhang bzw. Assoziation stehen, wird hier, wenn zumindest eine Autorisierung-ID von diesen mehreren Autorisierung-IDs 1604 für den Client eingestellt bzw. gesetzt ist, die Autorisierungsanforderung als gültig betrachtet. In dem Fall, dass keine mit der Clientumfang-ID in Zusammenhang bzw. Assoziation stehende Autorierung-ID eingestellt bzw. gesetzt ist, wird jedoch die Autorisierungsanforderung ungeachtet der Clientautorisierung als ungültig betrachtet. In dem Fall, dass das Ergebnis der Verifikation für zumindest eine Autorisierung-ID "ungültig" angibt, gibt das Autorisierungsservermodul 600 in Schritt S4.14 einen Autorisierungsfehler an das Ressourcenservermodul 700 zurück, und endet der Prozess. In dem Fall, dass das Verifikationsergebnis für alle in S4.6 erhaltene Clientumfänge "gültig" angibt, schreitet das Autorisierungsservermodul 600 zu Schritt S4.15 voran.
  • In Schritt S4.15 führt das Autorisierungsservermodul 600 den API-Zählprozess durch, der nachstehend beschrieben wird, um die API-Benutzungsgrenzzahl zu verwalten. In Schritt S4.16 wird bestimmt, ob der API-Zählprozess erfolgreich war oder fehlgeschlagen ist, und in dem Fall, dass der Prozess erfolgreich war, wird in Schritt S4.17 eine Antwort, die angibt, dass die API ausgeführt werden kann, an das Ressourcenservermodul 700 zurückgegeben, woraufhin der Prozess endet. Wenn jedoch der API-Zählprozess in Schritt S4.16 fehlgeschlagen ist, gibt das Autorisierungsservermodul 600 einen API-Grenzzahlverwaltungsfehler an das Ressourcenservermodul 700 zurück, woraufhin der Prozess endet.
  • API-Zählprozess
  • 11 ist ein Ablaufdiagramm, das einen API-Zählprozess veranschaulicht, der durch das Autorisierungsservermodul 600 während das in 10 gezeigten Zugriffstoken-Verifikationsprozess ausgeführt wird. In Schritt S5.1 erhält das Autorisierungsservermodul 600 eine Mandant-ID, die mit dem zu verifizierenden Zugriffstoken in Zusammenhang bzw. Assoziation steht. Im Speziellen wird die Client-ID 1905 des Zugriffstokens erhalten, die durch die Zugriffstoken-ID 1901 in der Zugriffstoken-Verwaltungstabelle 1900 bezeichnet wird. Außerdem wird basierend auf der Client-ID 1301 auf eine Zeile in der gemäß 4B gezeigten Client-Verwaltungstabelle 1300 Bezug genommen, die der Client-ID entspricht, und wird der Wert der entsprechenden Mandant-ID 1303 erhalten. Als Nächstes nimmt das Autorisierungsservermodul 600 in Schritt S5.2 auf die Mandant-ID 1951 und die Umfang-ID 1952 in der API-Benutzungszahl-Verwaltungstabelle 1950 Bezug, die mit der Mandant-ID und der Umfang-ID übereinstimmen, die vorher erhalten werden. Die API-Benutzungszahl 1955 in der vorher unter Bezug genommenen Zeile wird dann inkrementiert. Weiterhin bestätigt das Autorisierungsservermodul 600 in Schritt S5.3 den Wert der API-Benutzungsgrenzzahl 1954 in der Zeile der API-Benutzungszahl-Verwaltungstabelle 1950, auf die vorher Bezug genommen wurde, und vergleicht es die API-Benutzungszahl 1955 (nämlich eine Zugriffszahl bzw. -häufigkeit) mit der API-Benutzungsgrenzzahl 1954 (nämlich einer Zugriffsgrenzzahl bzw. -häufigkeit). Wenn die API-Benutzungszahl 1955 die API-Benutzungsgrenzzahl 1954 in Schritt S5.3 nicht überschritten hat, wird bestimmt, dass die API-Benutzung innerhalb der API-Benutzungszahl- bzw. -häufigkeitsgrenze liegt, wird in Schritt S5.4 "Erfolg" zurückgegeben, und endet der Prozess. Wenn jedoch die API-Benutzungszahl 1955 die API-Benutzungsgrenzzahl 1954 in Schritt S5.3 überschritten hat, wird bestimmt, dass die API-Benutzung die API-Benutzungszahl- bzw. -häufigkeitsgrenze überschritten hat, wird in Schritt S5.5 "Fehler" zurückgegeben, und endet der Prozess.
  • Durch diese Sequenzen nimmt das Ressourcenservermodul 700 nur einen Zugriff von einem Anwendungsmodul 800 mit der geeigneten Autorisierung bzw. Berechtigung an, und kann es unbeabsichtigte Autorisierungs- bzw. Berechtigungsfehler von dem Anwendungsmodul 800 verhindern. Außerdem kann gemäß dem vorliegenden Ausführungsbeispiel eine Aufrufgrenzzahl bzw. -häufigkeit für eine Zugriff-API oder eine Gruppe einer Reihe von Zugriff-APIs hinsichtlich einer Ressource, auf die basierend auf dem Umfang Bezug genommen werden kann, pro Mandant verwaltet bzw. geregelt werden, und kann sie weiterhin pro Dienst verwaltet bzw. geregelt werden. Dementsprechend kann ein Abfall in der Qualität von verschiedenen Typen von Diensten, die durch das Ressourcenservermodul 700 bereitgestellt werden, der durch die übermäßige Benutzung von Diensten und APIs in einem bestimmten Mandanten verursacht wird, basierend auf dem QoS-Konzept (QoS: "Quality of Service" bzw. Dienstgüte) verhindert werden.
  • Weiterhin wird der API-Zählprozess, der bestimmt, ob die API-Benutzungszahl bzw. -häufigkeit eine Grenzzahl bzw. -häufigkeit innerhalb einer eingestellten Periode überschritten hat, durch das Autorisierungsservermodul 600 durchgeführt, das die Zugriffstokenanforderung empfängt, und zwar während des durch das Anwendungsmodul 800 durchgeführten Zugriffstoken-Erlangungsprozesses (S2.30 und S3.6). Dies hängt nicht davon ab, ob das verwendete Protokoll Clientberechtigungsnachweiserteilung oder Autorisierungscodeerteilung ist. Außerdem wird der API-Zählprozess in dem Zugriffstoken-Verifikationsprozess selbst dann durchgeführt, nachdem das Zugriffstoken erhalten wurde, und selbst dann, wenn eine Anforderung für eine Ressource an den Ressourcenserver unter Verwendung dieses Zugriffstokens vorgenommen wird (S1.20). Dadurch werden Zugriffstokens, die aufgrund der Grenze bezüglich der Benutzungszahl bzw. -häufigkeit der in dem Umfang umfassten APIs nicht benutzt werden können, nicht länger abgegeben bzw. ausgestellt, was es möglich macht, Verarbeitungsressourcen, Kommunikationsressourcen, und so weiter einzusparen.
  • Zweites Ausführungsbeispiel
  • Wenn eine API-Benutzungsgrenzzahl bzw. -häufigkeit auf der Dienstebene (Umfangsebene) für einen bestimmten Mandanten besteht, und der Client die API eines einzelnen Diensts übermäßig benutzt und die Grenze überschritten hat, ist es möglich, dass eine Reihe von Funktionen, die den besagten Dienst mit anderen Diensten kombinieren, auf halbem Weg bzw. während des Ablaufs auf einen Fehler stoßen werden. Dabei können DataSetService bzw. Datensatzdienst, FormService bzw. Formulardienst, PrintService bzw. Druckdienst und DataSet-FormPrintService bzw. Datensatz-/Formular-/Druckdienst in der Umfang-ID 1601, die in der in 5A gezeigten Umfangstabelle 1600 definiert ist und bei dem vorgenannten Ausführungsbeispiel beschrieben ist, in Betracht gezogen werden. Es sei angenommen, dass ein bestimmter Mandant einen API-Aufruf vornimmt, der diesen vier Umfängen entspricht, oder mit anderen Worten eine Dienstanforderung vornimmt. Dabei entspricht der Umfang DatasSetService bzw. Datensatzdienst einem API-Dienst, in dem das Anwendungsmodul 800 eine lokale CSV-Datei an das Ressourcenservermodul 700 hochlädt und das Ressourcenservermodul 700 die hochgeladene CSV-Datei aufbaut bzw. erstellt und die Datei in einen Datensatz wandelt. Der Umfang FormService bzw. Formulardienst entspricht einem API-Dienst, in dem das Anwendungsmodul 800 den Datensatz in dem Ressourcenservermodul 700 spezifiziert und ein Formular erzeugt. Der Umfang PrintService bzw. Druckdienst entspricht einem API-Dienst, in dem das Anwendungsmodul 800 die Formulardaten in dem Ressourcenservermodul 700 druckt. Weiterhin entspricht der Umfang DataSetFormPrintService bzw. Datensatz-/Formular-/Druckdienst einem API-Dienst, in dem das Anwendungsmodul 800 nacheinander die APIs des Umfangs DataSetService bzw. Datensatzdienst, des Umfangs FormService bzw. Formulardienst und des Umfangs PrintService bzw. Druckdienst aufruft, um so eine lokale CSV-Datei hochzuladen, ein Formular zu erzeugen und das Formular zu drucken. Der Umfang DataSetFormPrintService bzw. Datensatz-/Formular-/Druckdienst entspricht einer Umfangsgruppe gemäß dem vorliegenden Ausführungsbeispiel. Die Umfangsgruppe ordnet einer Kombination von mehreren Umfängen einen eindeutigen Namen zu, wenn eine Reihe von Ressourcen unter Verwendung eines mit den mehreren Umfänge in Zusammenhang bzw. Assoziation stehende Zugriffstokens erhalten (eine API aufgerufen) wird. Die Umfangsgruppe konfiguriert die Reihe von Ressourcenerlangungen (API-Aufrufen). Die in 9 angegebene Zugriffstokenanforderung wird in der Abgabesequenz als ein Zugriffstoken abgegeben, das mehrere Umfang-IDs umfasst, wenn das Zugriffstoken tatsächlich abgegeben wird. Die Umfangsgruppe ist in einer Umfangsgruppentabelle in dem Autorisierungsservermodul 600 definiert, die in 5G gezeigt ist, und sie ist auf der Clientseite, wie etwa an dem Anwendungsmodul 800, nicht bekannt. Da die API einen Dienst spezifiziert, der durch diese API bereitgestellt wird, entsprechen "API" und "Dienst" einander. Dementsprechend werden bei dem vorstehenden Ausführungsbeispiel die API und der durch die API bereitgestellte Dienst kollektiv als API-Dienst bezeichnet. Dementsprechend kann auch der API-Dienst als Dienst und die diesem entsprechende API bezeichnet werden.
  • Wenn das Anwendungsmodul 800 eine API aufruft, die mehrere Umfänge spezifiziert, die dem Datensatz-/Formular-/Druckdienst entsprechen, wird faktisch eine Zugriffstokenverifikation gemäß dem in 10 gezeigten Ablaufdiagramm für den Datensatzdienst-Umfang, den Formulardienst-Umfang und den Druckdienst-Umfang durchgeführt, und wird weiterhin die in 11 angegebene API-Zählung durchgeführt. Wenn einer der drei Umfänge die AP-Benutzungszahlgrenze erreicht, ist es dabei möglich, dass der durch Zusammenarbeit der Reihe von Diensten (was tatsächlich einer Spezifikation von mehreren Umfängen entspricht) konfigurierte Datensatz-/Formular-/Druckdienst-Umfang auf halbem Weg bzw. während des Ablaufs stoppen wird, ohne dass der API-Aufruf abgeschlossen wird. Indessen kann ein Aufruf einer mehrere Umfänge spezifizierenden API eine Reihe von Diensten bezeichnen, indem eine ID der Umfangsgruppe in den mehreren Umfängen, die in der Reihe von Diensten umfasst sind, bereitgestellt wird. Das Autorisierungsservermodul 600 kann zwischen einem API-Aufruf für einzelne Umfänge und einem Aufruf für eine Reihe von Diensten, die durch mehrere Umfänge bezeichnet sind, unterscheiden, indem es die API-Grenzzahlen für die Umfangsgruppe und einzelne Umfänge separat verwaltet. Dadurch kann verhindert werden, dass der mehrere Umfänge spezifizierende API-Aufruf, der durch eine Zusammenarbeit der Reihe von Diensten konfiguriert ist, auf halbem Weg bzw. während des Ablaufs stoppt, ohne dass der API-Aufruf abgeschlossen wird.
  • Es wird angenommen, dass die Umfänge, die eine Umfangsgruppe konfigurieren, in dem System voreingestellt sind. Einem Benutzer kann auch erlaubt sein, die Umfangsgruppe zu definieren. In dem Fall, dass mehrere Umfänge in einer Zugriffstokenanforderung spezifiziert sind und die mehreren spezifizierten Tokens mit den in der Umfangsgruppe definierten Umfängen exakt übereinstimmen, wird die Zugriffstokenanforderung für die mehreren Umfänge so interpretiert, dass sie die Umfangsgruppe spezifiziert. Mit Bezug auf die Erlangung von Ressourcen (API-Aufrufe) unter Verwendung eines Zugriffstokens, das in Erwiderung auf die mehrere Umfänge spezifizierende Zugriffstokenanforderung abgegeben wird, bestimmt das Autorisierungsservermodul 600, dass die Erlangung von Ressourcen (API-Aufruf) die Umfangsgruppe spezifiziert, und führt es eine Verarbeitung durch.
  • Das zweite Ausführungsbeispiel, das das vorgenannte Problem löst, wird unter Verwendung von 5F, 5G, 12 und 13 beschrieben. Es ist zu beachten, dass das zweite Ausführungsbeispiel mit Ausnahme der Verarbeitung von der Zugriffstokenerlangung in S1.11 bis zu der Fehlerantwortsequenz in S1.17, die in 8 gezeigt sind, gleich dem vorgenannten Ausführungsbeispiel ist, und somit Beschreibungen abgesehen von diesen Elementen ausgelassen werden. Außerdem sind die gleichen Sequenznummern Sequenzen beigefügt, die die gleichen Prozesse wie diejenigen ausführen, die unter Bezugnahme auf 8 beschrieben sind, und werden Beschreibungen von diesen ausgelassen.
  • Umfangsgruppe-API-Verwaltungstabelle
  • 5F veranschaulicht eine Umfangsgruppe-API-Verwaltungstabelle 1980. Die Umfangsgruppe-API-Verwaltungstabelle 1980 wird im Voraus durch das System, durch den Benutzer oder beide definiert. Die Umfangsgruppe-API-Verwaltungstabelle 1980 umfasst eine Mandant-ID 1981, eine Umfang-ID 1982, eine Gruppenausführungszahl 1983 und eine API-Benutzungszahl 1984. Die Mandant-ID 1981 ist so konfiguriert, dass sie mit der Mandant-ID 1703 der Benutzer-Verwaltungstabelle 1700 in Zuordnung gebracht werden kann. Die Umfang-ID 1982 gibt eine Umfangsgruppe-ID an. Die Gruppenausführungszahl 1983 gibt an, wie viele APIs in einer Reihe von APIs durch das Anwendungsmodul 800 basierend auf dem Zugriffstoken aufgerufen werden, das mit den mehreren Umfang-IDs in Zusammenhang bzw. Assoziation steht, die der durch die Umfang-ID 1982 bezeichneten Umfangsgruppe-ID entsprechen. Die Gruppenausführungszahl 1983 bezeichnet eine Grenzzahl pro Einheitszeit, die bezüglich der Häufigkeit gesetzt ist, mit der Ressourcen als die Umfangsgruppe angefordert werden. Es ist zu beachten, dass diese Zahl nur auf erfolgreiche Anforderungen beschränkt ist. Die API-Benutzungszahl 1984 zeichnet auf, wie oft die Reihe von API-Aufrufen vorgenommen wurde. Einzelheiten einer Verarbeitung mit Bezug auf die Umfangsgruppe-API-Verwaltungstabelle 1980 werden nachstehend gegeben.
  • Es ist zu beachten, dass die API-Benutzungsgrenzzahl 1954 für die Umfangsgruppe durch den Benutzer eingestellt wird, wie es in 7B angedeutet ist. Indessen gibt die Gruppenausführungszahl 1983 eine Anzahl von Ausführungen als eine Gruppe an, und somit kann ein Wert, der durch Dividieren der eingestellten API-Benutzungsgrenzzahl 1954 durch die Anzahl von Umfang-IDs, die in dieser Umfangsgruppe umfasst sind, (unter Verwerfung des Rests) erhalten wird, als die Gruppenausführungszahl 1983 eingestellt werden. Umgekehrt kann eine Ausführungszahl als eine Gruppe eingestellt werden, und kann dieser Wert dann in einzelne API-Benutzungszahlen gewandelt und als die API-Benutzungsgrenzzahl 1954 verwendet werden. In beiden Fällen ist es notwendig, dass die Summe der Werte der API-Benutzungszahlgrenze nicht größer ist als die Gesamtbenutzungszahlgrenze für die APIs in dem Mandanten.
  • Umfangsgruppentabelle
  • 5G veranschaulicht eine Datentabelle, die in einem externen Speicher des Datenbankservers 500 gespeichert ist, der so konfiguriert ist, dass er zur Kommunikation mit dem Autorisierungsserver 200 über das LAN 101 fähig ist, und zwar in der gleichen Art und Weise, wie es in 5A, 5B, 5C, 5D, 5E und 5F der Fall ist. Diese Datentabellen können auch in einem externen Speicher des Autorisierungsservers 200 konfiguriert sein.
  • 5G veranschaulicht eine Umfangsgruppentabelle 1990. Die Umfangsgruppentabelle 1990 ist aus einer Umfangsgruppe-ID 1991, einer Umfang-ID-Liste 1992 und einer Beschreibung 1993 aufgebaut. Die Umfangsgruppe-ID 1991 bezeichnet eine Umfangsgruppe-ID. Die Umfang-ID-Liste 1992 bezeichnet eine Liste der Umfänge, die die durch die Umfangsgruppe-ID bezeichnete Umfangsgruppe tatsächlich konfigurieren. Bei dem vorliegenden Ausführungsbeispiel ist eine Umfangsgruppe mit DataSetFormPrintService bzw. Datensatz-/Formular-/Druckservice als Umfangsgruppe-ID aus drei Umfängen konfiguriert, nämlich einem Umfang DataSetService bzw. Datensatzdienst, einem Unfang FormService bzw. Formulardienst und einem Umfang PrintService bzw. Druckdienst. Wenn das Anwendungsmodul 800 unter Verwendung eines Zugriffstokens, das mit den drei Umfängen in Zusammenhang bzw. Assoziation steht, die der Umfangsgruppe DataSetFormPrintService bzw. Datensatz-/Formular-/Druckservice entsprechen, eine Datenhochladedienst-API, eine Formulardienst-API und eine Druckdienst-API nacheinander in Aufeinanderfolge ausführt, bestimmt das Autorisierungsservermodul 600, dass die durch die Umfangsgruppe DataSetFormPrintService bzw. Datensatz-/Formular-/Druckservice bereitgestellten Funktionen einmal bereitgestellt wurden.
  • Zugriffstoken-Erlangungsprozess
  • 12 veranschaulicht, von der in 8 gezeigten Sequenz gemäß dem zweiten Ausführungsbeispiel, eine Sequenz, die sich von der Erlangung eines mehrere Umfänge spezifizierenden Zugriffstokens durch das Anwendungsmodul 800 bis zu einer Verwaltung der API-Grenzzahl der Umfangsgruppe und einer Erlangung von Ressourcen (einem Aufruf von APIs) unter Verwendung des Zugriffstokens durch das Autorisierungsservermodul 600 erstreckt.
  • In der in 8 gezeigten Sequenz fordert das Anwendungsmodul 800 ein Zugriffstoken an und erhält es das Zugriffstoken in S1.11. Wenn das Anwendungsmodul 800 bei Erlangung des Zugriffstokens mehrere Umfänge spezifiziert, kann ein Zugriffstoken, das mehreren Umfängen entspricht, basierend auf der in 8 gezeigten Sequenz erhalten werden. Dabei werden in dem Fall, dass die mehreren Umfänge exakt mit der Umfang-ID-Liste 1992 übereinstimmen, die im Voraus in der Umfangsgruppentabelle 1990 in dem Autorisierungsservermodul 600 definiert ist, die mehreren Umfänge als Umfangsgruppe in dem Autorisierungsservermodul 600 erkannt. Die Umfangsgruppe wird verwendet, wenn das Anwendungsmodul 800 mehrere Ressourcen erhält (APIs aufruft), die den jeweiligen mehreren Umfängen entsprechen, damit das Autorisierungsservermodul 600 die Reihe von erhaltenen Ressourcen (API-Aufrufen) kollektiv, anstatt einzeln, hoch zählt. Die Erlangung von Ressourcen (die API-Aufrufe) durch das Anwendungsmodul 800 wird in dem Autorisierungsservermodul 600 als Fälle, die mit einem einzelnen Umfang in Zusammenhang bzw. Assoziation stehen, und Fälle, die mit mehreren Umfängen in Zusammenhang bzw. Assoziation stehen, unterschieden.
  • Im Speziellen werden API-Aufrufe, die mit dem einzelnen Umfang in Zusammenhang bzw. Assoziation stehen, als der folgende erste, zweite und dritte API-Aufruf realisiert.
  • Erster API-Aufruf
  • Die Erlangung von Ressourcen unter Verwendung des Zugriffstokens, das mit dem Datensatzdienst-Umfang (einem Hochladedienst-API-Aufruf) in Zusammenhang steht, erfolgt wie folgt. Die mit dem Datensatzdienst-Umfang in Zusammenhang stehende Zugriffstoken-ID ist "AT_0000001" in der Zugriffstoken-ID 1901 der Zugriffstoken-Verwaltungstabelle 1900. Das Anwendungsmodul 800 führt den API-Aufruf durch, indem es """QVRfMDAwMDAwMQ==" nach ""Authorization: Bearer" des API-Aufrufs in Base64-KCodierung hinzufügt.
    POST /oauth2/v1/dataset/upload HTTP/1.1
    Authorization: Bearer QVRfMDAwMDAwMQ==
    Host: example.com
  • Zweiter API-Aufruf
  • Die Erlangung von Ressourcen unter Verwendung des Zugriffstokens, das mit dem Formulardienst-Umfang (einem Formulardienst-API-Aufruf) in Zusammenhang steht, erfolgt wie folgt. Die mit dem Formulardienst-Umfang in Zusammenhang stehende Zugriffstoken-ID ist "AT_0000002" in der Zugriffstoken-ID 1901 der Zugriffstoken-Verwaltungstabelle 1900. Das Anwendungsmodul 800 führt den API-Aufruf durch, indem es """QVRfMDAwMDAwMg==" nach ""Authorization: Bearer" des API-Aufrufs in Base64-Codierung hinzufügt.
    POST /oauth2/v1/form/create HTTP/1.1
    Authorization: Bearer QVRfMDAwMDAwMg==
    Host: example.com
  • Dritter API-Aufruf
  • Die Erlangung von Ressourcen unter Verwendung des Zugriffstokens, das mit dem Druckdienst-Umfang (einem Druckdienst-API-Aufruf) in Zusammenhang steht, erfolgt wie folgt. Die mit dem Druckdienst-Umfang in Zusammenhang stehende Zugriffstoken-ID ist " AT_0000003" in der Zugriffstoken-ID 1901 der Zugriffstoken-Verwaltungstabelle 1900. Das Anwendungsmodul 800 führt den API-Aufruf durch, indem es """QVRfMDAwMDAwMw==" nach ""Authorization: Bearer" des API-Aufrufs in Base64-Codierung hinzufügt.
    GET /oauth2/v1/print?printerid=xxxx&jobid=yyyy HTTP/1.1
    Authorization: Bearer QVRfMDAwMDAwMw==
    Host: example.com
  • In Erwiderung auf den ersten, den zweiten und den dritten API-Aufruf, die vorstehend aufgeführt sind, erfolgen API-Aufrufe, die mit mehreren Umfängen in Zusammenhang stehen, gemäß dem vorliegenden Ausführungsbeispiel wie folgt. Die Erlangung von Ressourcen (die API-Aufrufe) unter Verwendung des Zugriffstokens, das mit den drei Umfängen in Zusammenhang steht, nämlich dem Datensatzdienst, dem Formulardienst und dem Druckdienst, wird nämlich als der folgende vierte, fünfte und sechste API-Aufruf implementiert.
  • Vierter API-Aufruf
  • Die Erlangung von Ressourcen (Hochladedienst-API) unter Verwendung des Zugriffstokens, das mit einem Gruppenumfang in Zusammenhang steht, der die drei vorgenannten Umfänge aufweist, erfolgt wie folgt. Die mit dem Datensatz-/Formular-/Druckdienst-Umfang in Zusammenhang stehende Zugriffstoken-ID ist "AT_0000004" in der Zugriffstoken-ID 1901 der Zugriffstoken-Verwaltungstabelle 1900. Das Anwendungsmodul 800 führt den API-Aufruf durch, indem es """QVRfMDAwMDAwNA==" nach ""Authorization: Bearer" des API-Aufrufs in Base64-Codierung hinzufügt.
    POST /oauth2/v1/dataset/upload HTTP/1.1
    Authorization: Bearer QVRfMDAwMDAwNA==
    Host: example.com
  • Fünfter API-Aufruf
  • Die Erlangung von Ressourcen (Formulardienst-API) unter Verwendung des Zugriffstokens, das mit einem Gruppenumfang in Zusammenhang steht, der die drei vorgenannten Umfänge aufweist, erfolgt wie folgt. Die mit dem Datensatz-/Formular-/Druckdienst-Umfang in Zusammenhang stehende Zugriffstoken-ID ist "AT_0000004" in der Zugriffstoken-ID 1901 der Zugriffstoken-Verwaltungstabelle 1900. Das Anwendungsmodul 800 führt den API-Aufruf durch, indem es """QVRfMDAwMDAwNA==" nach ""Authorization: Bearer" des API-Aufrufs in Base64-Codierung hinzufügt.
    POST /oauth2/v1/form/create HTTP/1.1
    Authorization: Bearer QVRfMDAwMDAwNA==
    Host: example.com
  • Sechster API-Aufruf
  • Die Erlangung von Ressourcen (Druckdienst-API) unter Verwendung des Zugriffstokens, das mit einem Gruppenumfang in Zusammenhang steht, der die drei vorgenannten Umfänge aufweist, erfolgt wie folgt. Die mit dem Datensatz-/Formular-/Druckdienst-Umfang in Zusammenhang stehende Zugriffstoken-ID ist "AT_0000004" in der Zugriffstoken-ID 1901 der Zugriffstoken-Verwaltungstabelle 1900. Das Anwendungsmodul 800 führt den API-Aufruf durch, indem es """QVRfMDAwMDAwNA==" nach ""Authorization: Bearer" des API-Aufrufs in Base64-Codierung hinzufügt.
    GET /oauth2/v1/print?printerid=xxxx&jobid=yyyy HTTP/1.1
    Authorization: Bearer QVRfMDAwMDAwNA==
    Host: example.com
  • Gemäß 12 führt das Anwendungsmodul 800 den besagten vierten, fünften und sechsten API-Aufruf durch. Diese entsprechen der oberen Ebene, der mittleren Ebene und der unteren Ebene in 12. Mit anderen Worten wird der vierte API-Aufruf von Schritt S8.11 bis S8.17 durchgeführt, wird der fünfte API-Aufruf von Schritt S9.11 bis S9.17 durchgeführt, und wird der sechste API-Aufruf von Schritt S10.11 bis S10.17 durchgeführt. Abgesehen von dem API-Zählprozess in dem Zugriffstoken-Verifikationsprozess, der in dem Ablaufdiagramm gemäß 10 gezeigt ist, sind diese API-Aufrufsequenzen gleich derjenigen von S1.11 bis S1.17 gemäß 8, und werden Beschreibungen von diesen daher ausgelassen. Auf diese Art und Weise können Dienste gemäß individuellen Umfängen, die in einem einzelnen Gruppenumfang umfasst sind, durch Verwendung eines Zugriffstokens empfangen werden, das mit dem Gruppenumfang in Zusammenhang steht.
  • Der in 12 gezeigte API-Zählprozess, der in dem Zugriffstoken-Verifikationsprozess durchgeführt wird, der in dem Ablaufdiagramm gemäß 10 gezeigt ist, wird unter Verwendung des in 13 gezeigten Ablaufdiagramms ausführlich beschrieben. 13 veranschaulicht einen Prozess, der bei dem vorliegenden Ausführungsbeispiel anstelle von 11 ausgeführt wird, die bei dem ersten Ausführungsbeispiel beschrieben ist.
  • In Schritt S7.1 erhält das Autorisierungsservermodul 600 eine Mandant-ID, die mit dem zu verifizierenden Zugriffstoken in Zusammenhang steht. Im Speziellen wird die Client-ID 1905 des Zugriffstokens erhalten, das der Zugriffstoken-ID 1901 in der Zugriffstoken-Verwaltungstabelle 1900 entspricht. Außerdem wird basierend auf der Client-ID 1301 auf eine Zeile in der gemäß 4B gezeigten Client-Verwaltungstabelle 1300 Bezug genommen, die der Client-ID entspricht, und wird der Wert der entsprechenden Mandant-ID 1303 erhalten. Als nächstes nimmt das Autorisierungsservermodul 600 in Schritt S7.2 auf die Zugriffstoken-Verwaltungstabelle 1900 Bezug, und nimmt es auf die Umfang-ID 1904 in einer Zeile Bezug, die mit der aktuellen Zugriffstoken-ID 1901, die zu verifizieren ist, übereinstimmt. Als Nächstes wird in Schritt S7.3 bestimmt, ob die Umfang-ID 1904, auf die in Schritt S7.2 Bezug genommen wird, eine einzelne Umfang-ID oder mehrere Umfang-IDs darstellt. Wenn die Umfang-ID mehrere Umfang-IDs bezeichnet, nimmt das Autorisierungsservermodul 600 hier in Schritt S7.4 auf eine Umfang-ID-Liste 1992 in der Umfangsgruppentabelle 1990 Bezug, und bestimmt es, ob die mehreren Umfang-IDs eine exakte Übereinstimmung mit der Umfang-ID-Liste 1992 darstellen oder nicht. Wenn jedoch die Umfang-ID in Schritt S7.3 nicht mehrere IDs bezeichnet, schreitet der Prozess zu Schritt S7.7 voran. Wenn in Schritt S7.4 die mehreren Umfang-IDs nicht exakt mit der Umfang-ID-Liste 1992 übereinstimmen, schreitet der Prozess weiterhin zu Schritt S7.7 voran. Wenn in Schritt S7.4 die verifizierten mehreren Umfang-IDs exakt mit der Umfang-ID-Liste 1992 übereinstimmen, bestimmt das Autorisierungsservermodul 600, dass die mehreren Umfang-IDs einer Umfangsgruppe-ID entsprechen, die mit der Umfang-ID-Liste 1992 in der Umfangsgruppentabelle 1990 übereinstimmt.
  • In dem Fall, dass die Umfangsgruppe bestimmt wird, werden in Schritt S7.5 die Mandant-ID 1981, die mit der in Schritt S7.1 erhaltenen Mandant-ID übereinstimmt, und die Umfang-ID 1982, die mit der Umfangsgruppe-ID übereinstimmt, aus der Umfangsgruppe-API-Verwaltungstabelle 1980 herausgesucht, und wird die API-Benutzungszahl 1984 in dergleichen Zeile um 1 inkrementiert. Hier bestimmt das Autorisierungsservermodul 600 in Schritt S7.6, ob der Wert der API-Benutzungszahl 1984 in der Umfangsgruppr-API-Verwaltungstabelle 1980 den Wert der Gruppenausführungszahl 1983 überschreitet oder nicht. Wenn der Wert der API-Benutzungszahl 1984 den Wert der Gruppenausführungszahl 1983 überschreitet, stellt das Autorisierungsservermodul 600 den Wert der API-Benutzungszahl 1984 auf 0 zurück, und schreitet es dann zu Schritt S7.7 voran. Wenn jedoch der Wert der API-Benutzungszahl 1984 den Wert der Gruppenausführungszahl 1983 nicht überschreitet, gibt das Autorisierungsservermodul 600 in S7.9 "Erfolg" zurück, woraufhin der Prozess endet. In Schritt S7.7 bestätigt das Autorisierungsservermodul 600 den Wert der API-Benutzungsgrenzzahl 1954 in der Zeile der API-Benutzungszahl-Verwaltungstabelle 1950, auf die vorher Bezug genommen wurde, und vergleicht es die API-Benutzungszahl 1955 mit der API-Benutzungsgrenzzahl 1954. Wenn die API-Benutzungszahl 1955 die API-Benutzungsgrenzzahl 1954 in Schritt S7.8 nicht überschritten hat, wird bestimmt, dass die API-Benutzung innerhalb der API-Benutzungszahlgrenze liegt, wird in Schritt S7.9 "Erfolg" zurückgegeben, und endet der Prozess. Wenn jedoch die API-Benutzungszahl 1955 in Schritt S7.8 die API-Benutzungsgrenzzahl 1954 überschritten hat, wird bestimmt, dass die API-Benutzung die API-Benutzungsgrenzzahl überschritten hat, wird in Schritt S7.10 "Fehler" zurückgegeben, und endet der Prozess.
  • Vorstehend wurde eine API-Benutzungszahlgrenze-Verwaltung mittels Umfang und Umfangsgruppe gemäß dem zweiten Ausführungsbeispiel beschrieben. Durch diese Verarbeitung kann das Autorisierungsservermodul 600 von einem Client eine Anforderung für einen Umfang empfangen, der verwendet wird, wenn der Client registriert wird, und einen Registrierungsfehler zu diesem Zeitpunkt zurückgeben, wenn eine unzureichende Autorisierung bzw. Berechtigung vorliegt. Dies macht es möglich, eine verschwenderische bzw. überflüssige Clientregistrierung zu vermeiden.
  • Weitere Ausführungsbeispiele
  • Ein oder mehrere Ausführungsbeispiele der vorliegenden Erfindung können auch realisiert werden durch einen Computer eines Systems oder einer Vorrichtung, der computerausführbare Anweisungen (z.B. ein oder mehrere Programme), die auf einem Speichermedium (das vollständiger auch als ein "nichtvorübergehendes computerlesbares Speichermedium" bezeichnet werden kann) aufgezeichnet sind, ausliest und ausführt, um die Funktionen von einem oder mehreren der vorgenannten Ausführungsbeispiele durchzuführen, und/oder ein oder mehrere Schaltungen (z.B. eine anwendungsspezifische integrierte Schaltung (ASIC)) zum Durchführen der Funktionen von einem oder mehreren der vorgenannten Ausführungsbeispiele umfasst, sowie durch ein Verfahren, das durch den Computer des Systems oder der Vorrichtung durchgeführt wird, indem zum Beispiel die computerausführbaren Anweisungen von dem Speichermedium ausgelesen und ausgeführt werden, um die Funktionen von einem oder mehreren der vorgenannten Ausführungsbeispiele durchzuführen, und/oder die ein oder mehreren Schaltungen gesteuert werden, um die Funktionen von einem oder mehreren der vorgenannten Ausführungsbeispiele durchzuführen. Der Computer kann einen oder mehrere Prozessoren (z.B. Zentralverarbeitungseinheit (CPU), Mikroverarbeitungseinheit (MPU)) aufweisen und ein Netzwerk separater Computer oder separater Prozessoren umfasst, um die computerausführbaren Anweisungen auszulesen und auszuführen. Die computerausführbaren Anweisungen können an den Computer zum Beispiel von einem Netzwerk oder dem Speichermedium bereitgestellt werden. Das Speichermedium kann zum Beispiel eines oder mehreres einer Festplatte, eines Direktzugriffsspeichers (RAM) eines Festwertspeichers (ROM), eines Speichers verteilter Rechensysteme, einer optischen Platte (wie etwa einer Compact Disc (CD), einer Digital Versatile Disc (DVD), oder einer Blu-ray Disc (BD)TM), einer Flashspeichervorrichtung, einer Speicherkarte und dergleichen umfassen.
  • Während die vorliegende Erfindung unter Bezugnahme auf beispielhafte Ausführungsbeispiele beschrieben wurde, ist es selbstverständlich, dass die Erfindung nicht auf die offenbarten beispielhaften Ausführungsbeispiele beschränkt ist. Dem Umfang der folgenden Patentansprüche ist die breiteste Auslegung zuzugestehen, um alle derartigen Modifikationen und äquivalente Strukturen und Funktionen zu umfassen.
  • Es wird ein API-Zählprozess ausgeführt, der eine Grenzzahl für eine durch einen Client benutzte API einstellt und, wenn ein Zugriffstoken in Erwiderung auf eine Anforderung von einem Autorisierungsübertragungsziel abgegeben wird und eine Anforderung zum Verifizieren des abgegebenen Zugriffstokens empfangen wird, eine API-Benutzungsgrenzzahl pro Client gemäß der Benutzungsgrenzzahl für jede API verwaltet, die für das Autorisierungsübertragungsziel eingestellt ist. Die API-Benutzungszahl wird inkrementiert (S5.2), mit der Benutzungsgrenzzahl verglichen (S5.3), und die Zugriffstokenverifikation wird in dem Fall, dass die Grenze überschritten wurde, als fehlgeschlagen betrachtet.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • JP 2007-328417 [0007]
  • Zitierte Nicht-Patentliteratur
    • "The Oauth 2.0 Authorization Framwork", (online), D. Hardt, Mai 2013, abgerufen von http://tools.ietf.org/html/rfc6749 [0003]

Claims (13)

  1. Autorisierungsverwaltungsserver mit: einer Verwaltungseinrichtung zum Verwalten einer Zugriffsautorisierung eines Benutzers für eine Ressource; einer Abgabeeinrichtung zum, in Erwiderung auf eine Autorisierungsanforderung von einem Client, die eine Übertragung der Zugriffsautorisierung des Benutzers für eine Ressource anfordert, Verifizieren der Autorisierungsanforderung und Abgeben eines Zugriffstokens an den Client in dem Fall, dass die Verifikation erfolgreich ist; und einer Verifikationseinrichtung zum Verifizieren des Zugriffstokens und Zurückgeben einer Verifikationsantwort in dem Fall, dass die Verifikation erfolgreich ist, falls eine Ressourcenanforderung zusammen mit dem Zugriffstoken vorliegt, wobei sowohl die durch die Abgabeeinrichtung durchgeführte Autorisierungsanforderungsverifikation als auch die durch die Verifikationseinrichtung durchgeführte Zugriffstokenverifikation bestimmen, ob eine Anzahl von Zugriffen auf die Ressource eine eingestellte Zugriffsgrenzzahl überschritten hat oder nicht, und in dem Fall, dass die Zugriffsgrenzzahl nicht überschritten ist, das Zugriffstoken als gültig bestimmen.
  2. Autorisierungsverwaltungsserver gemäß Anspruch 1, wobei bestimmt wird, ob die Anzahl von Zugriffen auf die Ressource die Zugriffsgrenzzahl überschreitet oder nicht, indem die Anzahl von Zugriffen auf jede Ressource mit einer Zugriffsgrenzzahl, die für jede Ressource eingestellt ist, verglichen wird.
  3. Autorisierungsverwaltungsserver gemäß Anspruch 1 oder 2, wobei die Zugriffsgrenzzahl eine Zugriffsgrenzzahl für jeden Mandanten, dem die Ressource bereitzustellen ist, und für jede Einheitsperiode ist.
  4. Autorisierungsverwaltungsserver gemäß einem der Ansprüche 1 bis 3, zusätzlich mit: einer Einstelleinrichtung zum Anzeigen eines Eingabebildschirms zum Eingeben der Zugriffsgrenzzahl an einem Endgerät und Einstellen eines über den Eingabebildschirm eingegeben Werts als die Zugriffsgrenzzahl.
  5. Autorisierungsverwaltungsserver gemäß Anspruch 4, wobei ein Eingabefeld zum Eingeben der Zugriffsgrenzzahl pro Ressource auf dem Eingabebildschirm umfasst ist und die auf dem Eingabebildschirm eingegebenen Werte pro Ressource als die Zugriffsgrenzzahlen pro Ressource eingestellt werden.
  6. Autorisierungsverwaltungsserver gemäß einem der Ansprüche 1 bis 3, wobei eine durch eine Vielzahl von Ressourcen konfigurierte Gruppe sowohl in der Autorisierungsanforderung als auch in dem Zugriffstoken umfasst sein kann; und wobei bestimmt wird, ob die Anzahl von Zugriffen auf die Ressource die Zugriffsgrenzzahl überschreitet, indem die Anzahl von Zugriffen auf jede Ressource auf der Gruppenebene mit einer Zugriffsgrenzzahl, die für jede Gruppe eingestellt ist, verglichen wird.
  7. Autorisierungsverwaltungsserver gemäß Anspruch 6, zusätzlich mit: einer Einstelleinrichtung zum Anzeigen eines Eingabebildschirms zum Eingeben der Zugriffsgrenzzahl an einem Endgerät und Einstellen eines über den Eingabebildschirm eingegebenen Werts als die Zugriffsgrenzzahl, wobei ein Eingabefeld zum Eingeben der Zugriffsgrenzzahl pro Gruppe auf dem Eingabebildschirm umfasst ist und die auf dem Aufgabebildschirm eingegebenen Werte pro Gruppe als die Zugriffsgrenzzahlen eingestellt werden.
  8. Autorisierungsverwaltungsserver mit: einer Verwaltungseinrichtung zum Verwalten einer Zugriffsautorisierung eines Benutzers für eine Ressource; einer Abgabeeinrichtung zum, in Erwiderung auf eine Autorisierungsanforderung von einem Client, die eine Übertragung der Zugriffsautorisierung des Benutzers für eine Ressource anfordert, Abgeben eines Zugriffstokens an den Client; und einer Verifikationseinrichtung zum Verifizieren des Zugriffstokens und Zurückgeben einer Verifikationsantwort in dem Fall, dass die Verifikation erfolgreich ist, falls eine Ressourcenanforderung zusammen mit dem Zugriffstoken vorliegt, wobei die durch die Verifikationseinrichtung durchgeführte Zugriffstokenverifikation bestimmt, ob eine Anzahl von Zugriffen auf die angeforderte Ressource eine eingestellte Zugriffsgrenzzahl überschritten hat oder nicht, und in dem Fall, dass die Zugriffsgrenzzahl nicht überschritten ist, das Zugriffstoken als gültig bestimmt.
  9. Autorisierungsverwaltungsserver gemäß einem der Ansprüche 1 bis 8, wobei in dem Fall, dass die Zugriffstokenverifikation dazu geführt hat, dass das Zugriffstoken als authentisch verifiziert wird, auf die Ressource zugegriffen werden darf, ohne dass gefordert wird, dass Berechtigungsnachweise eingegeben werden.
  10. Ressourcenbereitstellungssystem mit: dem Autorisierungsverwaltungsserver gemäß einem der Ansprüche 1 bis 9; einem Endgerät, das mit dem Autorisierungsverwaltungsserver verbunden ist; und einem Ressourcenserver, der in dem Fall, dass eine Ressourcenanforderung von dem Endgerät zusammen mit dem Zugriffstoken empfangen wurde, den Autorisierungsverwaltungsserver auffordert, das Zugriffstoken zu verifizieren, und in dem Fall, dass eine das Zugriffstoken akzeptierende Antwort von dem Autorisierungsverwaltungsserver empfangen wurde, die durch das Endgerät angeforderte Ressource bereitstellt.
  11. Programm zum Veranlassen eines Computers zum Arbeiten als der Autorisierungsverwaltungsserver gemäß einem der Ansprüche 1 bis 9.
  12. Autorisierungsverwaltungsverfahren mit: einem Verwaltungsschritt des Verwaltens einer Zugriffsautorisierung eines Benutzers für eine Ressource; einem Abgabeschritt des Verifizierens, in Erwiderung auf eine Autorisierungsanforderung von einem Client, die eine Übertragung der Zugriffsautorisierung des Benutzers für eine Ressource anfordert, der Autorisierungsanforderung und des Abgebens eines Zugriffstokens an den Client in dem Fall, dass die Verifikation erfolgreich ist; und einem Verifikationsschritt des Verifizierens des Zugriffstokens und des Zurückgebens einer Verifikationsantwort in dem Fall, dass die Verifikation erfolgreich ist, falls eine Ressourcenanforderung zusammen mit dem Zugriffstoken vorliegt, wobei sowohl die in dem Abgabeschritt durchgeführte Autorisierungsanforderungsverifikation als auch die in dem Verifikationsschritt durchgeführte Zugriffstokenverifikation bestimmen, ob eine Anzahl von Zugriffen auf die Ressource eine eingestellte Zugriffsgrenzzahl überschritten hat oder nicht, und in dem Fall, dass die Zugriffsgrenzzahl nicht überschritten ist, das Zugriffstoken als gültig bestimmen.
  13. Autorisierungsverwaltungsverfahren mit: einem Verwaltungsschritt des Verwaltens einer Zugriffsautorisierung eines Benutzers für eine Ressource; einem Abgabeschritt des Abgebens, in Erwiderung auf eine Autorisierungsanforderung von einem Client, die eine Übertragung der Zugriffsautorisierung des Benutzers für eine Ressource anfordert, eines Zugriffstokens an den Client; und einem Verifikationsschritt des Verifizierens des Zugriffstokens und des Zurückgebens einer Verifikationsantwort, in dem Fall, dass die Verifikation erfolgreich ist, falls eine Ressourcenanforderung zusammen mit dem Zugriffstoken vorliegt, wobei die in dem Verifikationsschritt durchgeführte Zugriffstokenverifikation bestimmt, ob eine Anzahl von Zugriffen auf die angeforderte Ressource eine eingestellte Zugriffsgrenzzahl überschritten hat oder nicht, und in dem Fall, dass die Zugriffsgrenzzahl nicht überschritten ist, das Zugriffstoken als gültig bestimmt.
DE102014119363.6A 2013-12-25 2014-12-22 Autorisierungsverwaltungsserver und autorisierungsverwaltungsverfahren Pending DE102014119363A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2013-268093 2013-12-25
JP2013268093A JP6265733B2 (ja) 2013-12-25 2013-12-25 権限管理サーバー及び権限管理方法

Publications (1)

Publication Number Publication Date
DE102014119363A1 true DE102014119363A1 (de) 2015-06-25

Family

ID=53275544

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102014119363.6A Pending DE102014119363A1 (de) 2013-12-25 2014-12-22 Autorisierungsverwaltungsserver und autorisierungsverwaltungsverfahren

Country Status (3)

Country Link
US (1) US9608990B2 (de)
JP (1) JP6265733B2 (de)
DE (1) DE102014119363A1 (de)

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016085641A (ja) * 2014-10-27 2016-05-19 キヤノン株式会社 権限移譲システム、権限移譲システムにて実行される方法、およびそのプログラム
JP6545000B2 (ja) * 2015-06-01 2019-07-17 キヤノン株式会社 アップロード管理システム、アップロード管理システムの制御方法、及びプログラム
US10243924B2 (en) 2015-08-18 2019-03-26 Ricoh Company, Ltd. Service providing system, service providing method, and information processing apparatus
JP6682254B2 (ja) * 2015-12-08 2020-04-15 キヤノン株式会社 認証連携システム及び認証連携方法、認可サーバー及びプログラム
US10320844B2 (en) * 2016-01-13 2019-06-11 Microsoft Technology Licensing, Llc Restricting access to public cloud SaaS applications to a single organization
US10306016B2 (en) 2016-02-01 2019-05-28 General Electric Company System and method for scoped attributes
US20180211056A1 (en) * 2016-04-15 2018-07-26 Authscope, Inc. Systems and methods for scope-based access
US11128734B2 (en) * 2016-05-10 2021-09-21 Veniam, Inc. Configuring a communication system using analytics of a restful API in a network of moving things
US10382461B1 (en) * 2016-05-26 2019-08-13 Amazon Technologies, Inc. System for determining anomalies associated with a request
GB2551543A (en) * 2016-06-21 2017-12-27 Eckoh Uk Ltd Methods of authenticating a user for data exchange
US10554418B2 (en) * 2016-06-24 2020-02-04 General Electric Company Routing cloud messages using digital certificates
JP6729145B2 (ja) 2016-08-03 2020-07-22 富士通株式会社 接続管理装置、接続管理方法および接続管理プログラム
US10445151B1 (en) 2016-09-14 2019-10-15 Google Llc Distributed API accounting
JP6806543B2 (ja) * 2016-11-25 2021-01-06 キヤノン株式会社 権限検証システムおよびリソースサーバー、認証サーバー、権限検証方法
JP6957194B2 (ja) * 2016-12-13 2021-11-02 キヤノン株式会社 サービスシステム、その制御方法、およびそのプログラム
US10462124B2 (en) 2016-12-30 2019-10-29 Google Llc Authenticated session management across multiple electronic devices using a virtual session manager
US10541992B2 (en) * 2016-12-30 2020-01-21 Google Llc Two-token based authenticated session management
JP6926627B2 (ja) * 2017-04-21 2021-08-25 富士通株式会社 情報処理システム、情報処理装置、ａｐｉ制御方法及びプログラム
US10924505B2 (en) * 2017-08-24 2021-02-16 Red Hat, Inc. Passcode based access-control with randomized limits
CN111164595A (zh) * 2017-10-03 2020-05-15 凡诺尼斯系统有限公司 在企业计算机环境中用于防止超额用户认证令牌使用状况的系统及方法
JP6748667B2 (ja) * 2018-03-20 2020-09-02 楽天銀行株式会社 Ａｐｉ提供システム、認証サーバ、ａｐｉ提供方法、及びプログラム
US11316693B2 (en) * 2018-04-13 2022-04-26 Microsoft Technology Licensing, Llc Trusted platform module-based prepaid access token for commercial IoT online services
US11122035B2 (en) 2018-05-24 2021-09-14 International Business Machines Corporation Secure delegation of a refresh token for long-running operations
US10764276B2 (en) 2018-08-31 2020-09-01 Sap Se Certificate-initiated access to services
CN109766084B (zh) * 2018-12-28 2021-04-23 百富计算机技术（深圳）有限公司 支付应用的定制开发方法、装置、计算机设备和存储介质
US11640456B1 (en) 2019-04-26 2023-05-02 Workday, Inc. System and method for authenticating a user at a user application using an credential access application and automatically redirecting to a target application
CN111953635B (zh) * 2019-05-15 2022-09-06 福建天晴数码有限公司 接口请求处理方法及计算机可读存储介质
CN110322940B (zh) * 2019-07-15 2023-06-27 山东浪潮智慧医疗科技有限公司 一种医疗数据共享的访问授权方法及系统
CN110555317B (zh) * 2019-09-09 2023-04-07 浪潮通用软件有限公司 一种应用文件更改处理方法、装置及系统
US11468525B2 (en) 2020-06-16 2022-10-11 Bank Of America Corporation Coordination platform for generating and managing authority tokens
CN113378217A (zh) * 2021-06-02 2021-09-10 浪潮软件股份有限公司 数据权限控制模块、数据访问系统及数据访问方法
CN113726675A (zh) * 2021-08-27 2021-11-30 上海东普信息科技有限公司 流量管理方法、装置、设备和存储介质
CN115801476B (zh) * 2023-02-09 2023-05-05 中国证券登记结算有限责任公司 一种应用请求的验证方法和装置
CN116436671B (zh) * 2023-04-14 2023-11-17 北京志凌海纳科技有限公司 私有网络内的Kubernetes集群接入的方法、系统、设备和介质
CN116992476B (zh) * 2023-09-26 2024-01-16 深圳竹云科技股份有限公司 应用权限的控制方法、装置、设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007328417A (ja) 2006-06-06 2007-12-20 Nec Biglobe Ltd リクエスト制限装置、サーバ装置、リクエスト制限方法、リクエスト制限プログラム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002342518A (ja) * 2001-02-02 2002-11-29 Matsushita Electric Ind Co Ltd コンテンツ利用管理システム及びコンテンツ利用管理方法
JP4294266B2 (ja) * 2001-06-11 2009-07-08 パナソニック株式会社 ライセンス管理サーバ、ライセンス管理システム及び利用制限制御方法
EP1430373A2 (de) * 2001-06-11 2004-06-23 Matsushita Electric Industrial Co., Ltd. Lizenzverwaltungsserver, lizenzverwaltungssystem, und verfahren zur benutzungseinschränkung
EP1788773A1 (de) * 2005-11-18 2007-05-23 Alcatel Lucent Verfahren und Vorrichtungen zur Anforderung eines Medienpostens und zur Voraberstellung eines Tokens
JP2011198064A (ja) * 2010-03-19 2011-10-06 Fuji Xerox Co Ltd プログラム、情報処理装置、および情報処理システム
JP5129313B2 (ja) * 2010-10-29 2013-01-30 株式会社東芝 アクセス認可装置
JP5529105B2 (ja) * 2011-11-24 2014-06-25 日本電信電話株式会社 アクセスチケット発行システム及びアクセスチケット発行方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007328417A (ja) 2006-06-06 2007-12-20 Nec Biglobe Ltd リクエスト制限装置、サーバ装置、リクエスト制限方法、リクエスト制限プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"The Oauth 2.0 Authorization Framwork", (online), D. Hardt, Mai 2013, abgerufen von http://tools.ietf.org/html/rfc6749

Also Published As

Publication number Publication date
JP6265733B2 (ja) 2018-01-24
US20150180863A1 (en) 2015-06-25
JP2015125510A (ja) 2015-07-06
US9608990B2 (en) 2017-03-28

Similar Documents

Publication Publication Date Title
DE102014119363A1 (de) Autorisierungsverwaltungsserver und autorisierungsverwaltungsverfahren
DE102014222852A1 (de) Autorisierungsserversystem, Steuerverfahren dafür und Speichermedium
EP2250598B1 (de) Client/server-system zur kommunikation gemäss dem standardprotokoll opc ua und mit single sign-on mechanismen zur authentifizierung sowie verfahren zur durchführung von single sign-on in einem solchen system
US20150180877A1 (en) Cloud Based Billing, Credential, And Data Sharing Management System
DE112012002741T5 (de) Identitäts- und Berechtigungsprüfungsverfahren für die Sicherheit einer Cloud-Datenverarbeitungsplattform
DE102011089580B3 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
DE102007012749A1 (de) Verfahren und System zur Bereitstellung von Diensten für Endgeräte
DE112011101729T5 (de) Verwaltung von Ressourcenzugriff
DE102014206325A1 (de) Verteiltes Authentifizierungssystem
DE112016002392T5 (de) Autorisierung in einem verteilten System unter Verwendung von Zugriffssteuerungslisten und Gruppen
EP3254432B1 (de) Verfahren zur berechtigungsverwaltung in einer anordnung mit mehreren rechensystemen
DE102014106310A1 (de) Vertrauensniveauberechnung mit attributspezifischen Funktionen
EP3117359B1 (de) Id-provider-computersystem, id-token und verfahren zur bestätigung einer digitalen identität
DE112021005026T5 (de) Persistente quellwerte für angenommene alternative identitäten
DE112022000340T5 (de) Attributgestützte verschlüsselungsschlüssel als schlüsselmaterial zum authentifizieren und berechtigen von benutzern mit schlüssel-hash-nachrichtenauthentifizierungscode
EP3117360B1 (de) Id-provider-computersystem
DE102009037436B4 (de) Verfahren und System zum Zugreifen von einer Vorrichtung auf zumindest einen Rechner eines Rechnerverbundes
EP2723111B1 (de) Mehrfaktor-Authentifikation für mobile Endgeräte
DE102013202339A1 (de) Vorrichtung und Verfahren zum Verwalten von Zugangscodes
EP1845689B1 (de) Verfahren und kommunikationssystem zum bereitstellen eines personalisierbaren zugangs zu einer gruppe von einrichtungen
EP2068530B1 (de) Verfahren und Kommunikationssystem zum Steuern des Zugangs zu Medieninhalten in Abhängigkeit des Alters eines Nutzers
DE102014210058A1 (de) Informationsverarbeitungsserversystem, Steuerverfahren und Programm
WO2021001334A1 (de) System und verfahren zur authentifizierung an einem gerät
EP3967009A1 (de) Verfahren zur authentisierung eines endnutzers gegenüber einem abhängigen dienst
DE112021006481T5 (de) Realm-auswahl für föderierte berechtigungsprüfungen auf grundlage eines zweitfaktors

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication