Un guide sur l'API Java GSS

Haut Java

Je viens d'annoncer le nouveau cours Learn Spring , axé sur les principes de base de Spring 5 et Spring Boot 2:

>> VOIR LE COURS

1. Vue d'ensemble

Dans ce tutoriel, nous allons comprendre l'API Generic Security Service (API GSS) et comment nous pouvons l'implémenter en Java. Nous verrons comment sécuriser la communication réseau à l'aide de l'API GSS en Java.

Au cours du processus, nous créerons des composants client et serveur simples, en les sécurisant avec l'API GSS.

2. Qu'est-ce que l' API GSS ?

Alors, qu'est-ce que l'API Generic Security Service? L'API GSS fournit un cadre générique permettant aux applications d'utiliser différents mécanismes de sécurité tels que Kerberos , NTLM et SPNEGO de manière enfichable. Par conséquent, il aide les applications à se dissocier directement des mécanismes de sécurité.

Pour clarifier, la sécurité englobe ici l' authentification, l'intégrité des données et la confidentialité.

2.1. Pourquoi avons-nous besoin de l' API GSS ?

Les mécanismes de sécurité tels que Kerberos, NTLM et Digest-MD5 sont assez différents dans leurs capacités et leurs implémentations. En règle générale, une application prenant en charge l'un de ces mécanismes trouve assez décourageant de passer à un autre.

C'est là qu'un cadre générique comme l'API GSS fournit aux applications une abstraction . Par conséquent, les applications utilisant l'API GSS peuvent négocier un mécanisme de sécurité approprié et l'utiliser pour la communication. Tout cela sans avoir à implémenter de détails spécifiques au mécanisme.

2.2. Comment fonctionne l' API GSS ?

L'API GSS est un mécanisme basé sur des jetons . Cela fonctionne par l'échange de jetons de sécurité entre pairs . Cet échange se produit généralement sur un réseau, mais l'API GSS est indépendante de ces détails.

Ces jetons sont générés et traités par les implémentations spécifiques de l'API GSS. La syntaxe et la sémantique de ces tokens sont spécifiques au mécanisme de sécurité négocié entre les pairs:

Le thème central de l'API GSS tourne autour d'un contexte de sécurité. Nous pouvons établir ce contexte entre pairs grâce à l'échange de jetons. Nous pouvons avoir besoin de plusieurs échanges de jetons entre pairs pour établir le contexte.

Une fois établi avec succès aux deux extrémités, nous pouvons utiliser le contexte de sécurité pour échanger des données en toute sécurité. Cela peut inclure des contrôles d'intégrité des données et le chiffrement des données, selon le mécanisme de sécurité sous-jacent.

3. Prise en charge de l'API GSS en Java

Java prend en charge l'API GSS dans le cadre du package «org.ietf.jgss». Le nom du paquet peut sembler étrange. En effet, les liaisons Java pour l'API GSS sont définies dans une spécification IETF . La spécification elle-même est indépendante du mécanisme de sécurité.

L'un des mécanismes de sécurité les plus courants pour Java GSS est Kerberos v5.

3.1. API Java GSS

Essayons de comprendre certaines des principales API qui construisent Java GSS:

  • GSSContext encapsule le contexte de sécurité de l'API GSS et fournit des services disponibles dans le contexte
  • GSSCredential encapsule les informations d'identification de l'API GSS pour une entité qui est nécessaire pour établir le contexte de sécurité
  • GSSName encapsule l'entité principale de l'API GSS qui fournit une abstraction pour différents espaces de noms utilisés par les mécanismes sous-jacents

En dehors des interfaces ci-dessus, il y a peu d'autres classes importantes à noter:

  • GSSManager sert de classe d'usine pour d'autres classes d'API GSS importantes telles que GSSName , GSSCredential et GSSContext
  • Oid représente les identificateurs d'objets universels (OID) qui sont des identificateurs hiérarchiques utilisés dans l'API GSS pour identifier les mécanismes et les formats de nom
  • MessageProp encapsule les propriétés pour indiquer GSSContext sur des éléments tels que la qualité de protection (QoP) et la confidentialité pour l'échange de données
  • ChannelBinding encapsule les informations facultatives de liaison de canal utilisées pour renforcer la qualité avec laquelle l'authentification d'entité homologue est fournie

3.2. Fournisseur de sécurité Java GSS

Bien que Java GSS définisse le cadre de base pour l'implémentation de l'API GSS en Java, il ne fournit pas d'implémentation. Java adopte des implémentations enfichables basées sur le fournisseur pour les services de sécurité, y compris Java GSS.

