DE102022109139A1

DE102022109139A1 - Cloud-gesteuertes rollenmanagement für wlan

Info

Publication number: DE102022109139A1
Application number: DE102022109139.2A
Authority: DE
Inventors: Feng Ding; Hao Lu; Mohan Ram R. Bhadravati
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2021-10-26
Filing date: 2022-04-13
Publication date: 2023-04-27
Also published as: CN116032516A; US20230129117A1

Abstract

Beispiele beziehen sich auf die Konfiguration dynamischer Benutzerrollen, die von einem cloudbasierten Benutzerrollendienst verwaltet und verteilt werden können. Auf diese Weise können dynamische Benutzerrollen auf eine besser skalierbare Weise verteilt werden, als dies bisher möglich war. Bei der Assoziierung oder Verbindung mit einem Zugangspunkt (AP) kann ein Benutzergerät beispielsweise authentifiziert und einer Benutzerrolle zugewiesen werden. Der AP kann die Konfiguration der Benutzerrolle vom cloudbasierten Benutzerrollendienst anfordern. Der Cloud-basierte Benutzerrollendienst kann zusätzlich dieselbe Benutzerrollenkonfiguration/-details an alle benachbarten APs verteilen. Auf diese Weise kann ein Benutzergerät umziehen, roamen oder sich anderweitig mit einem anderen AP verbinden, der nach der Verteilung bereits über die (dynamische) Benutzerrollenkonfiguration verfügt, die dann einfach auf das Benutzergerät angewendet werden kann.

Description

Hintergrund
Drahtlose Netzwerke können es drahtlosen Geräten wie bestimmten Smartphones, Laptops, Tablets oder anderen geeigneten Computergeräten ermöglichen, Daten mit anderen verkabelten oder drahtlosen Geräten auszutauschen. In einigen drahtlosen Netzwerken kann ein drahtloses Gerät über einen oder mehrere Zugangspunkte auf einen verkabelten Teil des Netzwerks zugreifen. Solche Zugangspunkte können so ausgelegt sein, dass sie mit drahtlosen Geräten auf einer oder mehreren Funkfrequenzen kommunizieren, je nach den Fähigkeiten der Netzwerkausrüstung oder anderen Faktoren.
Figurenliste
Die vorliegende Offenbarung wird in Übereinstimmung mit einem oder mehreren verschiedenen Beispielen unter Bezugnahme auf die folgenden Figuren im Detail beschrieben. Die Figuren dienen lediglich der Veranschaulichung und stellen lediglich typische oder beispielhafte Beispiele dar.

1 zeigt ein Beispielnetz, in dem Beispiele der hier offengelegten Technologie angewendet werden können.
2 zeigt ein Beispiel für die Konfiguration einer Benutzerrolle.
3 zeigt eine Beispielimplementierung eines Cloud-basierten Rollendienstes in Übereinstimmung mit einigen Beispielen.
4A ist ein Blockdiagramm von Beispiel-Computerkomponenten oder -Geräten für die Cloud-gesteuerte Benutzerrollenverwaltung gemäß einigen Beispielen.
4B ist ein Blockdiagramm von Beispiel-Computerkomponenten oder -Geräten für die Cloud-gesteuerte Benutzerrollenverwaltung gemäß einigen Beispielen.
5 ist ein Beispiel für eine Computerkomponente, die zur Implementierung verschiedener Merkmale der in der vorliegenden Offenbarung beschriebenen Beispiele verwendet werden kann.

