Discussions
Categories
- 197.1K All Categories
- 2.5K Data
- 546 Big Data Appliance
- 1.9K Data Science
- 450.7K Databases
- 221.9K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 552 MySQL Community Space
- 479 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.1K ORDS, SODA & JSON in the Database
- 555 SQLcl
- 4K SQL Developer Data Modeler
- 187.2K SQL & PL/SQL
- 21.3K SQL Developer
- 296.3K Development
- 17 Developer Projects
- 139 Programming Languages
- 293K Development Tools
- 110 DevOps
- 3.1K QA/Testing
- 646.1K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 158 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.2K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 19 Java Essentials
- 162 Java 8 Questions
- 86K Java Programming
- 81 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 466 LiveLabs
- 39 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 175 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 233 Portuguese
Kerberos RMI - Spring Remoting

969563
Member Posts: 1
For some time I have been analyzing the possibility of using Kerberos in RMI apps.
I know that this challenging issue but I decided to use interceptors withing Spring remoting framework
which contains extra transport layer.
I was inspired by the following example (muthual authentication turned off)
http://thejavamonkey.blogspot.com/2008/04/clientserver-hello-world-in-kerberos.html , where ticket is saved on disk and there is no 'while'for GSSContext accept. If there is no while there is no need for using socket factories?
In my solution, the Kerberos ticket is send using apropriate ContextInvocationFactories.
The client is connecting to the KDC, TGT is generated and service ticket is calculated for validation
on the server side.
On the server side I'm using RemoteInvocationExecutor which plays role of 'intercepting filter' where the genenerated ticket is obtained. But during the processing I get some errors.
First of all the server is multithreaded so I'm wondering if the GSSContext can be shared between many
customers or each customer should have assigned the separate instance?
1. In my first approach the GSS context is generated on each invocation of the intercepting filter.
This is problematic because as I assume the operation is not performed within main server thread
in which TGT was obtained and during context creation the error is as foolows:
AccessControlContext is also saved in the 'ApplicationContext'.
During invocation of the filter ticket it is obtained from the method context and the checking is performed:
I know that this challenging issue but I decided to use interceptors withing Spring remoting framework
which contains extra transport layer.
I was inspired by the following example (muthual authentication turned off)
http://thejavamonkey.blogspot.com/2008/04/clientserver-hello-world-in-kerberos.html , where ticket is saved on disk and there is no 'while'for GSSContext accept. If there is no while there is no need for using socket factories?
In my solution, the Kerberos ticket is send using apropriate ContextInvocationFactories.
The client is connecting to the KDC, TGT is generated and service ticket is calculated for validation
on the server side.
On the server side I'm using RemoteInvocationExecutor which plays role of 'intercepting filter' where the genenerated ticket is obtained. But during the processing I get some errors.
First of all the server is multithreaded so I'm wondering if the GSSContext can be shared between many
customers or each customer should have assigned the separate instance?
1. In my first approach the GSS context is generated on each invocation of the intercepting filter.
This is problematic because as I assume the operation is not performed within main server thread
in which TGT was obtained and during context creation the error is as foolows:
GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails) at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:89) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:126) at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:192) at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:406) at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:60) at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:153)The code:
return Subject.doAsPrivileged( serverSubject, new PrivilegedAction<String>() { public String run() { try { Oid krb5Oid = new Oid( "1.2.840.113554.1.2.2"); // Identify the server that communications are being made to. GSSManager manager = GSSManager.getInstance(); // Modified GSSName serverName = manager.createName( "rmi-services/gmaccountingsystem/ubuntu-kerberos-srv.atsi", GSSName.NT_HOSTBASED_SERVICE); GSSCredential serverCreds = manager.createCredential(serverName, GSSCredential.DEFAULT_LIFETIME, krb5Oid, GSSCredential.ACCEPT_ONLY); GSSContext context = manager.createContext( serverCreds ); context.acceptSecContext( serviceTicket, 0, serviceTicket.length); return context.getSrcName().toString(); } catch ( GSSException e) { e.printStackTrace(); return null; } } }, acc);2. In the second approach the GSSContext is generated during server startup and saved in the 'ApplicationContext'.
AccessControlContext is also saved in the 'ApplicationContext'.
During invocation of the filter ticket it is obtained from the method context and the checking is performed:
// Completes the security context initialisation and returns the client name. public static String acceptSecurityContext(Subject serverSubject, final byte[] serviceTicket, final AccessControlContext acc, final GSSContext context) throws GSSException { return Subject.doAsPrivileged( serverSubject, new PrivilegedAction<String>() { public String run() { try { context.acceptSecContext( serviceTicket, 0, serviceTicket.length); return context.getSrcName().toString(); } catch ( GSSException e) { e.printStackTrace(); return null; } } }, acc); }but the validation is not successful:
Caused by: java.lang.IllegalStateException: This key is no longer valid at javax.security.auth.kerberos.KerberosKey.getEncoded(KerberosKey.java:207) at sun.security.jgss.krb5.Krb5Util$ServiceCreds.getEKeys(Krb5Util.java:304) at sun.security.jgss.krb5.Krb5AcceptCredential.getKrb5EncryptionKeys(Krb5AcceptCredential.java:156) at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:768) at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342) at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285) at org.atsi.security.kerberos.jaas.common.Kerberos$2.run(Kerberos.java:67) at org.atsi.security.kerberos.jaas.common.Kerberos$2.run(Kerberos.java:64) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:473) at org.atsi.security.kerberos.jaas.common.Kerberos.acceptSecurityContext
This discussion has been closed.