Dynamische Cacheobjekte für OAuth
Die OAuth-Unterstützung von WebSphere Application Server stellt zwei Optionen für die OAuth-Token- und -Clientpersistenz bereit: speicherintern und Datenbank.
Bei Verwendung der speicherinternen Clients und Token sind die Clients im Dateisystem persistent definiert und die Token verbleiben im Speicher. MBean-Schnittstellen sind verfügbar, um Clients hinzuzufügen und zu entfernen, und sie synchronisieren Änderungen in einem Cluster und definieren die Änderungen im Dateisystem als persistent. Die Token werden über dynamische Cacheobjekte oder speicherinterne Hashtabellen verwaltet, wenn kein dynamischer Cache angegeben ist.
In der Datenbankimplementierung werden ebenfalls dynamische Cacheobjekte verwendet, um die Datenbankpersistenz für die Clienttabelle und für die Tokentabelle zu unterstützen. Normalerweise ist der Cache, der die Datenbank unterstützt, eine schwache Hashtabelle (weak hashmap), die auf der LRU-Richtlinie (Least-Recently-Used) basiert. Werden in den Caches Daten gefunden, werden diese verwendet. Dadurch werden Datenbankabfragen nach häufig verwendeten Daten vermieden, und die Leistung wird verbessert. Wird für die Datenbank kein dynamischer Cache angegeben, wird stattdessen eine lokale speicherinterne Hashtabelle verwendet.
Für OAuth-Umgebungen, die keine Clusterumgebungen sind, ist die Konfiguration eines dynamischen Cache nicht erforderlich.
Standardeinstellungen
Dynamische Cacheobjekte sind in hohem Maße konfigurierbar und optimierbar, um die Leistung zu maximieren. Standardmäßig erstellt der OAuth-Service in den meisten Umgebungen Instanzen des dynamischen Cach mit angemessenen Standarwerten.
cache.instance.0=/services/cache/OAuth20MemTokenCache
cache.instance.0.cacheSize=1000
cache.instance.0.enableDiskOffload=true
cache.instance.0.flushToDiskOnStop=true
cache.instance.0.useListenerContext=false
cache.instance.0.enableCacheReplication=true
cache.instance.0.replicationDomain=DynaCacheCluster
cache.instance.1=/services/cache/OAuth20MemTokenOwnerCache
cache.instance.1.cacheSize=1000
cache.instance.1.enableDiskOffload=true
cache.instance.1.flushToDiskOnStop=true
cache.instance.1.useListenerContext=false
cache.instance.1.enableCacheReplication=true
cache.instance.1.replicationDomain=DynaCacheCluster
cache.instance.2=/services/cache/OAuth20DBTokenCache
cache.instance.2.cacheSize=1000
cache.instance.2.enableDiskOffload=false
cache.instance.2.flushToDiskOnStop=false
cache.instance.2.useListenerContext=false
cache.instance.2.enableCacheReplication=true
cache.instance.2.replicationDomain=DynaCacheCluster
cache.instance.3=/services/cache/OAuth20DBClientCache
cache.instance.3.cacheSize=1000
cache.instance.3.enableDiskOffload=false
cache.instance.3.flushToDiskOnStop=false
cache.instance.3.useListenerContext=false
cache.instance.3.enableCacheReplication=true
cache.instance.3.replicationDomain=DynaCacheCluster
Damit diese Caches in einem Cluster ordnungsgemäß verwendet werden, müssen die Clusterknoten für die Verwendung einer Replikationsdomäne mit dem Namen DynaCacheCluster konfiguriert sein. Außer dem Festlegen der Replikationsdomäne ist keine weitere Konfiguration erforderlich.
Erweiterte Konfiguration
Es kann nur eine Replikationsdomäne pro Knoten angegeben werden. Für Clusterknoten, für die bereits eine Replikationsdomäne konfiguriert ist, ist eine erweiterte Konfiguration erforderlich, damit dynamische Cacheobjekte für die vorhandene Replikationsdomäne erstellt werden können. Für Umgebungen, die optimierte dynamische Cacheobjekte verwenden, beispielsweise um die Cachegröße zu erhöhen, muss ebenfalls die erweiterte Konfiguration verwendet werden.
- Erstellen Sie die Instanzen des dynamischen Cache in der Umgebung von WebSphere Application Server. Einzelheiten zu den speziellen Optionen finden Sie in der vorhandenen Dokumentation zu dynamischen Cacheobjekten. Die vorher gezeigten Standardwerte können als Einstieg verwendet werden. Der Name der Replikationsdomäne ist besonders wichtig, weil er mit dem Namen der Replikationsdomäne für die Umgebungen übereinstimmen muss, in denen bereits eine Replikationsdomäne definiert ist.
- Modifizieren Sie die
OAuth-Providerkonfigurationseinstellungen für die JNDI-Namen
(Java™ Naming and Directory Interface) der neuen dynamischen Cacheobjekte.
- Bei Verwendung der speicherinternen Persistenz lauten die Parameternamen wie folgt:
undoauth20.token.cache.jndi.tokens
oauth20.token.cache.jndi.users
- Bei Verwendung der Datenbankpersistenz lauten die Parameternamen wie folgt:
undoauth20.db.token.cache.jndi.tokens
oauth20.db.token.cache.jndi.clients
- Bei Verwendung der speicherinternen Persistenz lauten die Parameternamen wie folgt:
Werden die dynamischen Cacheobjekte falsch konfiguriert, werden sie durch die lokalen speicherinternen Hashtabellen ersetzt. Die Hashtabellen bieten eine Leistungssteigerung, allerdings werden die Daten in den Knoten eines Clusters nicht repliziert. Dies ist wichtig für die Cacheinvalidierung. Beispielsweise können Benutzer, die ihre OAuth-Token in einer falsch konfigurierten Umgebung widerrufen, weiterhin auf ihre OAuth-Token auf anderen Knoten zugreifen, bis das Token abläuft.
In Umgebungen, in denen kein Tokenwiderruf zulässig ist, oder Umgebungen, in denen während der Lebensdauer der Token eine Tokeninkonsistenz zulässig ist, besteht auch die Möglichkeit, das dynamische Caching oder die Cacheinvalidierung zu inaktivieren. Durch Inaktivieren des dynamischen Caching wird die Leistung auf Kosten längerer Zugriffszeit weiter erhöht.