Il peut y avoir un ou plusieurs de ces fournisseurs de sécurité enregistrés auprès de Java Cryptography Architecture (JCA). Chaque fournisseur de sécurité peut implémenter un ou plusieurs services de sécurité, comme Java GSSAPI et les mécanismes de sécurité en dessous.

Il existe un fournisseur GSS par défaut fourni avec le JDK. Cependant, il existe d'autres fournisseurs GSS spécifiques aux fournisseurs avec différents mécanismes de sécurité que nous pouvons utiliser. L'un de ces fournisseurs est IBM Java GSS. Nous devons enregistrer un tel fournisseur de sécurité auprès de JCA pour pouvoir les utiliser.

De plus, si nécessaire, nous pouvons implémenter notre propre fournisseur de sécurité avec éventuellement des mécanismes de sécurité personnalisés . Cependant, cela n'est guère nécessaire dans la pratique.

4. API GSS à travers un exemple

Maintenant, nous allons voir Java GSS en action à travers un exemple. Nous allons créer une application client et serveur simple. Le client est plus communément appelé initiateur et serveur comme accepteur dans GSS. Nous utiliserons Java GSS et Kerberos v5 ci-dessous pour l'authentification.

4.1. Contexte GSS pour le client et le serveur

Pour commencer, nous devrons établir un GSSContext , à la fois côté serveur et côté client de l'application.

Voyons d'abord comment nous pouvons le faire côté client:

GSSManager manager = GSSManager.getInstance(); String serverPrinciple = "HTTP/[email protected]"; GSSName serverName = manager.createName(serverPrinciple, null); Oid krb5Oid = new Oid("1.2.840.113554.1.2.2"); GSSContext clientContext = manager.createContext( serverName, krb5Oid, (GSSCredential)null, GSSContext.DEFAULT_LIFETIME); clientContext.requestMutualAuth(true); clientContext.requestConf(true); clientContext.requestInteg(true);

Il se passe pas mal de choses ici, décomposons-les:

  • Nous commençons par créer une instance du GSSManager
  • Ensuite, nous utilisons cette instance pour créer GSSContext , en passant:
    • a GSSName representing the server principal, note the Kerberos specific principal name here
    • the Oid of mechanism to use, Kerberos v5 here
    • the initiator's credentials, null here means that default credentials will be used
    • the lifetime for the established context
  • Finally, we prepare the context for mutual authentication, confidentiality, and data integrity

Similarly, we have to define the server-side context:

GSSManager manager = GSSManager.getInstance(); GSSContext serverContext = manager.createContext((GSSCredential) null);

As we can see, this is much simpler than the client-side context. The only difference here is that we need acceptor's credentials which we have used as null. As before, null means that the default credentials will be used.

4.2. GSS API Authentication

Although we have created the server and client-side GSSContext, please note that they are unestablished at this stage.

To establish these contexts, we need to exchange tokens specific to the security mechanism specified, that is Kerberos v5:

// On the client-side clientToken = clientContext.initSecContext(new byte[0], 0, 0); sendToServer(clientToken); // This is supposed to be send over the network // On the server-side serverToken = serverContext.acceptSecContext(clientToken, 0, clientToken.length); sendToClient(serverToken); // This is supposed to be send over the network // Back on the client side clientContext.initSecContext(serverToken, 0, serverToken.length);

This finally makes the context established at both the ends:

assertTrue(serverContext.isEstablished()); assertTrue(clientContext.isEstablished());

4.3. GSS API Secure Communication

Now, that we have context established at both the ends, we can start sending data with integrity and confidentiality:

// On the client-side byte[] messageBytes = "Baeldung".getBytes(); MessageProp clientProp = new MessageProp(0, true); byte[] clientToken = clientContext.wrap(messageBytes, 0, messageBytes.length, clientProp); sendToClient(serverToken); // This is supposed to be send over the network // On the server-side MessageProp serverProp = new MessageProp(0, false); byte[] bytes = serverContext.unwrap(clientToken, 0, clientToken.length, serverProp); String string = new String(bytes); assertEquals("Baeldung", string);

There are a couple of things happening here, let's analyze:

  • MessageProp is used by the client to set the wrap method and generate the token
  • The method wrap also adds cryptographic MIC of the data, the MIC is bundled as part of the token
  • That token is sent to the server (possibly over a network call)
  • The server leverages MessageProp again to set the unwrap method and get data back
  • Also, the method unwrap verifies the MIC for the received data, ensuring the data integrity

Hence, the client and server are able to exchange data with integrity and confidentiality.

4.4. Kerberos Set-up for the Example