Die Figuren sind nicht erschöpfend und beschränken die vorliegende Offenbarung nicht auf die genaue Form, die offengelegt wird.
Detaillierte Beschreibung
Eine Benutzerrolle kann sich auf einen Richtliniencontainer oder eine Regel/einen Satz von Regeln beziehen, die auf einem Netzgerät verwaltet werden können. Eine Benutzerrolle kann verwendet werden, um Verkehrsrichtlinien auf den Benutzerverkehr bzw. die Kommunikation anzuwenden, der/die ein oder mehrere Netzgeräte durchläuft. Angesichts der exponentiellen Zunahme von Benutzergeräten und Netzwerkkonnektivität können herkömmliche Konfigurationsmodelle für Benutzerrollen nicht skaliert werden, um diese Zunahme an Benutzergeräten zu bewältigen.
Herkömmliche Benutzerrollenkonfigurationsmodelle, wie das „statische“ Benutzerrollenkonfigurationsmodell, können für eine begrenzte Anzahl von Benutzerrollen geeignet sein, die in einem Netz festgelegt werden, z. B. bis zu 32 Benutzerrollenkonfigurationen. Das statische Benutzerrollenkonfigurationsmodell ist jedoch nicht in der Lage, mehr Benutzerrollenkonfigurationen zu verwalten. Daher kann ein anderes Benutzerrollenkonfigurationsmodell, das als „dynamisches“ Benutzerrollenkonfigurationsmodell bezeichnet wird, verwendet werden, um zusätzlich zu den oben erwähnten statischen Benutzerrollen eine Reihe von dynamischen Benutzerrollen zu definieren. Dynamische Benutzerrollen können auf ein Netzwerkgerät, wie z. B. einen Zugangspunkt (AP), heruntergeladen werden, um für einen bestimmten Client nach Bedarf angewendet zu werden.
Trotz der Vorteile, die dynamische Benutzerrollen mit sich bringen, erfordert die Verteilung dynamischer Benutzerrollen an andere APs, z. B. andere APs im selben AP-Cluster oder in derselben Niederlassung, die Übertragung dieser dynamischen Benutzerrollen, was eine unzuverlässige Methode zur Verteilung von Informationen sein kann. Darüber hinaus funktionieren Broadcasting-Mechanismen in der Regel nicht, wenn versucht wird, Informationen an verschiedene virtuelle lokale Netzwerke (VLANS) des AP-Managements zu verteilen.
Dementsprechend sind Beispiele der vorliegenden Offenbarung darauf gerichtet, dynamische Benutzerrollen zu konfigurieren, die von einem cloudbasierten Benutzerrollendienst verwaltet und verteilt werden können, so dass dynamische Benutzerrollen auf eine besser skalierbare Weise verteilt werden können, als dies bisher möglich war. Insbesondere können dynamische Benutzerrollen mit Hilfe des oben erwähnten Benutzerrollendienstes konfiguriert werden. So können beispielsweise die Benutzerrollen sowie die für die jeweilige Benutzerrolle geltenden Richtlinien definiert werden.
In einigen Ausführungsformen der offengelegten Technologie kann ein Benutzergerät beim Verbinden mit einem AP authentifiziert und ihm eine Benutzerrolle zugewiesen werden, obwohl der AP die Konfiguration der Benutzerrolle noch nicht unbedingt kennt. Daher kann der AP die Benutzerrollenkonfiguration von dem cloudbasierten Benutzerrollendienst anfordern. Während dieses Zeitraums kann das Benutzergerät in einen blockierten Zustand versetzt werden. Wenn der AP eine ordnungsgemäße Anfrage sendet, können die angeforderten Benutzerrollenkonfiguration/Details an den AP zurückgesendet werden, der AP kann die Sperrung des Benutzergeräts aufheben, und die Benutzerrollenkonfiguration kann auf das Benutzergerät angewendet werden. Wenn die Anforderung nicht ordnungsgemäß ist, z. B. die angeforderte Benutzerrollenkonfiguration für den AP nicht anwendbar ist, kann die Download-Anforderung durch den Cloud-basierten Benutzerrollendienst zurückgewiesen werden. In einigen Beispielen kann als Reaktion auf die Anforderung ein Ablehnungsgrundcode angezeigt werden. Wenn die Anforderung für die Benutzerrollenkonfiguration zeitlich abgelaufen ist oder aus irgendeinem Grund abgelehnt wird, kann das Benutzergerät im blockierten Zustand verbleiben, und es kann kein weiterer Verkehr/keine weitere Kommunikation zu/von dem Benutzergerät zugelassen werden.
Der Cloud-basierte Benutzerrollendienst kann zusätzlich dieselbe Benutzerrollenkonfiguration bzw. dieselben Benutzerrollendetails an alle benachbarten APs verteilen. Auf diese Weise kann ein Benutzergerät umziehen, roamen oder sich anderweitig mit einem anderen AP verbinden, der nach der Verteilung bereits über die (dynamische) Benutzerrollenkonfiguration verfügt, die auf das Benutzergerät angewendet werden kann.
Bevor Beispiele für die offengelegten Systeme und Methoden im Detail beschrieben werden, ist es sinnvoll, ein Beispiel für ein Bereitstellungsnetz zu beschreiben, in dem die offengelegten Systeme und Methoden in verschiedenen Anwendungen implementiert werden könnten. 1 zeigt ein Beispiel für ein Netzwerk 100, das eine Multi-AP-Mikrozweigstelle umfasst. In diesem Beispiel kann das Netzwerk 100 ein Datenzentrum 102 umfassen, mit dem die Multi-AP-Mikrozweigstelle 130 operativ verbunden ist. Teil des Netzwerks 100 kann auch ein Bereitstellungssystem sein, z. B. ein Cloud-basiertes Zero-Touch-Bereitstellungssystem/-service 114.
Das Rechenzentrum 102 kann repräsentativ für eine Unternehmenszentrale sein. Das Rechenzentrum 102 kann einen Controller oder Core-Switch 104 umfassen, mit dem ein DHCP-Server 106 und eine Policy-Management-Plattform 108 operativ verbunden sind. Je nachdem, wie eine Verbindung zwischen dem Rechenzentrum 102 und einer entfernten Zweigstelle (in diesem Beispiel die Mikrozweigstelle 130) implementiert ist, kann die Funktionalität des Controllers oder Core Switches 104 unterschiedlich sein. Beispielsweise kann das Netzwerk 100 ein Layer-3-geroutetes VLAN sein. In diesem Fall kann ein VPN-Konzentrator Verkehrsströme an einen Core-Switch, z. B. den Core-Switch 104, senden, der ein Hochgeschwindigkeits-Core-Switch sein kann. Der Core-Switch 104 kann dann die Pakete der Datenströme an den erforderlichen nachfolgenden Hop weiterleiten. In einem anderen Beispiel kann das Netzwerk 100 ein Layer-2-verbundenes VLAN sein, und der VPN-Konzentrator kann generische Routing-Kapselungspakete (GRE) (siehe unten) an einen Controller weiterleiten, z. B. an den Controller oder Core Switch 104, der in diesem Fall als Controller fungieren kann.
Wie der Fachmann weiß, kann sich der DHCP-Server 106 auf ein Netzelement beziehen, das jedem Gerät im Netz dynamisch eine IP-Adresse und/oder andere Netzparameter zuweist. Die Policy-Management-Plattform 108 kann implementiert werden, um Geräte, wie z. B. Client-Geräte, sicher/ordnungsgemäß mit einem Netzwerk, z. B. dem Netzwerk 100, zu verbinden. Beispielsweise kann die Policy-Management-Plattform 108 neue Geräte einbinden, unterschiedliche Zugriffsebenen auf das Netzwerk gewähren, die Netzwerksicherheit aufrechterhalten usw.
Wie in 1 weiter dargestellt, kann das Rechenzentrum 102 über einen Overlay-Tunnel 116 mit der Mikrofiliale 130 verbunden sein. Der Overlay-Tunnel 116 kann den Root-AP 132 der Mikrozweigstelle 130 mit einem Kopfstellen-Gateway 110 verbinden, das als VPN-Konzentrator und Overlay-Terminator (z. B. unter Verwendung eines GRE-Tunneling-Protokolls) für die Terminierung von VPN-Tunneln (hier Overlay-Tunnel 116) fungieren kann, wodurch ein Routing von der Mikrozweigstelle 130 in das Rechenzentrum 102 ermöglicht wird. Die Leaf-APs 134A-134C können operativ mit dem Root-AP 132 verbunden sein, über den die Verbindung zum Datenzentrum 102 hergestellt werden kann. Die Mikroverzweigung 130 kann ein oder mehrere Client-Geräte enthalten, z. B. die Client-Geräte 138A-C, von denen jedes direkt mit dem Root-AP 132 oder einem der APs 134A-134C verbunden sein kann. In diesem Beispiel kann die Mikroverzweigung 130 außerdem einen unverwalteten Switch 136 umfassen, an den sich zusätzliche Client-Geräte, z. B. die Client-Geräte 138D-E, anschließen können. Zu den Client-Geräten können Computergeräte wie Laptops, PCs, Tablet-Computer, Smartphones und dergleichen sowie Sensoren oder andere IoT-Geräte gehören.
Wie bereits angedeutet, können sich Benutzerrollen auf Richtliniencontainer/Regelsätze beziehen, die zur Anwendung von Verkehrsrichtlinien auf den Benutzerverkehr an einem Netzwerkgerät, wie z. B. einem AP, verwendet werden können. Innerhalb einer Benutzerrolle können mehrere Regeleinträge definiert werden. In einigen Beispielen spezifiziert jede Regel oder jeder Regeleintrag eine bestimmte Verkehrsrichtlinie. Ein Beispiel für eine Regel kann lauten: „Erlaube“ einen bestimmten Datenfluss, „Verweigere“ einen bestimmten Datenfluss, oder „Priorisiere“ einen bestimmten Datenfluss. Eine Benutzerrollenkonfiguration kann je nach den Anforderungen eines Kunden kompliziert sein.
In 2 ist ein Beispiel für eine Benutzerrollenkonfiguration 200 dargestellt. Wie zu erkennen ist, umfasst die Benutzerrollenkonfiguration 200 eine Vielzahl von Regeln, die auf den Verkehr zu/von einem Benutzergerät anzuwenden sind, auf das die Benutzerrollenkonfiguration 200 angewendet wird. Benutzerrollen können auf einzelne Benutzer oder eine Gruppe von Benutzern angewendet werden. In einigen Ausführungsformen kann ein JavaScript Object Notation (JSON)/ProtoBuf/extensible markup language (XML)-Block einen Satz von Firewall-Regeln enthalten. Sobald ein AP den Block empfängt, kann er den Inhalt des Blocks dekodieren, um die Firewall-Regeln zu erkennen. Zum Beispiel kann die Regel „rule any any match udp 67 68 permit“ einem Benutzer/Client-Gerät erlauben, IP-Adressen von einem DHCP-Server zu beziehen. Die Regel „rule any any match udp 53 53 src-nat vlan 901“ ermöglicht beispielsweise den Zugriff auf einen DNS-Server (Domain Name System), legt aber fest, dass DNS-Anfragen durch NAT (Source Network Address Translation) in die IP-Adresse des AP auf VLAN 901 umgewandelt werden sollen. Das heißt, die übersetzte Quell-IP-Adresse eines Pakets wird verwendet, um Hosts mit privaten IP-Adressen den Zugriff auf ein öffentliches Netzwerk zu ermöglichen] . Andere Regeln wie „rule rule any any match webcategory * deny“ werden verwendet, um den Zugang zu Websites mit unangemessenem Inhalt zu blockieren. Es sollte verstanden werden, dass 2 lediglich ein Beispiel für eine Benutzerrollenkonfiguration mit Beispielregeln/Einstellungen/Parametern darstellt und dass andere Regeln/Benutzerregelkonfigurationen möglich sind und im Rahmen der vorliegenden Offenlegung in Betracht gezogen werden.
Wie bereits angedeutet, kann das traditionelle statische Benutzerrollenkonfigurationsmodell oder -schema verwendet werden, wenn Kunden eine begrenzte Anzahl von Benutzerrollen im Netz haben. Beispielsweise kann ein AP, wie ein Instant AP (IAP), bis zu 32 Benutzerrollenkonfigurationen unterstützen. Die Vielfalt und Anzahl der Endnutzergeräte nimmt jedoch weiter zu, da sich Geräte wie IoT-Geräte über ein WLAN-Edge-Netz verbinden und Hotspots/Betreiber die damit verbundenen Funktionen auf ein WLAN-Edge-Netz auslagern können. Wie bereits erwähnt, können herkömmliche, statische Benutzerrollenkonfigurationsmodelle/-schemata nicht mehr verwendet werden, wenn die Anzahl der Benutzerrollen die maximal zulässige Anzahl überschreitet. BeispielDie aufgeführten Beispiele können es den Nutzern ermöglichen, ihre Geräte sicher über APs zu verbinden.
Dynamische Benutzerrollen können verwendet werden, wenn der Bedarf an Benutzerrollen die Grenzen der traditionellen statischen Benutzerrollenkonfigurationsmodelle überschreitet. Wenn dynamische Benutzerrollen verwendet werden und ein Zugangspunkt hochfährt, kann der Zugangspunkt immer noch statische Benutzerrollen von einem oder mehreren Konfigurationsverwaltungsservern erhalten. Wenn sich zu einem späteren Zeitpunkt ein Client/Benutzergerät mit dem AP verbindet, kann dieses Client/Benutzergerät eine Benutzerrolle erhalten, die nicht in der statischen Konfiguration enthalten ist. Der Zugangspunkt kann dann den Inhalt dieser dynamischen Benutzerrolle dynamisch herunterladen und ihn für das Kunden-/Benutzergerät anwenden. Der Zugangspunkt kann anschließend den Inhalt der dynamischen Benutzerrolle an andere Zugangspunkte im selben AP-Cluster verteilen. Wenn ein Benutzergerät zu einem neuen Zugangspunkt wechselt, kann der neue Zugangspunkt auf diese Weise die entsprechende Benutzerrolle anwenden, ohne den/die oben genannten Konfigurationsverwaltungsserver erneut kontaktieren zu müssen. Insbesondere können dynamische Benutzerrolleninhalte (Benutzerrollenkonfiguration) an einen AP-Controller, wie z. B. einen virtuellen AP-Controller, übertragen werden. Der virtuelle AP-Controller kann dann die Rolleninhalte an die übrigen AP-Cluster-Mitglieder (z. B. APs innerhalb desselben AP-Management-VLANs) weiterverteilen. Der AP kann auch die dynamische Benutzerrollenkonfiguration an andere APs weitergeben. Daher kann eine zentralisierte virtuelle Kontrollinstanz erforderlich sein (was eine Aufwärtsskalierung behindern kann). Auch hier gibt es nur zwei Methoden der Verteilung von Benutzerrollenkonfigurationen, nämlich die Übertragung an andere APs im selben VLAN und die Verwendung eines virtuellen Controllers, der eine AP-„Datenbank“ der APs im Cluster verwalten muss (was, wie hier beschrieben, die Skalierung erschwert). Darüber hinaus können in einigen Beispielen dynamische Benutzerrollenkonfigurationen nicht an APs verteilt werden, die zu einem anderen AP-Cluster/Management-VLAN gehören. Dementsprechend kann die Verteilung von dynamischen Rollenkonfigurationen durch einen AP, der die dynamischen Benutzerrollenkonfigurationen sendet, die Verteilung auf Netzwerkgeräte innerhalb desselben VLANs beschränken. Alternativ können dynamische Benutzerrollen an einen virtuellen AP-Controller gesendet werden, und von dem virtuellen AP-Controller kann die dynamische Benutzerrollenkonfiguration an andere APs verteilt werden, aber die Skalierung mit einem solchen Mechanismus kann begrenzt sein.
exampleDisclosed examples include a cloud-based user role service that addresses the scalability-related shortcomings of traditional/conventional user role configuration models. Das heißt, die Beispiele erfordern nicht mehr die Verwendung eines zentralen oder primären AP. Vielmehr können alle APs durch den cloudbasierten Benutzerrollendienst, der die Verwaltung und Verteilung dynamischer Benutzerrollen erleichtert, logisch gleich behandelt werden.
3 zeigt ein schematisches Diagramm eines Systems 300 in Übereinstimmung mit einem oder mehreren Beispielen. Wie in 3 dargestellt, kann das System 300 Folgendes umfassen: Benutzergeräte, z. B. Benutzergerät 300Q, Benutzergerät 300R, Benutzergerät 300S, Benutzergerät 300T; Netzwerkgeräte, z. B. Netzwerkgerät 302X, Netzwerkgerät 302Y; ein Netzwerk 304; einen Richtlinienmanager 306; und einen Datenspeicher 308. Jede dieser Komponenten wird im Folgenden anhand von einem oder mehreren Beispielen erläutert.
In einigen Beispielen kann ein Benutzergerät, z. B. Benutzergerät 300Q, Benutzergerät 300R, Benutzergerät 300S, Benutzergerät 300T, eine Hardwarekomponente sein, die eine Kommunikation von einem anderen Benutzergerät des Systems empfängt und/oder eine Kommunikation an ein anderes Benutzergerät des Systems sendet. Die Kommunikation kann in einer oder mehreren Nachrichten gesendet oder empfangen werden. Wenn das Benutzergerät eine Nachricht empfängt, kann das Benutzergerät als Ziel der Nachricht bezeichnet werden. Wenn ein Benutzergerät eine Nachricht sendet, kann das Benutzergerät als Quelle der Nachricht bezeichnet werden. Bei der Kommunikation kann es sich beispielsweise um eine Anforderung oder Antwort auf einen oder mehrere Dienste eines anderen Benutzergeräts handeln.
In einem oder mehreren Beispielen kann ein Benutzergerät, z. B. Benutzergerät 300Q, Benutzergerät 300R, Benutzergerät 300S, Benutzergerät 300T, ein oder mehrere mobile Benutzergeräte sein (z. B., Laptop-Computer, Smartphone, persönlicher digitaler Assistent, Tablet-Computer oder ein anderes mobiles Benutzergerät), Spielkonsole, Desktop-Computer, Server, Blades in einem Server-Gehäuse oder jede andere Art von elektronischem Benutzergerät oder Benutzergeräten sein, die zumindest das Minimum an Verarbeitungsleistung, Speicher und Eingabe- und Ausgabegerät(en) enthalten, um ein oder mehrere Beispiele auszuführen, wie z. B. Sensoren, IoT-Geräte und dergleichen. Das Benutzergerät kann beispielsweise einen oder mehrere Hardware-Prozessoren, einen zugehörigen Speicher (z. B. RAM, Cache-Speicher, Flash-Speicher usw.), ein oder mehrere Speicher-Benutzergeräte (z. B. eine Festplatte, ein optisches Laufwerk wie ein CD-Laufwerk oder ein DVD-Laufwerk, einen Flash-Speicher-Stick usw.) und zahlreiche andere Elemente und Funktionalitäten umfassen. Der (die) Hardware-Prozessor(en) kann (können) ein integrierter Schaltkreis zur Verarbeitung von Anweisungen sein. Bei dem/den Hardware-Prozessor(en) kann es sich beispielsweise um einen oder mehrere Kerne oder Mikrokerne eines Prozessors handeln. Das Benutzergerät kann auch ein oder mehrere Eingabegeräte enthalten, wie z. B. einen Touchscreen, eine Tastatur, eine Maus, ein Mikrofon, ein Touchpad, einen elektronischen Stift oder jede andere Art von Eingabegerät. Darüber hinaus kann das Benutzergerät ein oder mehrere Ausgabegeräte umfassen, wie z. B. einen Bildschirm (z. B. eine Flüssigkristallanzeige (LCD), ein Plasmadisplay, einen Touchscreen, einen Kathodenstrahlröhrenmonitor, einen Projektor oder ein anderes Anzeigegerät), einen Drucker, einen externen Speicher oder ein anderes Ausgabegerät. Eines oder mehrere der Ausgabegeräte können mit dem/den Eingabegerät(en) identisch oder davon verschieden sein. Das/die Eingabe- und Ausgabegerät(e) kann/können lokal oder aus der Ferne (z. B. über das Netz) mit dem/den Hardware-Prozessor(en), dem Speicher und dem/den Speicher-Benutzergerät(en) verbunden sein. Es gibt viele verschiedene Arten von Benutzergeräten, und das/die oben genannte(n) Eingabe- und Ausgabegerät(e) können auch andere Formen annehmen.
Das Benutzergerät kann über eine Netzwerkschnittstellenverbindung (nicht dargestellt) und ein Netzwerkgerät, z. B. Netzwerkgerät 302X, Netzwerkgerät 302Y, mit einem Netzwerk 304 verbunden sein. Bei dem Netzwerk 304 kann es sich um ein lokales Netzwerk (LAN), ein Weitverkehrsnetz (WAN) wie das Internet, ein Mobilfunknetz oder eine andere Art von Netzwerk oder eine Kombination von Netzwerken handeln. Außerdem können sich die verschiedenen Benutzergeräte in demselben Internetprotokoll (IP)-Teilnetz oder in verschiedenen IP-Teilnetzen befinden. So können sich beispielsweise zwei oder mehr Benutzergeräte im selben virtuellen lokalen Netzwerk (VLAN) befinden.
Ein Netzwerkgerät, z. B. Netzwerkgerät 302X, Netzwerkgerät 302Y, kann ein digitales Hardware-Benutzergerät sein, das kommunikativ mit dem Netzwerk 304 verbunden sein kann. Beispielsweise kann ein Benutzergerät direkt verdrahtet oder drahtlos kommunikativ mit einem einzelnen AP verbunden sein, der direkt kommunikativ mit einem einzelnen Controller verbunden sein kann, der wiederum mit dem Netzwerk (z. B. Netzwerk 304) verbunden sein kann. Im Beispiel kann das Netzwerkgerät der AP, der Controller, ein AP mit der Funktionalität eines Controllers, ein Switch (z. B. ein Mobility Access Switch) oder ein anderes derartiges Benutzergerät sein. Darüber hinaus kann ein Netzwerkgerät beispielsweise ein Controller sein, während ein anderes Netzwerkgerät ein AP sein kann. Das Netzwerkgerät, das in diesem Beispiel der AP ist, kann über das Netzwerkgerät, das ein Controller ist, mit dem Netzwerk verbunden sein oder auch nicht.
Ein AP kann eine von einem Benutzergerät getrennte Hardwareeinheit sein, die direkt, z. B. drahtgebunden oder drahtlos, mit dem Benutzergerät verbunden ist und sich in einem Kommunikationspfad vom Benutzergerät zum Netzwerk befindet. Mit anderen Worten, der AP kann direkt über die direkte drahtgebundene/drahtlose Verbindung mit einer Netzwerkschnittstellenkarte auf dem Benutzergerät (z. B. Benutzergerät 300Q, Benutzergerät 300R, Benutzergerät 300S, Benutzergerät 300T) verbunden sein. Ferner können APs direkt mit dem Netzwerk 304 verbunden sein oder über einen Controller mit dem Netzwerk 304 verbunden sein. Bei dem AP kann es sich beispielsweise um einen drahtlosen Zugangspunkt (WAP) handeln, der drahtlos mit Benutzergeräten unter Verwendung von Wi-Fi, Bluetooth oder verwandten Standards kommuniziert und mit einem kabelgebundenen Netzwerk verbunden ist.
Jedes Netzgerät kann zu jedem Zeitpunkt mit einer beliebigen Anzahl von Benutzergeräten verbunden sein. Insbesondere kann jedes Netzwerkgerät zu einem bestimmten Zeitpunkt mit keinem Benutzergerät, einem einzigen Benutzergerät oder mehreren Benutzergeräten verbunden sein. Darüber hinaus kann die Anzahl der mit einem Netzwerkgerät verbundenen Benutzergeräte unter den Netzwerkgeräten heterogen sein, d. h., die Netzwerkgeräte können mit einer unterschiedlichen Anzahl von Benutzergeräten verbunden sein.
In einem oder mehreren Beispielen kann ein Netzwerkgerät so konfiguriert sein, dass es entscheidet, ob ein Benutzergerät mit einem anderen Benutzergerät im System kommunizieren darf. Das Netzwerkgerät, das die Entscheidung trifft, kann das Netzwerkgerät sein, das der Quelle der Nachricht zugeordnet ist, und/oder das Netzwerkgerät, das dem Ziel der Nachricht zugeordnet ist.
In Fortführung von 3 können die Netzwerkgeräte, z. B. Netzwerkgerät 302X, Netzwerkgerät 302Y, kontinuierlich oder intermittierend, direkt oder über das Netzwerk, mit einem Richtlinienmanager 306 verbunden sein. Der Richtlinienmanager 306 kann einem Computersystem entsprechen oder auf einem Computersystem ausgeführt werden und kann das Computersystem veranlassen, Benutzergerätedatensätze zu verwalten, z. B. Benutzergerätedatensatz 310Q (entsprechend Benutzergerät 300Q), Benutzergerätedatensatz 310T (entsprechend Benutzergerät 300T), und Benutzerrollendatensätze, z. B. Benutzerrollendatensatz 312M, Benutzerrollendatensatz 312N. Insbesondere kann der Richtlinienmanager 306 eine Benutzeroberfläche enthalten, die es einem Administrator ermöglicht, Benutzergerätedatensätze und Benutzerrollendatensätze zu erstellen, zu konfigurieren, zu ändern und zu löschen. Der Richtlinienmanager 306 kann ferner Funktionen zur entsprechenden Aktualisierung der Benutzergerätedatensätze und Benutzerrollendatensätze enthalten.
Das Computersystem des Richtlinienmanagers 306 kann ein oder mehrere mobile Benutzergeräte (z. B. Laptops, Smartphones, persönliche digitale Assistenten, Tablet-Computer oder andere mobile Benutzergeräte), Desktop-Computer, Server, Blades in einem Server-Gehäuse oder jede andere Art von Computer-Benutzergerät oder Benutzergeräten sein, die zumindest ein Minimum an Verarbeitungsleistung, Speicher und Eingabe- und Ausgabegerät(en) zur Durchführung eines oder mehrerer Beispiele aufweisen. Es gibt viele verschiedene Arten von Computersystemen, und das/die oben erwähnte(n) Eingabe- und Ausgabegerät(e) können andere Formen annehmen. Außerdem können sich ein oder mehrere Elemente des genannten Computersystems an einem entfernten Ort befinden und über ein Netzwerk mit den anderen Elementen verbunden sein.
Wie oben erwähnt, können Beispiele der offengelegten Technologien einen Cloud-basierten Benutzerrollendienst umfassen, über den Benutzerrollenkonfigurationen gepflegt und abgerufen werden können. Dementsprechend kann der Richtlinienmanager 306 in/als Teil eines cloudbasierten Benutzerrollendienstes 330 verkörpert sein, der operativ mit dem Netzwerk 304 verbunden sein kann. In einigen Beispielen kann der Richtlinienmanager 306 als eigenständige/getrennte Komponente implementiert werden, auf die ein fernimplementierter cloudbasierter Benutzerrollendienst 330 zugreifen kann. Wie in 3 dargestellt, kann der Richtlinienmanager 306 ein Teil des Benutzerrollendienstes 330 sein oder getrennt vom Benutzerrollendienst 330 implementiert werden. In jedem Fall kann der Cloud-basierte Benutzerrollendienst eine verbesserte Skalierbarkeit (mit einer größeren Anzahl von Benutzergeräten) und die Fähigkeit zum Zugriff auf und zur Bereitstellung von dynamischen Benutzerrollenkonfigurationen für Netzwerkgeräte ermöglichen. Dies steht im Gegensatz z. B. zum Broadcasting, bei dem in einem großen VLAN z. B. Broadcast-Nachrichten für jede Aktualisierung/Herunterladen einer Benutzerrolle an alle VLAN-Mitglieder gesendet werden müssten. Bei der Verwendung eines virtuellen Controllers können die Kosten für die Aufrechterhaltung der AP-Mitgliedschaft mit der Anzahl der APs steigen, und derzeit können z. B. für ein Instant-AP-Cluster nur 128 APs pro Cluster unterstützt werden, was die Skalierbarkeit einschränkt. Das bedeutet, dass der Zugriff auf Cloud-basierte Benutzerrollen nicht durch die maximale Anzahl der unterstützten APs und/oder die Beschränkungen für das Aktualisieren/Herunterladen von Benutzerrollen eingeschränkt ist.
In einigen Beispielen können dynamische Benutzerrollen mithilfe des Richtlinienmanagers 306 gegenüber dem cloudbasierten Benutzerrollendienst 330 konfiguriert werden. Beispielsweise kann ein Netzwerkadministrator oder eine ähnliche Instanz die dynamischen Benutzerrollen, die Richtlinien, nach denen die dynamischen Benutzerrollen angewendet werden sollen, und die tatsächlichen dynamischen Benutzerrollenkonfigurationen (die weiter unten ausführlicher erläutert werden) definieren. Sobald sich ein Benutzergerät, z. B. das Benutzergerät 300Q, mit einem AP, z. B. einem Netzwerkgerät 302X, verbindet, kann das Benutzergerät 300Q authentifiziert werden. Die Authentifizierung eines Benutzergeräts kann beispielsweise auf Anmeldeinformationen wie Benutzername und Passwort, einem Gerätezertifikat oder einer Geräte-MAC-Adresse usw. basieren. Das Netzwerkgerät 302X, bei dem es sich um einen AP handeln kann, kann die Anmeldedaten sicher an einen Backend-Authentifizierungsserver weiterleiten, z. B. einen RADIUS-Server (Remote Authentication Dial-in User Service), der dann die Authentifizierung des Benutzergeräts durchführt. Es können auch andere Mittel oder Methoden der Authentifizierung verwendet werden, z. B. die Mehrfaktor-Authentifizierung.
Wenn das Benutzergerät 300Q authentifiziert ist bzw. die Authentifizierung besteht, kann das Netzwerkgerät 302X dem Benutzergerät 300Q eine Benutzerrolle zuweisen. Es sollte verstanden werden, dass die Zuweisung einer Benutzerrolle an das Benutzergerät 300Q noch nicht das Parsen und Anwenden der tatsächlichen Benutzerrollenkonfiguration auf die Kommunikation des Benutzergeräts 300Q beinhaltet. Vielmehr kann das Netzwerkgerät 302X die tatsächliche Benutzerrollenkonfiguration, verkörpert als Benutzerrollendatensatz, vom Benutzerrollendienst 330 gegenüber dem Richtlinienmanager 306 anfordern.
Der Benutzerrollendienst 330 kann feststellen, ob die Anforderung der Benutzerrollenkonfiguration ordnungsgemäß ist. Die Feststellung, ob eine Benutzerrollenkonfigurationsanforderung ordnungsgemäß ist, kann die Bestimmung der Quelle der Anforderung und die Feststellung beinhalten, ob diese Quelle die angeforderte Benutzerrollenkonfiguration empfangen darf oder nicht. Beispielsweise kann der Benutzerrollendienst 300 feststellen, ob die Anforderung für die Benutzerrollenkonfiguration von einem zulässigen Netzwerkgerät oder einem zulässigen WLAN Service Set Identifier (SSID) kommt. Das heißt, eine bestimmte dynamische Benutzerrolle kann selektiv nur für bestimmte APs oder SSIDs aktiviert werden. Wenn die Anforderung korrekt ist, kann das Netzwerkgerät 302 die angeforderte Benutzerrollenkonfiguration in Form eines Benutzerrollendatensatzes übermitteln (z. B. als Datei oder Datenspeicherdatensatz aus dem Datenspeicher 308, wie weiter unten erläutert wird). Wenn die Anforderung nicht ordnungsgemäß ist, kann der Benutzerrollendienst 330 die Anforderung ablehnen, und in einigen Beispielen kann ein Ablehnungsgrundcode oder eine ähnliche Benachrichtigung an das anfordernde Netzwerkgerät, Benutzergerät, den Benutzer usw. übermittelt werden. Wenn beispielsweise ein AP eine Rolle angefordert hat, die im cloudbasierten Benutzerrollendienst noch nicht bekannt/konfiguriert ist, kann ein Ablehnungsgrundcode wie „unbekannte Rolle“ übermittelt werden.
Der Benutzerrollendienst 330 kann die Benutzerrollenkonfiguration/den Benutzerrollendatensatz auch an benachbarte APs oder, in einigen Beispielen, an alle benachbarten APs des anfordernden APs übertragen oder verteilen. In diesem Beispiel kann das Netzwerkgerät 302Y ein benachbarter AP zum Netzwerkgerät 302X sein. Während das Netzwerkgerät 302X auf den Empfang der Benutzerrollenkonfiguration vom Benutzerrollendienst 330 wartet, kann es das Benutzergerät 300Q in einen vorübergehenden Sperrzustand versetzen. Sobald das Netzwerkgerät 302X die angeforderte Benutzerrollenkonfiguration erhält, kann das Netzwerkgerät 302X die Sperrung des Benutzergeräts 300Q aufheben, und das Netzwerkgerät 302X kann die Benutzerrollenkonfiguration auf das Benutzergerät 300Q anwenden. Es sollte verstanden werden, dass, sobald die Benutzerrollenkonfiguration angewendet wird, der gesamte Verkehr zu/von dem Benutzergerät 302X in Übereinstimmung mit der Benutzerrollenkonfiguration geregelt/kontrolliert/eingeschränkt wird, z.B. in Übereinstimmung mit den definierten Benutzerrollenbeziehungen, die in der Benutzerrollenkonfiguration/dem Datensatz festgelegt sind. In einigen Beispielen, in denen die Anfrage abgelehnt wird, kann das Benutzergerät 300Q zusätzlich zur Ablehnung der Anfrage (und in einigen Beispielen zur Übermittlung eines Ablehnungsgrundcodes oder einer ähnlichen Benachrichtigung an das Benutzergerät 300Q) in seinem blockierten Zustand bleiben. Dies kann verhindern, dass weiterer Datenverkehr von/von Benutzergerät 300Q gesendet/empfangen wird. Es sollte klar sein, dass in einigen Beispielen der Ablehnungsgrundcode/die Benachrichtigung vom/vom Benutzerrollendienst 330 gesendet werden kann.
Wenn man bedenkt, dass das Netzwerkgerät 302X eine angeforderte Benutzerrollenkonfiguration an benachbarte Netzwerkgeräte, wie z. B. das Netzwerkgerät 302Y, verteilt, kann das Netzwerkgerät 302Y die Benutzerrollenkonfiguration auf das Benutzergerät 300Q anwenden, wenn sich das Benutzergerät 300Q mit dem Netzwerkgerät 302Y verbinden/roamen würde. Beispielsweise muss das Netzwerkgerät 302Y weder den Benutzerrollendienst 330 noch ein anderes Netzwerkgerät kontaktieren oder darauf zugreifen. Es versteht sich, dass ein AP, z. B. ein Beispiel für das Netzwerkgerät 302Y, eine Liste von Benutzergerätedatensätzen führen kann, die entsprechende Benutzer-IDs (z. B. MAC-Adressen) und Benutzerrollen-IDs enthalten, wie hier beschrieben. Die dynamische Benutzerrollenkonfiguration kann auch als Satz von Benutzerrollendatensätzen (z. B. Benutzerrollendatensatz 312N) geführt werden, von denen jeder eine Benutzerrollenkennung (z. B. Benutzerrollenkennung 322) und mit dieser Benutzerrolle verbundene Regeln (z. B. definierte Benutzerrollenbeziehungen 324) enthält. Der AP kann zunächst feststellen, ob der Eintrag des gerooteten Benutzergeräts in einer Benutzergerätedatensatz-Cachetabelle vorhanden ist, und wenn dies der Fall ist, die Zuweisung der Benutzerrollen-ID an den Benutzer vornehmen. Es sollte verstanden werden, dass die Benutzergerätedatensatz-Cachetabelle eine Liste von Benutzergeräteeinträgen in Bezug auf Benutzergeräte enthalten kann, die derzeit mit einem AP verbunden sind. In jedem Benutzergeräteeintrag sind mindestens einige Schicht-2-/Schicht-3-Attribute enthalten, wie z. B. die Media-Access-Control-Adresse des Geräts, die Internet-Protokoll-Adresse, die Virtual-Local-Area-Network-ID, die Zugriffskontrollliste/Rolle usw. Der Zugangskontrolldienst kann dann in der Benutzerrollen-Cachetabelle für diese Rollen-ID nachsehen und die Konfiguration der Benutzerrolle abrufen.
Der Richtlinienmanager 306 kann mit einem Datenspeicher 308 verbunden sein. In einem oder mehreren Beispielen ist der Datenspeicher 308 eine beliebige Art von Speichereinheit und/oder Benutzergerät (z. B. ein Dateisystem, eine Datenbank, eine Sammlung von Tabellen oder ein anderer Speichermechanismus) zum Speichern von Daten. Darüber hinaus kann die Datenablage 308 mehrere verschiedene Speichereinheiten und/oder Benutzergeräte umfassen. Die mehreren verschiedenen Speichereinheiten und/oder Benutzergeräte können vom gleichen Typ sein oder sich am gleichen physischen Standort befinden. Ferner kann der Datenspeicher auf demselben Computersystem wie der Richtlinienmanager 306 sein oder ausgeführt werden. Alternativ oder zusätzlich kann sich das Datenarchiv 308 auf einem separaten Computersystem befinden.
Der Datenspeicher 308 kann so konfiguriert sein, dass er Benutzergerätedatensätze, z.B. Benutzergerätedatensatz 310Q, Benutzergerätedatensatz 310T, für jedes mit einem Netzwerkgerät, z.B. Netzwerkgerät 302X, Netzwerkgerät 302Y, verbundene Benutzergerät speichert. Ein Benutzergerätedatensatz, z. B. Benutzergerätedatensatz 310Q, Benutzergerätedatensatz 310T, kann Informationen über ein Benutzergerät enthalten. Zum Speichern eines Benutzergerätedatensatzes kann jeder beliebige Mechanismus verwendet werden, ohne dass dies vom Anwendungsbereich der Ansprüche abweicht. Insbesondere kann ein Benutzergerätedatensatz eine Datei, ein Datenbankdatensatz, ein Eintrag oder eine Zeile in einer Tabelle oder eine andere Datenstruktur sein.
3 zeigt ein Beispiel für einen Benutzergerätedatensatz, Benutzergerätedatensatz 310Q. Wie in 3 gezeigt, kann der Benutzergerätedatensatz 310Q beispielsweise eine Benutzergeräteadresse 314 und eine Benutzerkennung 315 gemäß einem oder mehreren Beispielen enthalten. Eine Benutzergeräteadresse 314 kann ein eindeutiger Bezeichner für ein Benutzergerät sein. Bei der Benutzergeräteadresse kann es sich beispielsweise um eine MAC-Adresse (Media Access Control), eine Seriennummer des Benutzergeräts oder eine andere eindeutige Kennung des Benutzergeräts handeln.
Eine Benutzerkennung 315 kann eine eindeutige Kennung eines Benutzers sein, der das Benutzergerät besitzt oder anderweitig kontrolliert. Bei der Benutzerkennung kann es sich um eine einzelne Kennung (z. B. Steuerkennzeichen, Anmeldename, E-Mail-Adresse, eine vom System zugewiesene eindeutige Kennung) oder um eine Kombination von Kennungen (z. B. eine Kombination aus Postanschrift und Name, eine Kombination aus Name und Geburtsdatum oder eine andere Kombination) handeln.
In einem oder mehreren Beispielen enthält der Datenspeicher außerdem Funktionen zum Speichern von Benutzerdatensätzen, z. B. Benutzerdatensatz 311W, Benutzerdatensatz 311V. Jeder Benutzerdatensatz kann ein Benutzerprofil enthalten. In einem oder mehreren Beispielen entspricht das Benutzerprofil den Informationen über einen Benutzer eines oder mehrerer Benutzergeräte. 3 zeigt ein Beispiel für einen Benutzerdatensatz, z. B. den Benutzerdatensatz 311W. Wie im Beispiel gezeigt, kann der Benutzerdatensatz 311W einen Benutzeridentifikator 318 und einen Benutzerrollenkennzeichner 320 enthalten. Der Benutzeridentifikator 318 kann ein Querverweis auf den Benutzeridentifikator 315 im Gerätedatensatz sein. Die Benutzerkennung kann also die gleiche oder eine ähnliche sein wie die oben beschriebene Benutzerkennung.
In einem oder mehreren Beispielen kann eine Benutzerrollenkennung, wie z. B. die Benutzerrollenkennung 320, eine Kennung der Benutzerrolle des Benutzers sein. Eine Benutzerrolle kann eine logische Klassifizierung eines Benutzers sein, die die Rolle definiert, die der Benutzer innerhalb einer Gruppe oder einer bestimmten Aktivität spielt. Die Benutzerrolle kann zum Beispiel die Beschäftigungsposition des Benutzers, die Abteilung, in der der Benutzer arbeitet, ein Projekt, an dem der Benutzer arbeitet, eine Organisation, der der Benutzer angehört, oder eine andere Klassifizierung des Benutzers sein. Der Begriff „Benutzerrolle“, wie er in dieser Anwendung verwendet wird, schließt Medienzugriffskontrolladressen und Internetprotokolladressen der Benutzergeräte aus.
Obwohl 3 einen Benutzerdatensatz zeigt, der nur eine Benutzerrollenkennung enthält, kann der Benutzerdatensatz mehrere Benutzerrollenkennungen enthalten, wenn ein Benutzer mehrere Benutzerrollen hat. Die Datenablage 308 kann ferner Informationen speichern, die eine Hierarchie von Benutzerrollen definieren. Die Hierarchie kann eine Rangfolge der Benutzerrollen in Bezug darauf festlegen, ob eine Kommunikation erlaubt ist. So kann auf Benutzerrollen entsprechend der Hierarchie zugegriffen werden, um festzustellen, ob eine bestimmte Kommunikation erlaubt ist. Wenn die Benutzerrolle keine Kommunikation zulässt, wird gemäß einem oder mehreren Beispielen auf die nächste Benutzerrolle zugegriffen.
Die Datenablage 308 kann außerdem Funktionen zum Speichern von Benutzerrollendatensätzen (z. B. Benutzerrollendatensatz 312M, Benutzerrollendatensatz 312N) für jede definierte Benutzerrolle im System enthalten. Wie in 3 gezeigt, enthält der Benutzerrollendatensatz 312N eine Benutzerrollenkennung 322 und einen Satz definierter Benutzerrollenbeziehungen 324. Der Benutzerrollenkennzeichner 322 kann ein Querverweis auf den Benutzerrollenkennzeichner 320 sein, der Teil eines Benutzergerätedatensatzes ist.
Die Menge der definierten Benutzerrollenbeziehungen 324, die einer bestimmten Benutzerrolle zugeordnet sind, kann festlegen, ob die Kommunikation zwischen Benutzergeräten von Benutzern mit dieser bestimmten Benutzerrolle erlaubt ist. Die definierten Benutzerrollenbeziehungen können in einigen Beispielen definiert werden, bevor die Nachricht, die erlaubt oder verweigert werden soll, gesendet wird. In einigen Beispielen können die definierten Benutzerrollenbeziehungen für eine bestimmte Benutzerrolle als eine Gruppe von Benutzerrollen, mit denen die bestimmte Benutzerrolle kommunizieren darf, als eine Gruppe von Benutzerrollen, mit denen die bestimmte Benutzerrolle nicht kommunizieren darf, oder als eine Kombination davon gepflegt werden. Darüber hinaus können eine oder mehrere Standard-Benutzerrollenbeziehungen definiert werden, die eine Standard-Aktion festlegen, wenn eine Benutzerrollenbeziehung nicht in der Menge der Benutzerrollenbeziehungen definiert ist (nicht dargestellt).
In einem oder mehreren Beispielen kann der Satz von Benutzerrollenbeziehungen separate Benutzerrollenbeziehungen für verschiedene Kommunikationsphasen enthalten. Ein Stadium der Kommunikation kann sich auf die zeitliche Position einer Kommunikation innerhalb der gesamten Kommunikationssitzung beziehen. So kann beispielsweise eine Benutzerrollenbeziehung bestehen, wenn eine erste bestimmte Benutzerrolle eine Kommunikation mit einer zweiten bestimmten Benutzerrolle einleitet. Eine andere Benutzerrollenbeziehung kann bestehen, wenn die erste bestimmte Benutzerrolle auf eine Kommunikation von der zweiten bestimmten Benutzerrolle antwortet. Eine dritte Benutzerrollenbeziehung kann bestehen, wenn die erste bestimmte Benutzerrolle bereits eine Kommunikation mit der zweiten bestimmten Benutzerrolle aufgebaut hat. Eine Kommunikationssitzung kann sich auf einen Datensatz beziehen, dessen Schlüssel aus fünf Attributen besteht: Quell-IP, Ziel-IP, Protokoll (TCP/UDP), Quell-Port und Ziel-Port, und dessen Wert die von einem Zugangskontrollsystem durchgeführte „Aktion“ ist, z. B. Zulassen/Ablehnen/Quell-IP/Ziel-IP übersetzen usw.
In einem oder mehreren Beispielen kann der Satz von Benutzerrollenbeziehungen separate Benutzerrollenbeziehungen für verschiedene Arten der Kommunikation enthalten. Eine Kommunikationsart kann sich auf die Art der Daten beziehen, die in der Kommunikation übertragen werden. So können beispielsweise separate Benutzerrollenbeziehungen für Sprachdaten, Videodaten, Hintergrunddaten und Best-Effort-Daten bestehen.
In einem oder mehreren Beispielen können einzelne Benutzerrollenbeziehungen für eine Sammlung von Benutzerrollen definiert werden. Zum Beispiel kann eine Benutzerrollenbeziehung definiert werden, wenn der/die Benutzer, die der Quelle und/oder dem Ziel einer Kommunikation entsprechen, eine erste Sammlung von Benutzerrollen haben, während eine andere Benutzerrollenbeziehung definiert werden kann, wenn der/die Benutzer, die der Quelle und/oder dem Ziel entsprechen, eine zweite Sammlung von Benutzerrollen haben. In diesem Beispiel können sich die erste und die zweite Sammlung von Benutzerrollen überschneiden oder auch nicht.
Es können verschiedene Techniken zur Speicherung von Benutzerrollenbeziehungen verwendet werden. Beispielsweise können Benutzerrollenbeziehungen als Zugriffskontrolllisten, in einem Satz von einer oder mehreren Tabellen oder unter Verwendung eines anderen Speichermechanismus zur Speicherung von Berechtigungen gespeichert werden. Außerdem zeigt 3 nur eine mögliche Speicherstruktur zum Speichern von Datensätzen im Datenspeicher. Es können auch andere Speicherstrukturen verwendet werden, ohne dass dies vom Anwendungsbereich der Ansprüche abweicht.
3 zeigt zwar eine Konfiguration von Bauteilen, doch können auch andere Konfigurationen verwendet werden, ohne dass dies vom Anwendungsbereich der Ansprüche abweicht. So können beispielsweise verschiedene Komponenten zu einer einzigen Komponente kombiniert werden. Ein weiteres Beispiel ist, dass die von einer einzelnen Komponente ausgeführte Funktionalität von zwei oder mehr Komponenten ausgeführt werden kann.
4A ist ein Blockdiagramm einer beispielhaften Rechnerkomponente oder eines Geräts 400 zur Durchführung einer Cloudorchestrierten Benutzerrollenverwaltung gemäß einem Beispiel. Bei der Rechnerkomponente 400 kann es sich beispielsweise um einen Controller, einen Prozessor oder eine andere ähnliche Rechnerkomponente handeln, die in der Lage ist, Daten zu verarbeiten, z. B. ein AP oder AP-Controller. In der Beispielimplementierung von 4A umfasst die Rechnerkomponente 400 einen Hardware-Prozessor 402 und ein maschinenlesbares Speichermedium 404.
Bei dem Hardware-Prozessor 402 kann es sich um eine oder mehrere Zentraleinheiten (CPUs), halbleiterbasierte Mikroprozessoren und/oder andere Hardwarevorrichtungen handeln, die zum Abrufen und Ausführen von Anweisungen geeignet sind, die in dem maschinenlesbaren Speichermedium 404 gespeichert sind. Der Hardwareprozessor 402 kann Befehle, wie die Befehle 406-412, abrufen, dekodieren und ausführen, um Prozesse oder Vorgänge zur Verteilung von Benutzerrollenkonfigurationen zu steuern. Alternativ oder zusätzlich zum Abrufen und Ausführen von Befehlen kann der Hardware-Prozessor 402 einen oder mehrere elektronische Schaltkreise enthalten, die elektronische Komponenten zur Ausführung der Funktionalität eines oder mehrerer Befehle umfassen, wie z. B. ein Field Programmable Gate Array (FPGA), einen anwendungsspezifischen integrierten Schaltkreis (ASIC) oder andere elektronische Schaltkreise.
Ein maschinenlesbares Speichermedium, wie das maschinenlesbare Speichermedium 404, kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät sein, das ausführbare Anweisungen enthält oder speichert. Bei dem maschinenlesbaren Speichermedium 404 kann es sich beispielsweise um einen Direktzugriffsspeicher (RAM), einen nichtflüchtigen RAM (NVRAM), einen elektrisch löschbaren programmierbaren Festspeicher (EEPROM), ein Speichergerät, eine optische Platte oder Ähnliches handeln. In einigen Beispielen kann das maschinenlesbare Speichermedium 404 ein nicht-transitorisches Speichermedium sein, wobei der Begriff „nicht-transitorisch“ nicht die transitorischen Übertragungssignale umfasst. Wie im Folgenden ausführlich beschrieben, kann das maschinenlesbare Speichermedium 404 mit ausführbaren Befehlen kodiert sein, z. B. mit den Befehlen 406-412.
Der Hardware-Prozessor 402 kann die Anweisung 406 ausführen, um bei einem Cloud-basierten Rollenverwaltungsdienst (auch als der oben erwähnte Benutzerrollendienst bezeichnet) von einem AP eine Anforderung für eine Benutzerrollenkonfiguration zu empfangen. Wie oben beschrieben, kann sich ein Benutzergerät mit einem Netzwerkgerät, wie einem AP, z. B. einem der Netzwerkgeräte 302X, 302Y (3), verbinden/assoziieren. Es sollte klar sein, dass ein solcher Cloud-basierter Rollenverwaltungsdienst auch in anderen Netzwerkgeräten als nur APs implementiert werden kann. Beispielsweise kann ein Cloud-basierter Rollenverwaltungsdienst in jedem Netzwerkgerät implementiert werden, das in der Lage ist, Benutzerdatenrichtlinien auf der Grundlage einer Benutzerrolle durchzusetzen, z. B. in einem verkabelten Switch, einem Controller usw. Beim Verbinden/Assoziieren mit einem AP kann der AP das Benutzergerät authentifizieren. Wie bereits erwähnt, kann die Authentifizierung des Benutzergeräts auf der Grundlage von Informationen zur Identifizierung des Benutzergeräts (und/oder der SSID, zu der das Benutzergerät gehört) erfolgen, die an einen Authentifizierungsserver/-service gesendet werden können. Wenn das Benutzergerät den Authentifizierungsprozess besteht, kann der AP dem authentifizierten Benutzergerät eine Benutzerrolle zuweisen. Wie oben (in Verbindung mit 3) beschrieben, kann das Benutzergerät durch eine Benutzergeräteadresse, z. B. eine MAC-Adresse, identifiziert werden und kann darüber hinaus mit einer Art Benutzeridentifikation/Kennzeichen verknüpft sein, die einen Benutzer angibt, der mit dem Benutzergerät verbunden ist bzw. es nutzt.
Der Benutzergerätedatensatz 310Q (3) enthält zum Beispiel sowohl die Benutzergeräteadresse 314 als auch die Benutzer-ID 315. In einigen Beispielen entspricht die Benutzer-ID 315 einer Benutzer-ID 318, die als Teil eines Benutzerdatensatzes enthalten ist, z. B. des Benutzerdatensatzes 311 W, der außerdem eine Benutzerrollen-ID 320 enthalten kann. Diese Benutzerrollen-ID 320 wiederum entspricht einer Benutzerrollen-ID 322, die in einem Benutzerrollendatensatz 312N enthalten ist, der wiederum definierte Benutzerrollenbeziehungen 324 enthält. Auf diese Weise kann auf der Grundlage des Benutzers/Benutzergeräts die entsprechende Benutzerrolle bestimmt werden.
In einigen Beispielen führt der AP eine Prüfung durch, um festzustellen, ob er die entsprechende Benutzerrollenkonfiguration hat, die er auf das Benutzergerät anwenden kann. Wenn dies nicht der Fall ist, kann der AP die Benutzerrollenkonfigurationsdatei/den Datensatz von dem cloudbasierten Benutzerrollenverwaltungsdienst anfordern.
Der Hardware-Prozessor 402 kann die Anweisung 408 ausführen, um die Anfrage für die Benutzerrollenkonfiguration (die von dem AP, mit dem das Benutzergerät verbunden ist, empfangen wurde) durch den Cloud-basierten Rollenverwaltungsdienst zu authentifizieren. In einigen Beispielen kann die Authentifizierung/Überprüfung, dass die Anforderung der Benutzerrollenkonfiguration ordnungsgemäß ist, die Bestimmung der Quelle einer Anforderung und die Bestimmung, ob diese Quelle die angeforderte Benutzerrollenkonfiguration empfangen darf oder nicht, beinhalten. Auch hier können die Benutzerrollen je nach den Bedürfnissen/Wünschen der Kontrollinstanz(en) eines Netzes in Übereinstimmung mit der Netztopologie, - konfiguration usw. selektiv zugewiesen werden.
Der Hardware-Prozessor 402 kann die Anweisung 410 ausführen, um nach der Authentifizierung durch das Cloud-basierte Rollenverwaltungssystem dem anfordernden AP mit der angeforderten Benutzerrollenkonfiguration zu antworten. Das heißt, das Cloud-basierte Rollenverwaltungssystem kann über den Policy Manager 306 (3) die entsprechende Benutzerrollenkonfiguration/den entsprechenden Datensatz abrufen, den das Cloud-basierte Rollenverwaltungssystem dann an den anfordernden AP weiterleiten kann, so dass der anfordernde AP die Benutzerrollenkonfiguration/den Datensatz herunterladen kann. Der anfragende AP kann dann die heruntergeladene Benutzerrollenkonfiguration/den heruntergeladenen Datensatz auf das angeschlossene Benutzergerät anwenden.
Wie bereits erwähnt, wird das angeschlossene Benutzergerät in einen gesperrten Zustand versetzt und verbleibt dort, bis die Benutzerrollenkonfiguration/der Benutzerrollendatensatz empfangen und angewendet wird, so dass es keine Kommunikation/Daten senden oder empfangen kann. Sobald die Anforderung für die Benutzerrollenkonfiguration/den Datensatz authentifiziert, empfangen und angewendet wurde, kann der AP das Benutzergerät aus dem gesperrten Zustand in einen entsperrten Zustand versetzen. Wie bereits erwähnt, verbleibt das Benutzergerät im gesperrten Zustand, wenn die Anforderung der Benutzerrollenkonfiguration/des Benutzerrollendatensatzes ungültig oder anderweitig unzulässig ist, so dass kein weiterer Datenverkehr übertragen/empfangen werden kann.
Der Hardware-Prozessor 402 kann die Anweisung 412 ausführen, um die Benutzerrollenkonfiguration an einen AP zu verteilen, der dem anfordernden AP benachbart ist. Im Zusammenhang mit der Verteilung von Benutzerrollen kann eine AP-Nachbarschaftsbeziehung auf der Grundlage einer erfolgreichen Funkfrequenzkommunikation zwischen zwei APs definiert werden. Wenn ein AP die HF-Übertragungen eines anderen APs „hören“ kann, können die beiden APs als Nachbarn betrachtet werden. Genauer gesagt, wenn ein Zugangsberechtigter erfolgreich einen dem 802.11-Standard entsprechenden Frame eines anderen Zugangsberechtigten dekodieren kann, der an einer seiner Funkschnittstellen empfangen wird, sind sie Nachbarn. Wie oben beschrieben, kann der Cloud-basierte Rollenverwaltungsdienst nach Erhalt der angeforderten Benutzerrollenkonfiguration die Benutzerrollenkonfiguration an andere benachbarte Zugangsgeräte des anfordernden Zugangsgeräts weiterleiten oder verteilen. Um dies zu erreichen, kann der Cloud-basierte Rollenverwaltungsdienst auf einen Dienst/Mechanismus zurückgreifen, der Netzwerk-HF-Daten analysieren kann, um die Konfiguration des Netzwerks abzuleiten/zu optimieren. In einigen Beispielen kann der Netzwerkanalysemechanismus Cloud-basiert sein. Jeder AP in einem Netzwerk kann z. B. regelmäßig ein Scanning durchführen, indem er 802.11 Probe Request Frames auf HF-Kanälen sendet, auf denen APs arbeiten dürfen. Benachbarte APs antworten auf diese Anfragen mit 802.11 Probe Response Frames. Der AP, der den Scanvorgang durchführt, sammelt diese Probe-Responses in einem RF-Nachbarschaftsbericht und kann sie an den Cloudbasierten Netzwerkanalysedienst senden. Der Cloud-basierte Netzwerkanalysedienst kann dann den RF-Nachbarschaftsbericht von jedem AP analysieren und einen RF-Nachbarschaftsgraphen der APs erstellen. Anhand dieses Graphen kann der Cloud-basierte Netzwerkanalysedienst RF-Nachbarn für jeden einzelnen AP identifizieren. Der Cloud-basierte Rollenverwaltungsdienst kann diese Informationen über die identifizierten Nachbarn des anfragenden APs nutzen und die angeforderte Benutzerrollenkonfiguration an einen oder mehrere der benachbarten APs weiterleiten/verteilen. In einigen Beispielen kann diese Verteilung auch ein selektiver Prozess sein, bei dem einige APs, aber nicht alle benachbarten APs die Benutzerrollenkonfiguration erhalten. Zum Beispiel kann eine Gruppe von APs definiert oder gruppiert werden, um verteilte Benutzerrollenkonfigurationen zu erhalten. Alternativ kann auch eine andere Gemeinsamkeit die Grundlage für die Verteilung/Broadcasting einer Benutzerrollenkonfiguration sein, z.B. alle APs mit dem gleichen Site Label. Ein Standort kann sich auf einen physischen Ort beziehen, an dem eine Reihe von Geräten installiert ist, z. B. ein Campus, eine Niederlassung oder ein Veranstaltungsort. In einigen Ausführungsformen können Standorte als primäres Navigationselement verwendet werden. Wenn beispielsweise einige Geräte auf einem Campus installiert sind, kann ein Standort mit der Bezeichnung CampusA erstellt werden. Die Geräte innerhalb von CampusA können auch mit Etiketten versehen werden. Wenn der Campus, auf dem CampusA definiert ist, beispielsweise aus mehreren Gebäuden besteht, können die auf dem Campus eingesetzten Geräte als Gebäude1 oder Lobby bezeichnet werden. Wenn die Geräte an einem bestimmten Standort oder in einem Bereich innerhalb eines bestimmten Standorts eine ähnliche Konfiguration aufweisen müssen, können die Geräte in Gruppen zusammengefasst werden.
Es ist zu beachten, dass benachbarte APs nicht auf APs beschränkt sein müssen, die zum selben AP-Cluster gehören oder vom selben Management-VLAN verwaltet werden (im Gegensatz zu den oben beschriebenen konventionellen/traditionellen Benutzerrollenkonfigurationsmodellen/- mechanismen). Darüber hinaus vermeiden die Beispiele die traditionellen Einschränkungen der Verteilung der Benutzerrollenkonfiguration und sind in der Lage, eine effizientere Methode oder ein effizienteres Modell zu implementieren. Dies liegt daran, dass die Verteilung einer angeforderten Benutzerrollenkonfiguration/eines angeforderten Datensatzes in Bezug auf benachbarte APs und nicht auf alle APs eines bestimmten AP-Clusters erfolgt. Die Verteilung einer Benutzerrollenkonfiguration/eines Datensatzes kann weniger Zeit in Anspruch nehmen, und es können weniger Ressourcen für die Verteilung der Benutzerrollenkonfiguration/des Datensatzes verwendet/beansprucht werden. Wie bereits erwähnt, muss ein Zugangspunkt nicht mit einem anderen Netzwerkgerät (z. B. dem Cloud-basierten Rollenverwaltungsdienst) interagieren, um eine Benutzerrollenkonfiguration zu erhalten, die auf ein angeschlossenes Benutzergerät anzuwenden ist. Nach der Verteilung durch den anfragenden Zugangspunkt können benachbarte Zugangspunkte bereits über die Benutzerrollenkonfiguration/den Datensatz verfügen, falls das Benutzergerät anschließend zu einem oder mehreren solchen benachbarten Zugangspunkten roamt/andere Verbindungen herstellt/aufbaut.
4B ist ein Blockdiagramm einer beispielhaften Computerkomponente oder eines Geräts 450 zur Durchführung einer Cloudgesteuerten Benutzerrollenverwaltung gemäß einem anderen Beispiel. Bei der Rechnerkomponente 450 kann es sich beispielsweise um einen Controller, einen Prozessor oder eine andere ähnliche Rechnerkomponente handeln, die in der Lage ist, Daten zu verarbeiten, z. B. ein Benutzergeräteprozessor. In der Beispielimplementierung von 4B umfasst die Rechnerkomponente 450 einen Hardwareprozessor 452 und ein maschinenlesbares Speichermedium 454.
Bei dem Hardware-Prozessor 452 kann es sich um eine oder mehrere Zentraleinheiten (CPUs), halbleiterbasierte Mikroprozessoren und/oder andere Hardwarevorrichtungen handeln, die zum Abrufen und Ausführen von Anweisungen geeignet sind, die in dem maschinenlesbaren Speichermedium 454 gespeichert sind. Der Hardware-Prozessor 452 kann Befehle, wie die Befehle 456-460, abrufen, dekodieren und ausführen, um Prozesse oder Operationen zum Aufbau von Verbindungen, zur Synchronisierung und zur Veröffentlichung von Routen/Zuständen zu steuern. Alternativ oder zusätzlich zum Abrufen und Ausführen von Befehlen kann der Hardware-Prozessor 402 einen oder mehrere elektronische Schaltkreise enthalten, die elektronische Komponenten zur Ausführung der Funktionalität eines oder mehrerer Befehle umfassen, z. B. ein Field Programmable Gate Array (FPGA), einen anwendungsspezifischen integrierten Schaltkreis (ASIC) oder andere elektronische Schaltkreise.
Ein maschinenlesbares Speichermedium, wie das maschinenlesbare Speichermedium 454, kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät sein, das ausführbare Anweisungen enthält oder speichert. Bei dem maschinenlesbaren Speichermedium 454 kann es sich beispielsweise um einen Direktzugriffsspeicher (RAM), einen nichtflüchtigen RAM (NVRAM), einen elektrisch löschbaren, programmierbaren Festspeicher (EEPROM), ein Speichergerät, eine optische Platte oder Ähnliches handeln. In einigen Beispielen kann das maschinenlesbare Speichermedium 454 ein nicht-transitorisches Speichermedium sein, wobei der Begriff „nicht-transitorisch“ nicht die transitorischen Übertragungssignale umfasst. Wie nachstehend im Detail beschrieben, kann das maschinenlesbare Speichermedium 454 mit ausführbaren Befehlen kodiert sein, zum Beispiel mit den Befehlen 456-460.
Der Hardwareprozessor 452, bei dem es sich um einen Hardwareprozessor des Benutzergeräts handeln kann, kann die Anweisung 456 ausführen, um von einem AP, mit dem das Benutzergerät verbunden ist, die Anweisung zu empfangen, in einen gesperrten Zustand einzutreten, während er darauf wartet, dass ein Cloud-basierter Benutzerrollenverwaltungsdienst eine Benutzerrollenkonfigurationsanforderung vom AP authentifiziert, und in einen gesperrten Zustand einzutreten. Wie oben beschrieben, kann es einem Benutzergerät untersagt sein, Nachrichten/Kommunikationen zu senden/empfangen, während es sich in einem blockierten Zustand befindet. Dadurch wird Zeit gewonnen, damit die Anforderung zur Konfiguration der Benutzerrolle authentifiziert werden kann.
Der Hardware-Prozessor 452 kann die Anweisung 458 ausführen, um nach der Authentifizierung der Anforderung der Benutzerrollenkonfiguration vom AP die Anweisung zu erhalten, in einen entsperrten Zustand einzutreten. Dementsprechend kann das Benutzergerät in den entsperrten Zustand übergehen, wenn die angeforderte Benutzerrollenkonfiguration auf das Benutzergerät angewendet wird. Das heißt, sobald der AP in der Lage ist, den Verkehr zum/vom Benutzergerät auf der Grundlage der angeforderten Benutzerrollenkonfiguration zu steuern, weist der AP das Benutzergerät an, von seinem gesperrten Zustand in einen entsperrten Zustand überzugehen. Im entsperrten Zustand kann das Benutzergerät Verkehr empfangen/senden.
Wie bereits erwähnt, verbessern die Ausführungsformen die herkömmliche Verwaltung und Verteilung von Benutzerrollenkonfigurationen, indem sie die Verteilung von Benutzerrollenkonfigurationen an gewünschte Netzwerkgeräte wie z. B. APs ermöglichen. Da diese Verteilung durch einen Cloud-basierten Rollenverwaltungsdienst erfolgt, unterliegt sie nicht den Einschränkungen, die mit herkömmlichen Systemen und Mechanismen verbunden sind, wie z. B. über einen virtuellen Controller oder über Broadcasting. Vielmehr kann ein erster Zugangspunkt eine Benutzerrollenkonfiguration an einen anderen Zugangspunkt weitergeben, so dass die Benutzerrolle angewendet werden kann, wenn sich ein Benutzergerät später mit diesem anderen Zugangspunkt verbindet. Wie bereits erwähnt, ist die Verteilung nicht auf APs beschränkt, die sich im selben Cluster oder in derselben Filiale befinden. Zum Beispiel können benachbarte APs die angeforderte Benutzerrollenkonfiguration erhalten. Wie bereits erwähnt, können benachbarte APs in manchen Kontexten darauf basieren, dass ein AP den Funkverkehr eines anderen APs hört. In einigen Szenarien handelt es sich bei benachbarten APs um APs, mit denen sich ein Benutzergerät von einem anderen AP aus verbinden/assoziieren kann, unabhängig davon, ob die APs zum selben Cluster/Zweig gehören. Daher müssen die Beschränkungen typischer Modelle zur Verwaltung von Benutzerrollen nicht auf die offengelegten Ausführungsformen zutreffen.
5 zeigt ein Blockdiagramm eines Beispiel-Computersystems 500, in dem verschiedene der hier beschriebenen Beispiele implementiert werden können. Das Computersystem 500 kann einen Bus 502 oder einen anderen Kommunikationsmechanismus zur Übermittlung von Informationen sowie einen oder mehrere mit dem Bus 502 gekoppelte Hardware-Prozessoren 504 zur Verarbeitung von Informationen umfassen. Bei dem/den Hardware-Prozessor(en) 504 kann es sich z. B. um einen oder mehrere Allzweck-Mikroprozessoren handeln. Die vorgenannten Komponenten/Einheiten, wie z. B. der Benutzerrollendienst 330, der Richtlinienmanager 306, das Netzwerkgerät 302X usw., können Implementierungen oder Beispiele des Computersystems 500 sein.
Das Computersystem 500 kann Speichereinheiten enthalten, wie z. B. einen Hauptspeicher 506, wie z. B. einen Direktzugriffsspeicher (RAM), einen Cache und/oder andere dynamische Speichergeräte, die mit dem Bus 502 verbunden sind, um Informationen und Befehle zu speichern, die vom Prozessor 504 ausgeführt werden sollen. Der Hauptspeicher 506 kann auch zum Speichern temporärer Variablen oder anderer Zwischeninformationen während der Ausführung von Befehlen verwendet werden, die vom Prozessor 504 ausgeführt werden sollen. Wenn solche Befehle in Speichermedien gespeichert werden, auf die der Prozessor 504 zugreifen kann, wird das Computersystem 500 zu einer Spezialmaschine, die so angepasst ist, dass sie die in den Befehlen angegebenen Operationen ausführen kann.
Das Computersystem 500 kann außerdem einen Festwertspeicher (ROM) 508 oder ein anderes statisches Speichergerät enthalten, das mit dem Bus 502 verbunden ist, um statische Informationen und Anweisungen für den Prozessor 504 zu speichern. Ein Speichergerät 510, wie z. B. eine Magnetplatte, eine optische Platte oder ein USB-Stick (Flash-Laufwerk) usw., kann vorgesehen und mit dem Bus 502 verbunden sein, um Informationen und Anweisungen zu speichern.
Im Allgemeinen kann sich der hier verwendete Begriff „Engine“, „Komponente“, „System“, „Datenbank“ und dergleichen auf eine in Hardware oder Firmware verkörperte Logik oder auf eine Sammlung von Softwareanweisungen beziehen, die möglicherweise Ein- und Ausstiegspunkte haben und in einer Programmiersprache wie z. B. Java, C oder C++ geschrieben sind. Eine Softwarekomponente kann kompiliert und zu einem ausführbaren Programm verknüpft werden, in einer dynamischen Link-Bibliothek installiert werden oder in einer interpretierten Programmiersprache wie BASIC, Perl oder Python geschrieben sein. Es versteht sich von selbst, dass Softwarekomponenten von anderen Komponenten oder von sich selbst aus aufrufbar sein können und/oder als Reaktion auf erkannte Ereignisse oder Unterbrechungen aufgerufen werden können. Softwarekomponenten, die für die Ausführung auf Computergeräten konfiguriert sind, können auf einem computerlesbaren Medium, wie z. B. einer Compact Disc, einer digitalen Videodisc, einem Flash-Laufwerk, einer Magnetplatte oder einem anderen greifbaren Medium, oder als digitaler Download bereitgestellt werden (und können ursprünglich in einem komprimierten oder installierbaren Format gespeichert sein, das vor der Ausführung installiert, dekomprimiert oder entschlüsselt werden muss). Ein solcher Softwarecode kann teilweise oder vollständig in einem Speicher des ausführenden Computergeräts gespeichert werden, damit er von dem Computergerät ausgeführt werden kann. Softwareanweisungen können in Firmware, wie z. B. einem EPROM, eingebettet sein. Darüber hinaus können die Hardwarekomponenten aus verbundenen Logikeinheiten wie Gattern und Flipflops und/oder aus programmierbaren Einheiten wie programmierbaren Gatteranordnungen oder Prozessoren bestehen.
Das Computersystem 500 kann die hier beschriebenen Techniken unter Verwendung von kundenspezifischer festverdrahteter Logik, einem oder mehreren ASICs oder FPGAs, Firmware und/oder Programmlogik implementieren, die in Kombination mit dem Computersystem das Computersystem 500 zu einer Spezialmaschine macht oder programmiert. Einem Beispiel zufolge werden die hierin beschriebenen Techniken vom Computersystem 500 als Reaktion auf den/die Prozessor(en) 504 ausgeführt, der/die eine oder mehrere Sequenzen von einem oder mehreren im Hauptspeicher 506 enthaltenen Befehlen ausführt/ausführen. Solche Anweisungen können in den Hauptspeicher 506 von einem anderen Speichermedium, wie z. B. einem Speichergerät 510, eingelesen werden. Die Ausführung der im Hauptspeicher 506 enthaltenen Befehlssequenzen veranlasst den/die Prozessor(en) 504, die hier beschriebenen Prozessschritte durchzuführen. In alternativen Beispielen können fest verdrahtete Schaltungen anstelle von oder in Kombination mit Softwareanweisungen verwendet werden.
Der Begriff „nichtflüchtige Medien“ und ähnliche Begriffe, wie sie hier verwendet werden, beziehen sich auf alle Medien, die Daten und/oder Befehle speichern, die den Betrieb einer Maschine in einer bestimmten Weise bewirken. Solche nichtflüchtigen Medien können nichtflüchtige Medien und/oder flüchtige Medien umfassen. Zu den nichtflüchtigen Medien gehören beispielsweise optische oder magnetische Festplatten, wie die Speichervorrichtung 510. Zu den flüchtigen Medien gehören dynamische Speicher, wie der Hauptspeicher 506. Zu den gängigen Formen nichtflüchtiger Medien gehören beispielsweise Disketten, flexible Platten, Festplatten, Solid-State-Laufwerke, Magnetbänder oder andere magnetische Datenspeichermedien, CD-ROMs, andere optische Datenspeichermedien, physische Medien mit Lochmustern, RAM, PROM und EPROM, FLASH-EPROM, NVRAM, andere Speicherchips oder -kassetten sowie deren vernetzte Versionen.
Nicht-transitorische Medien unterscheiden sich von Übertragungsmedien, können aber in Verbindung mit ihnen verwendet werden. Übertragungsmedien sind an der Übertragung von Informationen zwischen nichttransitorischen Medien beteiligt. Zu den Übertragungsmedien gehören z. B. Koaxialkabel, Kupfer- und Glasfaserkabel, einschließlich der Drähte, aus denen der Bus 502 besteht. Übertragungsmedien können auch in Form von Schall- oder Lichtwellen auftreten, wie sie bei der Datenkommunikation über Funk und Infrarot erzeugt werden.
Das Computersystem 500 umfasst auch eine Kommunikations-/Netzwerkschnittstelle 518, die mit dem Bus 502 verbunden ist. Die Kommunikationsschnittstelle 518 stellt eine Zwei-Wege-Datenkommunikationsverbindung zu einer oder mehreren Netzwerkverbindungen her, die mit einem oder mehreren lokalen Netzwerken verbunden sind. Bei der Kommunikationsschnittstelle 518 kann es sich beispielsweise um eine ISDN-Karte (Integrated Services Digital Network), ein Kabelmodem, ein Satellitenmodem oder ein Modem handeln, um eine Datenkommunikationsverbindung zu einer entsprechenden Art von Telefonleitung herzustellen. Als weiteres Beispiel kann die Kommunikationsschnittstelle 518 eine LAN-Karte sein, um eine Datenkommunikationsverbindung zu einem kompatiblen LAN (oder einer WAN-Komponente zur Kommunikation mit einem WAN) herzustellen. Es können auch drahtlose Verbindungen implementiert werden. In jeder dieser Implementierungen sendet und empfängt die Kommunikationsschnittstelle 518 elektrische, elektromagnetische oder optische Signale, die digitale Datenströme übertragen, die verschiedene Arten von Informationen darstellen.
Eine Netzverbindung ermöglicht in der Regel die Datenkommunikation über ein oder mehrere Netze zu anderen Datengeräten. Eine Netzverbindung kann beispielsweise eine Verbindung über ein lokales Netz zu einem Host-Computer oder zu Datengeräten herstellen, die von einem Internetdienstanbieter (ISP) betrieben werden. Der ISP wiederum bietet Datenkommunikationsdienste über das weltweite Paketdatenkommunikationsnetz an, das heute gemeinhin als „Internet“ bezeichnet wird. Sowohl das lokale Netz als auch das Internet verwenden elektrische, elektromagnetische oder optische Signale, die digitale Datenströme übertragen. Die Signale über die verschiedenen Netze und die Signale auf der Netzverbindung und über die Kommunikationsschnittstelle 518, die die digitalen Daten zum und vom Computersystem 500 übertragen, sind Beispiele für Übertragungsmedien.
Das Computersystem 500 kann über das/die Netzwerk(e), die Netzwerkverbindung und die Kommunikationsschnittstelle 518 Nachrichten senden und Daten, einschließlich Programmcode, empfangen. In dem Internet-Beispiel könnte ein Server einen angeforderten Code für ein Anwendungsprogramm über das Internet, den ISP, das lokale Netzwerk und die Kommunikationsschnittstelle 518 übertragen.
Wie hierin verwendet, kann der Begriff „oder“ sowohl im einschließenden als auch im ausschließenden Sinne verstanden werden. Darüber hinaus ist die Beschreibung von Ressourcen, Vorgängen oder Strukturen im Singular nicht so zu verstehen, dass der Plural ausgeschlossen wird. Bedingte Ausdrücke, wie z. B. „kann“, „könnte“, „könnte“ oder „darf“, sind, sofern nicht ausdrücklich anders angegeben oder im jeweiligen Kontext anders zu verstehen, im Allgemeinen so zu verstehen, dass bestimmte Beispiele bestimmte Merkmale, Elemente und/oder Schritte einschließen, während andere Beispiele diese nicht einschließen. Die in diesem Dokument verwendeten Begriffe und Ausdrücke sowie deren Variationen sind, sofern nicht ausdrücklich anders angegeben, nicht als einschränkend, sondern als offen zu verstehen. Als Beispiele für das Vorstehende ist der Begriff „einschließlich“ im Sinne von „einschließlich, ohne Einschränkung“ oder dergleichen zu verstehen. Der Begriff „Beispiel“ wird verwendet, um exemplarische Beispiele für den Gegenstand der Diskussion zu geben, nicht um eine erschöpfende oder einschränkende Liste zu erstellen. Die Begriffe „ein“ oder „ein“ sind im Sinne von „mindestens ein“, „ein oder mehrere“ oder ähnlich zu verstehen. Das Vorhandensein von erweiternden Wörtern und Ausdrücken wie „einer oder mehrere“, „mindestens“, „aber nicht beschränkt auf“ oder ähnlichen Ausdrücken in einigen Fällen ist nicht so zu verstehen, dass der engere Fall beabsichtigt oder erforderlich ist, wenn solche erweiternden Ausdrücke nicht vorhanden sind.

