Java GSS-API服务票证未使用Java保存在凭据高速缓存中
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了Java GSS-API服务票证未使用Java保存在凭据高速缓存中，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含7143字，纯文字阅读大概需要11分钟。
内容图文
我使用GSS-API创建了2个演示Kerberos客户端.
一个在Python3中,第二个在Java中.
两个客户端似乎大致相同,并且两者都“起作用”,因为我获得了我的Java GSS-API服务主体接受的服务票证.
但是在测试时我注意到Python客户端将服务票据保存在kerberos凭证缓存中,而Java客户端似乎没有保存票证.
我使用“klist”来查看凭证缓存的内容.
我的客户使用FreeIPA作为Kerberos环境在Lubuntu 17.04虚拟机上运行.我正在使用OpenJDK 8 u131.
问题1：Java GSS-API是否不保存凭证缓存的服务票证？或者我可以更改我的代码吗？
问题2：服务票据未保存到缓存这一事实是否有任何缺点？
我的假设是缓存的服务票据减少了与KDC的交互,但How to save Kerberos Service Ticket using a Windows Java client?的评论表明情况并非如此,但this Microsoft technote说“客户端每次想要访问这个特定服务器时都不需要返回KDC”.
问题3：来自python客户端的缓存服务票证在几分钟后消失 – 在到期日之前很久.是什么导致他们消失？
Python代码
#!/usr/bin/python3.5
import gssapi
from io import BytesIO
server_name = 'HTTP/app-srv.acme.com@ACME.COM'
service_name = gssapi.Name(server_name)
client_ctx = gssapi.SecurityContext(name=service_name, usage='initiate')
initial_client_token = client_ctx.step()
Java代码
System.setProperty("java.security.krb5.conf","/etc/krb5.conf");
System.setProperty("javax.security.auth.useSubjectCredsOnly","false");
GSSManager manager = GSSManager.getInstance();
GSSName clientName;
GSSContext context = null;
//try catch removed for brevity
GSSName serverName =
manager.createName("HTTP/app-srv.acme.com@ACME.COM", null);
Oid krb5Oid = new Oid("1.2.840.113554.1.2.2");
//use default credentials
context = manager.createContext(serverName,
krb5Oid,
null,
GSSContext.DEFAULT_LIFETIME);
context.requestMutualAuth(false);
context.requestConf(false);
context.requestInteg(true);
byte[] token = new byte[0];
token = context.initSecContext(token, 0, token.length);
编辑：
虽然最初的问题集中在使用Java GSS-API构建Java Kerberos客户端,但GSS不是必须的.我对其他适用于Java的Kerberos方法持开放态度.现在我正在试验Apache Kerby curb-client.
到目前为止,Java GSS-API似乎有两个问题：
1)它使用凭证缓存来获取TGT(Ok),但不使用缓存服务票证(Not Ok).
2)它无法访问KEYRING类型的凭证缓存. (通过行为确认,调试Java运行时安全类以及该代码中的注释.对于Lubuntu / FreeIPA组合,我使用KEYRING是开箱即用的默认设置.这不适用于Windows,并且可能不适用于其他Linux Kerberos组合.
解决方法:
编辑2：
我应该问的问题是：
How do I stop my KDC from being hammered for repeated SGT requests because Java GSS is not using the credentials cache.
我将原始答案留在底部,因为如果主要关注原始问题.
经过另一轮深度调试和测试,我找到了一个可接受的根问题解决方案.
在我的原始解决方案中使用Java GSS API与JAAS相比,而不是没有JAAS的“纯粹”GSS会产生很大的不同！
是的,没有加载可能在凭证缓存中的现有服务票证(SGT),
也没有任何新获得的SGT写回缓存,但KDC不会经常被敲打(真正的问题).
纯GSS和带有JAAS的GSS都使用客户主体.主题有一个内存中的privateCredentials集,
用于存储TGT和SGT.
关键的区别是：
>“纯GSS”：主题privateCredentials在GSSContext中创建,并且只有GSSContext存在时才存在.
> GSS与JAAS：主题由JAAS在GSSContext之外创建,因此可以在应用程序的生命周期中存在,
在应用程序的生命周期中跨越许多GSSContexts.
建立的第一个GSSContext将查询主题的privateCredentials以查找SGT,而不是查找一个,
然后从KDC请求SGT.
SGT被添加到主题的privateCredentials中,并且由于主题的寿命比GSSContext长,
当创建GSSContexts时,它和SGT一样可用.这些将在主题的privateCredentials中找到SGT,并且不需要为新SGT命中KDC.
因此,根据我的特定Java胖客户端看到,打开一次并可能运行数小时,一切都很好.
创建的第一个GSSContext将命中一个SGT的KDC,然后将由所有后续创建的GSSContex使用,直到客户端关闭.
没有使用凭证缓存,但这并没有伤害.
鉴于一个生命短暂的客户,重新打开了很多次,也许并行,
然后使用/不使用凭证缓存可能是一个更严重的问题.
private void initJAASandGSS() {
LoginContext loginContext = null;
TextCallbackHandler cbHandler = new TextCallbackHandler();
try {
loginContext = new LoginContext("wSOXClientGSSJAASLogin", cbHandler);
loginContext.login();
mySubject = loginContext.getSubject();
} catch (LoginException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
gssManager = GSSManager.getInstance();
try {
//TODO: LAMB: This name should be got from config / built from config / serviceIdentifier
serverName = gssManager.createName("HTTP/app-srv.acme.com@ACME.COM", null);
Oid krb5Oid = new Oid("1.2.840.113554.1.2.2");
} catch (GSSException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
private String getGSSwJAASServiceToken() {
byte[] token = null;
String encodedToken = null;
token = Subject.doAs(mySubject, new PrivilegedAction<byte[]>(){
public byte[] run(){
try{
System.setProperty("javax.security.auth.useSubjectCredsOnly","true");
GSSContext context = gssManager.createContext(serverName,
krb5Oid,
null,
GSSContext.DEFAULT_LIFETIME);
context.requestMutualAuth(false);
context.requestConf(false);
context.requestInteg(true);
byte[] ret = new byte[0];
ret = context.initSecContext(ret, 0, ret.length);
context.dispose();
return ret;
} catch(Exception e){
Log.log(Log.ERROR, e);
throw new otms.util.OTMSRuntimeException("Start Client (Kerberos) failed, cause: " + e.getMessage());
}
}
});
encodedToken = Base64.getEncoder().encodeToString(token);
return encodedToken;
}
结束编辑2：原始答案如下：
问题1：Java GSS-API是否不保存凭证缓存的服务票证？或者我可以更改我的代码吗？
编辑：根本原因分析.
经过几个小时调试sun.security.*类之后,我现在明白了GSS和Java安全代码正在做什么/不做什么 – 至少在Java 8 u 131中.
在此示例中,我们有一个Java GSS可以访问的凭证缓存,其中包含有效的票证授予票证(TGT)和有效的服务票证(SGT).
1)创建客户端主体Subject时,将从缓存(Credentials.acquireTGTFromCache())加载TGT,并将其存储在Subject的privateCredentials集中. – > (好)
仅加载TGT,未加载SGT并将其保存到Subject privateCredentials. – >(不行)
2)稍后,在GSSContext.initSecContext()过程的深处,安全代码实际上尝试从Subject的privateCredentials中检索服务票证.相关代码是Krb5Context.initSecContext()/ KrbUtils.getTicket()/ SubjectComber.find()/ findAux().但是,由于SGT从未在步骤1)中加载,因此将无法找到SGT！因此,从KDC请求新的SGT并使用.
对每个服务请求重复此操作.
只是为了好玩,并且严格地作为概念验证黑客,我在登录和initSecContext()之间添加了几行代码来解析凭证缓存,提取凭据,转换为Krb凭证,并将它们添加到主体的私人凭证.
这在步骤2)中完成,找到并使用现有的SGT.没有从KDC请求新的SGT.
我不会发布这个hack的代码,因为它调用了我们不应该调用的sun内部类,而且我不希望激励其他人这样做.我也打算用这个黑客作为解决方案.
– >根本原因问题不是服务票据没有保存到缓存;反而
a)SGT未从凭证缓存加载到客户端主体的主体
和
b)没有公共API或配置设置.
无论是否使用JAAS,这都会影响GSS-API.
那么这会让我离开？
i)使用JASAS的Java GSS-API / GSS-API“按原样”,每个SGT请求命中KDC – >不好.
ii)正如Samson在下面的评论中所建议的,仅使用Java GSS-API进行应用程序的初始登录,然后对于所有进一步的调用,使用替代安全机制进行后续调用(一种自建的kerberos-light)使用令牌或饼干.
iii)考虑GSS-API的替代方案,例如Apache Kerby curb-client.这超出了这个答案的范围,可能会证明是从众所周知的煎锅跳到火上.
我已经向Oracle提交了一个Java功能请求,建议应该从缓存中检索SGT并将其存储在Subject凭证中(就像TGT的情况一样).
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8180144
问题2：服务票据未保存到缓存这一事实是否有任何缺点？
使用服务票证的凭证缓存可减少客户端与KDC之间的交互.这样做的必然结果是,在没有缓存服务票据的情况下,每个请求都需要与KDC进行交互,这可能导致KDC受到重创.
内容总结
以上是互联网集市为您收集整理的Java GSS-API服务票证未使用Java保存在凭据高速缓存中全部内容，希望文章能够帮你解决Java GSS-API服务票证未使用Java保存在凭据高速缓存中所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。