MétaCan
Menu
Retour à la cohorte
Enregistrement W207420180

Using Kerberos to provide secure authentication for DB2

2011· article· en· W207420180 sur OpenAlex

Pourquoi ce travail est dans la base

Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.

affAu moins un auteur déclare une institution canadienne dans l'instantané OpenAlex épinglé.

Notice bibliographique

RevueConference of the Centre for Advanced Studies on Collaborative Research · 2011
Typearticle
Langueen
DomaineDecision Sciences
ThématiqueBig Data Technologies and Applications
Établissements canadiensIBM (Canada)
Organismes subventionnairesnon disponible
Mots-clésKerberosComputer securityComputer scienceAuthentication (law)Authentication protocolSingle sign-onPassword
DOInon disponible

Résumé

récupéré en direct d'OpenAlex

During your average day, how many times do you need to type in a username and password? It's common for this to be at least a dozen times, and quite often many more. Wouldn't you prefer to do it only once, when you log into your operating system? This goal is known as single sign-on, a method where a person must only provide authenticating credentials once, and be able to gain access to multiple independent systems in a highly secure manner. Kerberos is the premier technology used to provide single sign-on. The Kerberos protocol, based around a trusted third party and ticket service, is highly robust and efficient. Its use of strong encryption provides a secure method of authentication over an insecure network. As a kerberized application, DB2 uses Kerberos to provide secure authentication. Developed by the Massachusetts Institute of Technology (MIT), Kerberos is a reference to the three-headed dog named Cerberus that guarded that gates of Hades in ancient Greek mythology. Cerberus, a vicious monster by all accounts, was responsible for ensuring only the souls of people who had died could enter Hades, and that no one could leave. Certainly very vivid imagery for an authentication system. The modern day Kerberos authentication protocol provides a similar level of security, ensuring that clients can authenticate themselves securely to a server or an insecure network, as well as providing options for data integrity and data privacy of any messages exchanged. So not only is Cerberus guarding the gate, it's making sure no one eavesdrops on conversations. A trusted third party, named the Key Distribution Center (KDC) forms the basis of the Kerberos protocol. The KDC shares the encryption keys for all principals making use of Kerberos. One non-traditional aspect of Kerberos is the principal, which is the identity that is either requesting or accepting connections to/from others. Thus servers also have identities and are referenced by their principal name. When a client logs into Kerberos, it contacts the KDC requesting a special ticket called a ticket-granting ticket (TGT). Clients authenticate themselves to servers by requesting a service ticket from the KDC, utilizing the TGT previously obtained. The client then passes this ticket to the server as proof of its identity. The server receives the ticket, examines the contents, and based on its trust of the KDC, knows who the client is. All tickets are encrypted with the keys for the appropriate principal so that they can not be tampered with. Tickets have limited lifetimes and Kerberos contains measures to prevent tickets from being re-used. In addition, Kerberos supports mutual authentication whereby a server proves its identity to a client by returning its own ticket to the client. The client is then assured the other end of the communication pipe is who it thinks it is talking to and not someone masquerading as the server. The use of encrypted tickets provides one of the fundamental strengths of the Kerberos protocol, that passwords are never sent over the network or placed in a ticket during day-to-day use. The KDC knows the users password, as does the user, but Kerberos does not require the password to be sent on the network, and there is never a chance for it to fall into the wrong hands or be exposed. The use of encrypted tickets also provides a highly efficient workflow. The KDC does not need to remember state information about which clients are connecting to which servers, or which clients have logged in. It merely examines the contents of the encrypted tickets to make a decision as to whether or not the client has proven its identity or that it should be able to connect to a server. As the KDC is a single-point of failure for all authentication, this simplified protocol allows for a very robust and fast service, critical for any enterprise environment. Kerberos has been the authentication mechanism used for Microsoft Windows since Windows 2000. Every Windows Active Directory is also a fully functioning Kerberos KDC. Every major UNIX/Linux provider supports Kerberos, often based on the MIT reference code. There is no doubt that Kerberos is an enterprise level authentication solution. Kerberos is governed by several standards, including RFC-1510 describing the protocol, and RFC-1964 describing the GSS-API (Generic Security Services API) implementation. The MIT Kerberos Consortium is a guiding body consisting of a mix of academia and large corporations that guide the current development of Kerberos. With on-going code updates, conferences and RFC updates, Kerberos is a modern and effective authentication solution. DB2 is an enterprise relational database management system. As a client-server product, DB2 is kerberized, meaning that it supports Kerberos as an authentication mechanism. DB2 integrates with the implementation of Kerberos provided by the operating system. DB2 supports cross-platform, cross-realm authentication using Kerberos to provide highly secure single sign-on capability. Kerberos support in DB2 is implemented through client and server security plugins that are accessed through the GSS-API interface. This plugin infrastructure, along with a sample Kerberos plugin, has allowed users to customize the plugin to suite their own Kerberos infrastructure.

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.

Prédiction distillée sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.

score de la tête « metaresearch » (Codex)0,002
score de la tête « metaresearch » (Gemma)0,024
Version: codex-gemma-dda1882f352aStatut de validation: machine_predicted_unvalidated
Catégories candidatesMétarecherche
Catégories consensuellesaucune
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Théorique ou conceptuel · Signal consensuel: Théorique ou conceptuel
GenreSignal candidat: Empirique · Signal consensuel: Empirique
Score de désaccord entre enseignants0,425
Score d'incertitude au seuil0,984

Scores Codex et Gemma par catégorie

CatégorieCodexGemma
Métarecherche0,0020,024
Méta-épidémiologie (sens strict)0,0000,000
Méta-épidémiologie (sens large)0,0000,000
Bibliométrie0,0000,002
Études des sciences et des technologies0,0010,001
Communication savante0,0000,000
Science ouverte0,0020,001
Intégrité de la recherche0,0000,000
Charge utile insuffisante (le modèle a refusé de juger)0,0000,000

Scores machine (provisoires)

Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.

Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.

Tête enseignante Opus0,791
Tête enseignante GPT0,557
Écart entre enseignants0,233 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle