根据配置文件中的信息，Krb5LoginModule可以使用已经存在的credential的缓存，例如操作系统中的本地缓存获得TGT，或者使用keytab文件中存储的密钥隐式的认证一个principal。在所有的平台上，Krb5LoginModule允许在配置文件中指定缓存文件的地址或者keytab文件的路径。在没有上述文件的情况下，会弹出用户名和密码的输入提示。
下面两个图分别是客户端和服务器配置文件书写方式：
SampleClient {
com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true;
};
SampleServer {
com.sun.security.auth.module.Krb5LoginModule
required useKeyTab=true storeKey=true principal="nfs/bar.foo.com" keyTab="/etc/krb5.keytab" doNotPrompt=true;
};
为了使其他供应商提供的kerberos认证模块也能在GSS-API中使用，在javax.security.auth.kerberos包中有三个类需要介绍。
l KerberosPrincipal用来处理principal。
l KerberosKey用来处理long-termkey，即用户的密码。
l KerberosTicket 用来处理ticket。
任何kerberos登录木块的相关内容都要使用这三个类包装。
Java GenericSecurity Service Application Program Interface
GSS-API
企业级应用程序通常需要多种安全需求，并且在底层部署了大量的安全机制。在这种情况下，如何开发客户端服务器程序，使之可以在不同的底层安全机制下轻松的移植？GSS-API实现了这样一种应用程序和底层具体实现之间的隔离。GSS-API是由IETF通用认证技术工作组设计的，提出了几种对等实体间安全通信的程序接口。
GSS-API在RFC 2743中可以查到，提供了以下几种安全服务：认证、信息的机密性和完整性、受保护的消息序列、重放检测以及credential代理。底层的实现有众多的选择。IETF定义了两种标准的安全机制：kerberos v5以及SimplePublic Key Mechanism（SPKM）。
API设计成可以同时使用多种底层安全机制，并且是应用程序可以在运行时选择。底层机制由在IANA注册的统一对象标识符（OID）表示。例如，kerberos v5的标识为{iso(1)member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2)}即(1.2.840.113554.1.2.2)。下图是多种底层安全机制的GSS-API实现。
Java GSS-API
通用安全服务Java版同样也在IETF有定义，并存储在RFC2853中。在Java社区进程（Java Community Process）的基础上，Sun公司追求这套API的标准化。最初的Java GSS-API的实现是只支持kerberos v5的，尽管它支持其他的底层机制，但是kerberos v5是必选的。在将来的发行版中，会添加一个服务提供接口（Service Provide Interface），新的底层机制可以静态的甚至运行时配置。Java GSS-API框架本身是非常轻巧的，所有的安全功能都委托给底层的安全机制。
GSSManager类了解所有安装的底层安全机制，并负责调用这些模块。其对象可以通过下面的方式获得：
GSSManagermanager = GSSManager.getInstance();
GSSManager可以用来配置新的安全机制，或者列出所有已经存在的安全机制。同时它还作为三个重要接口的工厂类，分别是GSSName、GSSCredential和 GSSContext。GSS-API的调用会抛出GSSException异常，这些异常类封装了GSS-API框架本身的问题以及底层安全机制的问题。
GSSNameInterface
该接口代表Java GSS-API中的一个实体实例化的方法如下：
GSSNameGSSManager.createName(String name, Oid nameType) throws GSSException
GSSNameclientName = manager.createName("root", GSSName.NT_USER_NAME);
GSSNameserverName = manager.createName("sample@location.example.com",
GSSName.NT_HOSTBASED_SERVICE);
这个调用返回一个principal的合法格式，并且屏蔽了底层安全机制。例如在kerberos v5机制下，上述第一个例子生成的principal为用户的principal：root@EXAMPLE.COM，第二个例子生成的principal是服务的principal：sample/location.example.com@EXAMPLE.COM。
类似地，底层安全机制是公钥加密机制的话，上述principal会被映射为X.509形式。
GSSCredentialInterface
该接口封装了实体所有的credential，同GSSName接口相同，该接口是一个多层安全机制的容器。其实例化方法如下：
GSSCredential createCredential(GSSName name,int lifetime, Oid[] desiredMechs, int usage) throwsGSSException
GSSCredential clientCreds =
manager.createCredential(clientName,
8*3600,
desiredMechs,
GSSCredential.INITIATE_ONLY);
GSSCredential serverCreds =
manager.createCredential(serverName,
GSSCredential.INDEFINITE_LIFETIME,
desiredMechs,
GSSCredential.ACCEPT_ONLY);
GSSManager调用desiredMechs中所列出的底层安全机制的模块来申请对应principal的credential。此外，加强了安全性的限制，credential必须是initial类型的，生命周期只有八小时。返回的对象中包含相应安全机制认证后的credential。Kerberosv5机制下返回的元素是javax.security.auth.kerberos.KerberosTicket子类的实例，包含用户相关的TGT。
服务器端程序基本相同，除了credential的类型是accept类型的，同时，服务器的credential一般都会申请一个较长生命周期的。
Credential的几个基本属性如下：
l ACCEPT_ONLY：仅用于安全会话环境接受。
l INITIATE_ONLY：仅用于安全会话环境初始化。
l INITIATE_AND_ACCEPT：同时允许安全会话环境初始化和接受。
GSSContextInterface
该类的实例负责提供对等实体间的安全服务。客户端该类实例化的方法：
GSSContext GSSManager.createContext(GSSNamepeer,
Oid mech,
GSSCredential clientCreds,
int lifetime)
throws GSSException
该API返回一个初始化的安全环境，该环境链接了其要通信的对等实体，以及底层相应的安全机制。对等实体需要该客户端的credential用于认证。
服务器端实例化方法：
GSSContextGSSManager.createContext(GSSCredential serverCreds)
throws GSSException