Claims

Ein System, das Folgendes umfasst: einen Prozessor; und einen Speicher, der operativ mit dem Prozessor verbunden ist, wobei der Speicher Befehle enthält, die, wenn sie ausgeführt werden, den Prozessor veranlassen,: von einem Netzwerkgerät eine Anforderung für eine Benutzerrollenkonfiguration empfangen; die Anfrage für die Benutzerrollenkonfiguration authentifizieren; nach der Authentifizierung dem anfordernden Netzwerkgerät mit der angeforderten Benutzerrollenkonfiguration antworten; und die Benutzerrollenkonfiguration an ein anderes, dem anfragenden Netzwerkgerät benachbartes Netzwerkgerät zu verteilen.
Das System nach Anspruch 1, wobei die Anweisungen einen Cloudbasierten Rollenverwaltungsdienst bewirken.
Das System nach Anspruch 1, wobei das Netzwerkgerät ein Gerät umfasst, das in der Lage ist, die Benutzerrollenkonfiguration durchzusetzen.
Das System nach Anspruch 1, wobei das Netzwerkgerät einen Zugangspunkt umfasst.
Das System nach Anspruch 1, wobei die Anweisungen, die, wenn sie ausgeführt werden, den Prozessor ferner veranlassen, zu bestimmen, dass eine Quelle der Anforderung berechtigt ist, die angeforderte Benutzerrollenkonfiguration zu empfangen, wobei die Quelle der Anforderung das Netzwerkgerät umfasst.
Das System nach Anspruch 1, wobei der Speicher weitere Anweisungen enthält, die, wenn sie ausgeführt werden, eine Benutzervorrichtung authentifizieren, wenn sich die Benutzervorrichtung mit der Netzwerkvorrichtung verbindet.
Das System nach Anspruch 6, wobei die Authentifizierung des Benutzergeräts auf mindestens einem der Anmeldeinformationen basiert, die das Benutzergerät oder eine Gruppe von Netzwerkgeräten identifizieren, zu der das Benutzergerät gehört.
Das System nach Anspruch 6, wobei der Speicher weitere Anweisungen enthält, die, wenn sie ausgeführt werden, den Prozessor veranlassen, die angeforderte Benutzerrollenkonfiguration auf das Benutzergerät anzuwenden.
Das System nach Anspruch 8, wobei der Speicher weitere Anweisungen enthält, die, wenn sie ausgeführt werden, den Prozessor veranlassen, das Benutzergerät in einen blockierten Zustand zu versetzen, bevor das Benutzergerät authentifiziert wird und bevor die angeforderte Benutzerrollenkonfiguration auf das Benutzergerät angewendet wird.
Das System nach Anspruch 9, wobei der Speicher weitere Anweisungen enthält, die, wenn sie ausgeführt werden, den Prozessor veranlassen, das Benutzergerät in einen entsperrten Zustand zu versetzen, wenn die angeforderte Benutzerrollenkonfiguration auf das Benutzergerät angewendet wird.
Das System nach Anspruch 1, wobei der Speicher weitere Anweisungen enthält, die, wenn sie ausgeführt werden, den Prozessor veranlassen, das andere benachbarte Netzwerkgerät auf der Grundlage einer Funkfrequenzanalyse von Netzwerkgeräten auszuwählen.
Ein Verfahren, das Folgendes umfasst: Empfangen einer Anforderung von einem Zugangspunkt für eine Benutzerrollenkonfiguration, die Richtlinien spezifiziert, die für den Benutzerverkehr gelten, der den Zugangspunkt durchläuft; die Authentifizierung der Anfrage für die Benutzerrollenkonfiguration; nach der Authentifizierung dem anfordernden Zugangspunkt mit der angeforderten Benutzerrollenkonfiguration antworten; und Verteilung der Benutzerrollenkonfiguration an einen anderen Zugangspunkt in der Nähe des anfordernden Zugangspunkts.
Das Verfahren nach Anspruch 12, wobei der andere benachbarte Zugangspunkt Teil desselben virtuellen lokalen Zugangsnetzes ist, zu dem der anfordernde Zugangspunkt gehört.
Das Verfahren nach Anspruch 12, wobei der andere benachbarte Zugangspunkt Teil eines anderen virtuellen lokalen Zugangsnetzes ist als das, zu dem der anfordernde Zugangspunkt gehört.
Das Verfahren nach Anspruch 12, das ferner umfasst, dass ein mit dem anfordernden Zugangspunkt verbundenes Benutzergerät in einen blockierten Zustand versetzt wird, während die Anforderung der Benutzerrollenkonfiguration authentifiziert wird.
Das Verfahren nach Anspruch 15, das ferner umfasst, dass das Benutzergerät in einen entsperrten Zustand versetzt wird, wenn die angeforderte Benutzerrollenkonfiguration auf das Benutzergerät angewendet wird, nachdem die Anforderung für die Benutzerrollenkonfiguration authentifiziert wurde.
Ein Benutzergerät, das Folgendes umfasst: einen Prozessor; und einen Speicher, der operativ mit dem Prozessor verbunden ist, wobei der Speicher Befehle enthält, die, wenn sie ausgeführt werden, den Prozessor veranlassen,: in einen blockierten Zustand eintreten, während sie darauf wartet, dass ein Cloud-basierter Benutzerrollenverwaltungsdienst eine Benutzerrollenkonfigurationsanforderung von einem ersten Netzwerkgerät, dem das Benutzergerät zugeordnet ist, authentifiziert; nach der Authentifizierung der Anforderung der Benutzerrollenkonfiguration in einen entsperrten Zustand eintreten, der sich aus der Anwendung der angeforderten Benutzerrollenkonfiguration auf das Benutzergerät durch das erste Netzwerkgerät ergibt; beim Verbinden mit einem zweiten Netzwerkgerät die Kommunikation in Übereinstimmung mit der angeforderten Benutzerrollenkonfiguration durchzuführen, wobei die angeforderte Benutzerrollenkonfiguration durch das zweite Netzwerkgerät auf das Benutzergerät angewendet wird, wobei das zweite Netzwerkgerät die angeforderte Benutzerrollenkonfiguration über die Verteilung durch den Cloudbasierten Benutzerrollenverwaltungsdienst vor dem Verbinden des Benutzergeräts mit dem zweiten Netzwerkgerät erhalten hat.
Das Benutzergerät nach Anspruch 17, wobei alle Kommunikationen zu und von dem Benutzergerät verboten sind, während es sich im blockierten Zustand befindet.
Das Benutzergerät nach Anspruch 17, wobei die Authentifizierung der Benutzerrollenkonfigurationsanforderung auf Identifizierungsinformationen basiert, die einen Benutzergerätedatensatz mit einem Benutzerdatensatz und einem Benutzerrollendatensatz verknüpfen.
Das Benutzergerät nach Anspruch 17, wobei dem Benutzergerät eine Benutzerrolle zugewiesen wird, die der angeforderten Benutzerrollenkonfiguration entspricht, bevor die Benutzerrollenkonfiguration durch das erste Netzwerkgerät auf das Benutzergerät angewendet wird.