Una guida all'API Java GSS

Java Top

Ho appena annunciato il nuovo corso Learn Spring , incentrato sui fondamenti di Spring 5 e Spring Boot 2:

>> SCOPRI IL CORSO

1. Panoramica

In questo tutorial, capiremo l'API del servizio di sicurezza generica (API GSS) e come possiamo implementarla in Java. Vedremo come possiamo proteggere la comunicazione di rete utilizzando l'API GSS in Java.

Nel processo, creeremo semplici componenti client e server, proteggendoli con l'API GSS.

2. Che cos'è l' API GSS ?

Allora, cos'è veramente l'API del servizio di sicurezza generico? L'API GSS fornisce un framework generico per le applicazioni per utilizzare diversi meccanismi di sicurezza come Kerberos , NTLM e SPNEGO in modo collegabile. Di conseguenza, aiuta le applicazioni a separarsi direttamente dai meccanismi di sicurezza.

Per chiarire, la sicurezza qui abbraccia l' autenticazione, l'integrità dei dati e la riservatezza.

2.1. Perché abbiamo bisogno dell'API GSS ?

I meccanismi di sicurezza come Kerberos, NTLM e Digest-MD5 sono abbastanza diversi nelle loro capacità e implementazioni. In genere, un'applicazione che supporta uno di questi meccanismi trova piuttosto scoraggiante passare a un altro.

È qui che un framework generico come l'API GSS fornisce alle applicazioni un'astrazione . Pertanto le applicazioni che utilizzano l'API GSS possono negoziare un meccanismo di sicurezza adeguato e utilizzarlo per la comunicazione. Tutto ciò senza dover implementare alcun dettaglio specifico del meccanismo.

2.2. Come funziona l' API GSS ?

L'API GSS è un meccanismo basato su token . Funziona tramite lo scambio di token di sicurezza tra pari . Questo scambio avviene in genere su una rete, ma l'API GSS è indipendente da questi dettagli.

Questi token vengono generati ed elaborati dalle implementazioni specifiche dell'API GSS. La sintassi e la semantica di questi token sono specifiche del meccanismo di sicurezza negoziato tra i peer:

Il tema centrale dell'API GSS ruota attorno a un contesto di sicurezza. Possiamo stabilire questo contesto tra pari attraverso lo scambio di token. Potremmo aver bisogno di più scambi di token tra colleghi per stabilire il contesto.

Una volta stabilito con successo a entrambe le estremità, possiamo utilizzare il contesto di sicurezza per scambiare dati in modo sicuro. Ciò può includere controlli di integrità dei dati e crittografia dei dati, a seconda del meccanismo di sicurezza sottostante.

3. Supporto API GSS in Java

Java supporta l'API GSS come parte del pacchetto "org.ietf.jgss". Il nome del pacchetto può sembrare strano. Questo perché i collegamenti Java per l'API GSS sono definiti in una specifica IETF . La specifica stessa è indipendente dal meccanismo di sicurezza.

Uno dei meccanismi di sicurezza più diffusi per Java GSS è Kerberos v5.

3.1. API Java GSS

Proviamo a capire alcune delle API principali che costruiscono Java GSS:

  • GSSContext incapsula il contesto di sicurezza dell'API GSS e fornisce i servizi disponibili nel contesto
  • GSSCredential incapsula le credenziali dell'API GSS per un'entità necessaria per stabilire il contesto di sicurezza
  • GSSName incapsula l'entità principale dell'API GSS che fornisce un'astrazione per il diverso spazio dei nomi utilizzato dai meccanismi sottostanti

Oltre alle interfacce di cui sopra, ci sono poche altre classi importanti da notare:

  • GSSManager funge da classe di fabbrica per altre importanti classi API GSS come GSSName , GSSCredential e GSSContext
  • Oid rappresenta gli Universal Object Identifier (OID) che sono identificatori gerarchici utilizzati all'interno dell'API GSS per identificare meccanismi e formati di nomi
  • MessageProp racchiude le proprietà per indicare GSSContext su cose come la qualità della protezione (QoP) e la riservatezza per lo scambio di dati
  • ChannelBinding incapsula le informazioni di associazione del canale facoltative utilizzate per rafforzare la qualità con cui viene fornita l'autenticazione dell'entità peer

3.2. Provider di sicurezza GSS Java

Sebbene Java GSS definisca il framework principale per l'implementazione dell'API GSS in Java, non fornisce un'implementazione. Java adotta implementazioni collegabili basate sul provider per i servizi di sicurezza, incluso Java GSS.

There can be one or more such security providers registered with the Java Cryptography Architecture (JCA). Each security provider may implement one or more security services, like Java GSSAPI and security mechanisms underneath.

There is a default GSS provider that ships with the JDK. However, there are other vendor-specific GSS providers with different security mechanisms which we can use. One such provider is IBM Java GSS. We have to register such a security provider with JCA to be able to use them.

Moreover, if required, we can implement our own security provider with possibly custom security mechanisms. However, this is hardly needed in practice.

4. GSS API Through an Example

Now, we'll see Java GSS in action through an example. We'll create a simple client and server application. The client is more commonly referred to as initiator and server as an acceptor in GSS. We'll use Java GSS and Kerberos v5 underneath for authentication.

4.1. GSS Context for Client and Server

To begin with, we'll have to establish a GSSContext, both at the server and client-side of the application.

Let's first see how we can do this at the client-side:

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);

There is quite a lot of things happening here, let's break them down:

  • We begin by creating an instance of the GSSManager
  • Then we use this instance to create GSSContext, passing along:
    • 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.

Nel complesso, l'API GSS è piuttosto potente nel fornire servizi di sicurezza in modo indipendente dal meccanismo. Tuttavia, il supporto per più meccanismi di sicurezza in Java lo porterà ulteriormente nell'adozione.

7. Conclusione

Per riassumere, in questo tutorial, abbiamo compreso le basi dell'API GSS come framework di sicurezza. Abbiamo esaminato le API Java per GSS e abbiamo capito come sfruttarle. Nel processo, abbiamo creato semplici componenti client e server che eseguivano l'autenticazione reciproca e scambiavano dati in modo sicuro.

Inoltre, abbiamo anche visto quali sono le applicazioni pratiche dell'API GSS e quali sono le alternative disponibili in Java.

Come sempre, il codice può essere trovato su GitHub.

Fondo Java

Ho appena annunciato il nuovo corso Learn Spring , incentrato sui fondamenti di Spring 5 e Spring Boot 2:

>> SCOPRI IL CORSO