Now, a GSS mechanism like Kerberos is typically expected to fetch credentials from an existing Subject. The class Subject here is a JAAS abstraction representing an entity like a person or a service. This is usually populated during a JAAS-based authentication.

However, for our example, we'll not directly use a JAAS-based authentication. We'll let Kerberos obtain credentials directly, in our case using a keytab file. There is a JVM system parameter to achieve that:

-Djavax.security.auth.useSubjectCredsOnly=false

However, the defaults Kerberos implementation provided by Sun Microsystem relies on JAAS to provide authentication.

This may sound contrary to what we just discussed. Please note that we can explicitly use JAAS in our application which will populate the Subject. Or leave it to the underlying mechanism to authenticate directly, where it anyways uses JAAS. Hence, we need to provide a JAAS configuration file to the underlying mechanism:

com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab=example.keytab principal="client/localhost" storeKey=true; }; com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab=example.keytab storeKey=true principal="HTTP/localhost"; };

This configuration is straight-forward, where we have defined Kerberos as the required login module for both initiator and acceptor. Additionally, we have configured to use the respective principals from a keytab file. We can pass this JAAS configuration to JVM as a system parameter:

-Djava.security.auth.login.config=login.conf

Here, the assumption is that we have access to a Kerberos KDC. In the KDC we have set up the required principals and obtained the keytab file to use, let's say “example.keytab”.

Additionally, we need the Kerberos configuration file pointing to the right KDC:

[libdefaults] default_realm = EXAMPLE.COM udp_preference_limit = 1 [realms] EXAMPLE.COM = { kdc = localhost:52135 }

This simple configuration defines a KDC running on port 52135 with a default realm as EXAMPLE.COM. We can pass this to JVM as a system parameter:

-Djava.security.krb5.conf=krb5.conf

4.5. Running the Example

To run the example, we have to make use of the Kerberos artifacts discussed in the last section.

Also, we need to pass the required JVM parameters:

java -Djava.security.krb5.conf=krb5.conf \ -Djavax.security.auth.useSubjectCredsOnly=false \ -Djava.security.auth.login.config=login.conf \ com.baeldung.jgss.JgssUnitTest

This is sufficient for Kerberos to perform the authentication with credentials from keytab and GSS to establish the contexts.

5. GSS API in Real World

While GSS API promises to solve a host of security problems through pluggable mechanisms, there are few use cases which have been more widely adopted:

  • It's widely used in SASL as a security mechanism, especially where Kerberos is the underlying mechanism of choice. Kerberos is a widely used authentication mechanism, especially within an enterprise network. It is really useful to leverage a Kerberised infrastructure to authenticate a new application. Hence, GSS API bridges that gap nicely.
  • It's also used in conjugation with SPNEGO to negotiate a security mechanism when one is not known beforehand. In this regard, SPNEGO is a pseudo mechanism of GSS API in a sense. This is widely supported in all modern browsers making them capable of leveraging Kerberos-based authentication.

6. GSS API in Comparision

GSS API is quite effective in providing security services to applications in a pluggable manner. However, it's not the only choice to achieve this in Java.

Let's understand what else Java has to offer and how do they compare against GSS API:

  • Java Secure Socket Extension (JSSE): JSSE is a set of packages in Java that implements Secure Sockets Layer (SSL) for Java. It provides data encryption, client and server authentication, and message integrity. Unlike GSS API, JSSE relies on a Public Key Infrastructure (PKI) to work. Hence, the GSS API works out to be more flexible and lightweight than JSSE.
  • Java Simple Authentication and Security Layer (SASL): SASL is a framework for authentication and data security for internet protocols which decouples them from specific authentication mechanisms. This is similar in scope to GSS API. However, Java GSS has limited support for underlying security mechanisms through available security providers.

Dans l'ensemble, l'API GSS est assez puissante pour fournir des services de sécurité de manière indépendante du mécanisme. Cependant, la prise en charge de davantage de mécanismes de sécurité dans Java fera progresser cette adoption.

7. Conclusion

Pour résumer, dans ce tutoriel, nous avons compris les bases de l'API GSS en tant que cadre de sécurité. Nous sommes passés par l'API Java pour GSS et avons compris comment nous pouvons en tirer parti. Au cours du processus, nous avons créé des composants client et serveur simples qui effectuaient une authentification mutuelle et échangeaient des données en toute sécurité.

De plus, nous avons également vu quelles sont les applications pratiques de l'API GSS et quelles sont les alternatives disponibles en Java.

Comme toujours, le code peut être trouvé sur GitHub.

Fond Java

Je viens d'annoncer le nouveau cours Learn Spring , axé sur les principes de base de Spring 5 et Spring Boot 2:

>> VOIR LE COURS