I have created 2 demo Kerberos Clients using the GSS-API.
One in Python3, the second in Java.
Both clients seem to be broadly equivalent, and both "work" in that I get a service ticket that is accepted by my Java GSS-API Service Principal.
However on testing I noticed that the Python client saves the service ticket in the kerberos credentials cache, whereas the Java client does not seem to save the ticket.
I use "klist" to view the contents of the credential cache.
My clients are running on a Lubuntu 17.04 Virtual Machine, using FreeIPA as the Kerberos environment. I am using OpenJDK 8 u131.
Question 1: Does the Java GSS-API not save service tickets to the credentials cache? Or can I change my code so it does so?
Question 2: Is there any downside to the fact that the service ticket is not saved to the cache?
My assumption is that cached service tickets reduce interaction with the KDC, but comments on How to save Kerberos Service Ticket using a Windows Java client? suggest that is not the case, but this Microsoft technote says "The client does not need to go back to the KDC each time it wants access to this particular server".
Question 3: The cached service tickets from the python client vanish after some minutes - long before the expiry date. What causes them to vanish?
Python code
#!/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 Code
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);
Edit:
While the original question focusses on the use of the Java GSS-API to build a Java Kerberos Client, GSS is not a must. I am open to other Kerberos approaches that work on Java. Right now I am experimenting with Apache Kerby kerb-client.
So far Java GSS-API seems to have 2 problems:
1) It uses the credentials cache to get the TGT (Ok), but not to cache service-tickets (Not Ok).
2) It cannot access credential caches of type KEYRING. (Confirmed by behaviour, debugging the Java runtime security classes, and by comments in that code. For the Lubuntu / FreeIPA combination I am using KEYRING was the out-of-the-box default. This won't apply to Windows, and may not apply to other Linux Kerberos combinations.
Edit 2:
The question I should have asked is:
How do I stop my KDC from being hammered for repeated SGT requests because Java GSS is not using the credentials cache.
I leave my original answer in place at the bottom, because if largely focusses on the original question.
After another round of deep debugging and testing, I have found an acceptable solution to the root problem.
Using Java GSS API with JAAS, as opposed to "pure" GSS without JAAS in my original solution makes a big difference!
Yes, existing Service Tickets (SGTs) that may be in the credentials cache are not being loaded,
nor are any newly acquired SGTs written back to the cache, however the KDC is not be constantly hammered (the real problem).
Both pure GSS, and GSS with JAAS use a client principal subject. The subject has an in-memory privateCredentials set,
which is used to store TGTs and SGTs.
The key difference is:
"pure GSS": the subject + privateCredentials is created within the GSSContext, and lives only as long as the GSSContext lives.
GSS with JAAS: the subject is created by JAAS, outside the GSSContext, and thus can live for the life of the application,
spanning many GSSContexts during the life of the application.
The first GSSContext established will query the subject's privateCredentials for a SGT, not find one,
then request a SGT from the KDC.
The SGT is added to the subject's privateCredentials, and as the subject lives longer than the GSSContext,
it is available, as is the SGT, when following GSSContexts are created. These will find the SGT in the subject's privateCredentials, and do not need to hit the KDC for a new SGT.
So seen in the light of my particular Java Fat Client, opened once and likely to run for hours, everything is ok.
The first GSSContext created will hit the KDC for a SGT which will then be used by all following GSSContexts created until the client is closed.
The credentials cache is not being used, but that does not hurt.
In the light of a much shorter lived client, reopened many many times, and perhaps in parallel,
then use / non-use of the credentials cache might be a more serious issue.
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;
}
End Edit 2: Original answer below:
Question 1: Does the Java GSS-API not save service tickets to the credentials cache? Or can I change my code so it does so?
Edit: Root Cause Analysis.
After many hours debugging the sun.security.* classes, I now understand what GSS and Java Security code is doing / not doing - at least in Java 8 u 131.
In this example we have a credential cache, of a type Java GSS can access, containing a valid Ticket Granting Ticket (TGT) and a valid Service Ticket (SGT).
1) When the client principal Subject is created, the TGT is loaded from the cache (Credentials.acquireTGTFromCache()), and stored in the privateCredentials set of the Subject. --> (OK)
Only the TGT is loaded, SGTs are NOT loaded and saved to the Subject privateCredentials. -->(NOT OK)
2) Later, deep in the GSSContext.initSecContext() process, the security code actually tries to retrieve a Service Ticket from the privateCredentials of the Subject. The relevant code is Krb5Context.initSecContext() / KrbUtils.getTicket() / SubjectComber.find()/findAux(). However as SGTs were never loaded in step 1) an SGT will not be found! Therefore a new SGT is requested from the KDC and used.
This is repeated for each Service request.
Just for fun, and strictly as a proof-of-concept hack, I added a few lines of code between the login, and the initSecContext() to parse the credentials cache, extract the credentials, convert to Krb Credentials, and add them to the Subject’s private credentials.
This done, in step 2) the existing SGT is found and used. No new SGT is requested from the KDC.
I will not post the code for this hack as it calls sun internal classes that we should not be calling, and I don’t wish to inspire anybody else to do so. Nor do I intend to use this hack as a solution.
—> The root cause problem is not that the service ticket are not SAVED to the cache; but rather
a) that SGTs are not LOADED from the credential cache to the Subject of the client principal
and
b) that there is no public API or configuration settings to do so.
This affects GSS-API both with and without JAAS.
So where does this leave me?
i) Use Java GSS-API / GSS-API with JAAS “as is”, with each SGT Request hitting the KDC —> Not good.
ii) As suggested by Samson in the comments below, use Java GSS-API only for initial login of the application, then for all further calls use an alternative security mechanism for subsequent calls (a kind of self-built kerberos-light) using tokens or cookies.
iii) Consider alternatives to GSS-API such as Apache Kerby kerb-client. This has implications outside the scope of this answer, and may well prove to be jumping from the proverbial frying pan to the fire.
I have submitted a Java Feature Request to Oracle, suggesting that SGTs should be retrieved from the cache and stored in the Subject credentials (as already the case for TGTs).
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8180144
Question 2: Is there any downside to the fact that the service ticket is not saved to the cache?
Using the credentials cache for Service Tickets reduces interaction between the client and the KDC. The corollary to this is that where service tickets are not cached, each request will require interaction with the KDC, which could lead to the KDC being hammered.
Related
I am working on golang version of fabcar smart contract while seeking to implement a Java-SDK API which enrolls an admin, registers a user and performs query-update value operations based on https://github.com/hyperledger/fabric-samples/tree/master/fabcar/java
I have successfully set up a 3 org-9 peers blockchain network, installed, instantiated and invoked chaincode on peers.
However, as i am working on implementing the relative API, i am only able to successfully query blockchain database, while getting a "Could not meet endorsement policy for chaincode mycc"
Please find below screenshot of relative error
Endorsement policy is "OR ('Org1MSP.member','Org2MSP.member', 'Org3MSP.member')".
Should registered user somehow get an Org1/Org2/Org3.member attribute? Any leads would be appreciated!
Like #Ikar Pohorský said, for me this got resolved after I used correct method name. Also, ensure that you delete 'wallet' folder in order to regenerate the user if your HLF n/w was recreated.
#Test
public void testMyMethodToBeInvoked() throws Exception {
deleteDirectory(".\\wallet");
EnrollAdmin.main(null);
RegisterUser.main(null);
// Load a file system based wallet for managing identities.
final Path walletPath = Paths.get("wallet");
final Wallet wallet = Wallet.createFileSystemWallet(walletPath);
// load a CCP
final Path networkConfigPath = Paths
.get("C:\\sw\\hlf146-2\\fabric-samples\\first-network\\connection-org1.yaml");
final Gateway.Builder builder = Gateway.createBuilder();
builder.identity(wallet, "user1").networkConfig(networkConfigPath).discovery(true);
// create a gateway connection
try (Gateway gateway = builder.connect()) {
final Network network = gateway.getNetwork("mychannel");
final Contract contract = network.getContract("mycc");
String myJSONString="{\"a\":\"b\"}";
byte[] result;
// Following did NOT work. Control goes directly to 'invoke' when 'submitTransaction' is done directly. 'invoke' need not be mentioned here.
// result = contract.submitTransaction("invoke", myJSONString);
// Following DID work. In chaincode (my chain code was Java) I had a method named 'myMethodToBeInvoked'. The chain code was written similar to https://github.com/hyperledger/fabric-samples/blob/release-1.4/chaincode/chaincode_example02/java/src/main/java/org/hyperledger/fabric/example/SimpleChaincode.java
result = contract.submitTransaction("myMethodToBeInvoked", my);
System.out.println(new String(result));
}
}
EDIT: Also, please remember that if your chaincode throws errorResponse, even then we can have this endorsement fail issue. So, check if your chain code is working without any issues.
I'm trying to run a long-lived WebHDFS client (actually building the Framework in front on HDFS). But my tokens are expiring after one day (default kerberos configuration here), at first I tried running a thread which would call
userLoginInformation.currentUser().checkTGTAndReloginFromKeytab();
However even though I see the TGT relogin 21hours, but after 24h my WebHDFS Filesystem is stuck on "token not found in the cache" (which is an error meaning that the server already deleted my token).
Watching inside the code # https://github.com/apache/hadoop/blob/release-2.7.1/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/web/WebHdfsFileSystem.java
I found the method "replaceExpiredDelegationToken". But after looking at "runWithRetry" it will be called only if "OPGETDELEGATIONTOKEN" fails (because at all other operations getRequireAuth is FALSE), which basically forces my client to run getDelegationToken at least once each day, so my token gets renewed.
**For now I'll be checking if the FS is a WebHDFS Service and then, each hour I'll do:
if (hdfsFileSystem instanceof WebHdfsFileSystem)
{
WebHdfsFileSystem tmpFS = (WebHdfsFileSystem) hdfsFileSystem;
tmpFS.setDelegationToken(tmpFS.getDelegationToken(null));
}
Is there a better way to force delegation token renewal? (or to have long-lived clients)
Thanks!
After two days testing (so kerberos ticket would run off)
Calling
if (hdfsFileSystem instanceof WebHdfsFileSystem)
{
WebHdfsFileSystem tmpFS = (WebHdfsFileSystem) hdfsFileSystem;
tmpFS.setDelegationToken(tmpFS.getDelegationToken(null));
}
once each hour, it seems to work fine, IMO this should be done at HDFS level but well... it will be # framework level for us :)
Okay, so I have most of the pieces, but I can't seem to put them together properly. I'm basically trying to protect database data with a simple authentication process (maybe with a GUI) to ensure that the correct people are viewing the data. Right now I'm using UnboundID to handle the actual authentication, although I am open to other methods such as JAAS. Here is the method that I wrote for that (the bypass is for testing purposes):
public static boolean authenticate(String username, String password) {
if (username == null || password == null) {
return false;
}
if (username.equals("bypass") && password.equals("bypass")) {
return true;
}
try {
LDAPConnection conn = new LDAPConnection(AUTH_URL,AUTH_PORT);
BindRequest request = new SimpleBindRequest(username,password);
BindResult result = conn.bind(request);
return result.getResultCode().equals(ResultCode.SUCCESS);
} catch (LDAPException ex) {
ex.printStackTrace();
return false;
}
}
This code is obviously dangerous due to the fact that the password is being inputted as plaintext. I did some digging and discovered that I should be using something like SSL for the actual request to protect the password. This raised another question: if I'm sending the request via SSL, don't I still need to somehow supply the password in plaintext form before I send the request? Isn't this dangerous? I'm surprised something like password authentication isn't done by a simple API since so many applications need to be secure. I'm very new to this stuff and would appreciate some guidance. Thanks!
Use TLS everywhere including your LDAP connection. As long as you follow good TLS connection practices your connection is safe.
-jim
You could use Stormpath's Servlet Plugin to authenticate your users. You only need to follow these very simple steps to create your ready to use Web Application.
You can also take the example Servlet App (completely Open Source) as the foundations for your Web App.
You will get:
Out of the box complete Web Application
Complete User Management: user authentication, user management, user storage, workflows, etc.
API Management
Hassle free world-class Security
Frequent free updates
In summary, the workflow will be like this. You will redirect your users to the Login page (or Registration for them to sign up first). Once your user is properly authenticated (via login) you can get your own code executed via the Next URI or the SuccessfulAuthenticationRequestEvent.
Disclaimer, I am an active Stormpath contributor.
I am using jTDS to connect to SQLServer. Internally jTDS uses GSS to obtain a kerberos' service ticket and establish a secure context. Since my app is long lived and my connections are kept alive the entire time I need that kerberos' service ticket to be renewable in order to allow SQL server to renew them on its own (the kdc policies are set to expire all tickets after 12 hours).
What jTDS does to obtain a kerberos token is (more or less) the following:
GSSManager manager = GSSManager.getInstance();
// Oids for Kerberos5
Oid mech = new Oid("1.2.840.113554.1.2.2");
Oid nameType = new Oid("1.2.840.113554.1.2.2.1");
// Canonicalize hostname to create SPN like MIT Kerberos does
GSSName serverName = manager.createName("MSSQLSvc/" + host + ":" + port, nameType);
GSSContext gssContext = manager.createContext(serverName, mech, null, GSSContext.DEFAULT_LIFETIME);
gssContext.requestMutualAuth(false);
gssContext.requestCredDeleg(true);
byte[] ticket = gssContext.initSecContext(new byte[0], 0, 0);
What I suspect is that the ticket I am obtaining is not renewable. I am checking that by doing something like the following:
ExtendedGSSContext extendedContext = (ExtendedGSSContext) gssContext;
boolean[] flags = (boolean[]) extendedContext.inquireSecContext(InquireType.KRB5_GET_TKT_FLAGS);
System.out.println("Renewable = " + flags[8]);
In our particular configuration GSS is getting kerberos TGT from JAAS login module. We have the following variable set to false -Djavax.security.auth.useSubjectCredsOnly=false and in the login.cfg file we have the following login module configured:
com.sun.security.jgss.krb5.initiate {
com.sun.security.auth.module.Krb5LoginModule required
useKeytTab=true
keyTab="/home/batman/.batman.ktab"
principal="batman#GOTHAMCITY.INT"
storeKey=true
doNotPrompt=true
debug=false
};
Another thing I notice is that the getLifetime() method of GSSContext doesn't seem to work. It always returns 2147483647 (max int) no matter what the real lifetime of the ticket is.
I feel confortable with branching jTDS driver, so I can modify the way it establishes a GSS context if needed.
What I tried:
Use native implementation of GSS api:
This works fine for me in terms of obtaining renewable tickets but it imposesses another set of issues (in terms of ensuring that the ticket cache is properly set and tickets in there are properly renew). If I can bypass this option it would be nice. Once thing I observe here is that the getLifetime() method actually returns the real lifetime in seconds of the ticket.
Reimplementing KerberosLoginModule:
Based on the answer to this question Jaas - Requesting Renewable Kerberos Tickets I reimplemented LoginModule to set the RENEW KDCOption in KrbAsReqBuilder before requesting a TGT. That works fine in the sense that I obtain a renewable TGT, but the ticket obtained from that TGT by GSS is still not renewable. If I set a breakpoint in the constructor of the KDCOption object and set the RENEW flag manually on each request (even the KrbTgsReq done by GSS) it works but making that change productive requires a major rewrite on GSS which I don't feel confortable with.
For administrators, the fact that Kerberos tickets have lifetime is an important security feature. User knows a password, so he/she may get a new ticket at any moment. But for intruder it's a problem - after the ticket expires, it can't be used to break into system. Administrators want this lifetime to be as short as possible, but not too short (like 1 hour) because users would generate like 10x more login requests than now, and it would be tough for ActiveDirectory to handle.
When we need to authenticate with Kerberos, we should use connection pooling (and DataSource). To use this feature in jTDS you need to add ConnectionPoolImplementation (recommended: DBCP or c3p0, see: http://jtds.sourceforge.net/features.html).
If you'd like to write your application using older way of connecting to database (without datasource, i.e. creating a connection and keeping it alive because it's expensive to create..) then the next obstacle would be 'renew lifetime'. In ActiveDirectory Kerberos tickets can be by default renewed within 7 days. There's a global setting in AD which allows to set there 0 (an indefinite renew lifetime), but you'd need to persuade Domain Administrator to lower security of whole domain just because one service wouldn't run without that.
I'm trying to wire our windows client application to use a single-sign-on mechanism. I'm following the explanations that can be found here. I'm already having trouble getting the first step to work, that is, acquiring the Signed On User's Ticket-Granting-Ticket. When running my unit test (code see below), I'm getting the following exception:
javax.security.auth.login.LoginException: Unable to obtain Princpal Name for authentication
at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:800)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:671)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:584)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
at org.myapp.test.cases.SSOTest.testSSO(SSOTest.java:28)
This happens when I run the test with Java 7. I thought this means that the ticket cache is empty. However, when I run the test with Java 6, the login is successful, and I can retrieve a fully populated Subject object from the LoginContext. As I read here, Java 7 now fully respects the Windows 7 policies which allow/deny exporting TGTs. So I set the the allowtgtsessionkey value in my registry, hoping this would fix my problem. But despite having relogged and restarted, I still can't access my TGT with Java 7. With Java 6, it works just fine. Could anyone point out what I'm missing?
SSOTest.java:
#Test
public void testSSO() {
System.setProperty("java.security.auth.login.config", "D:\\login.conf");
LoginContext lc = null;
try {
lc = new LoginContext("TestLoginContext1");
} catch (LoginException e1) {
e1.printStackTrace();
}
try {
lc.login(); // Exception happens here
} catch (LoginException e) {
e.printStackTrace();
}
Subject signedOnUserSubject = lc.getSubject();
System.out.println(signedOnUserSubject);
}
login.conf
TestLoginContext1 {
com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true doNotPrompt=true debug=true;
};
krb5.conf
[libdefaults]
default_realm = MY.DOMAIN.COM
[realms]
MY.DOMAIN.COM = {
kdc = domaincontroller.my.domain.com
admin_server = domaincontroller.my.domain.com
default_domain = MY.DOMAIN.COM
}
It seems this is a limitation of Windows when it comes to accounts that are also in the local administration group. I read the following here:
Known Issues
If an AD account is also added into local administrator group on
the client PC, Microsoft restricts such client from getting the
session key for tickets (even if you set the allowtgtsessionkey
registry key to 1). The workaround is: Just forget you're a logged
in user, call kinit.exe. Do not depends on LSA credential cache.
In a recent hotfix
([35]http://support.microsoft.com/kb/942219/en-us, should be
included in Vista SP1), this restriction is lifted for normal
service tickets. However, it still applies to TGT. Since Java uses TGT
to acquire tickets for other services (the standard Kerberos process),
this update provides no benefit to JGSS programming on Windows.
Furthermore, even if the implementation of Java is changed to read
service tickets from the LSA cache, it still cannot perform
delegation, since a TGT is always needed in that case.