Spring remoting with RMI and Kerberos

[MarcinJarzab]

Now I'm working on small PoC for presentation how Kerberos can be integrated with Java in non-web applications.
I have been implementing RMI app using Spring and now I want to add support for Kerberos.
According to spring-security Kerberos extensions there are beans which probably support it:
http://static.springsource.org/sprin...ocs/index.html

Unfortunately I can find any working example for spring-remoting based on RMI. There are many of them for webapps.
http://stackoverflow.com/questions/4...ide-the-domain

I think that the issue is to define interceptors for RMI components (generated using AOP) which use Kerberos authentication providers?

Thanks in advance
marcin

[Michael-O]

Forget about the Extension. Won't help you. I was looking for the same thing. As far as I understood Oracle's docs, you have to implement a custom SocketFactory which will wrap the entire comm through the GSS-API context. I gave up because I found little information on this.

[jim_doyle]

Forget about the Extension. Won't help you. I was looking for the same thing. As far as I understood Oracle's docs, you have to implement a custom SocketFactory which will wrap the entire comm through the GSS-API context. I gave up because I found little information on this.

It's possible to do this, but this is a very focused project which, IMHO, only a few people on the JBoss forums have talked about. For the most part, if you search for "Java and Kerberos" you will only find people that do Authorization with SPNEGO or JAAS, few people even dive past Single Signon. That said, I'll give some followup.

1. The GSS-API Mechanism is a conversational protocol with in-band control tokens to change session key, or re-negotiate credentials midstream, and address replay-attacks. Your socket factory would have intermediate these GSS API in-band control mechanism on behalf of the RMI Server and Client consumers of the socket abstraction. Yes, it can be done, but it's likely some focused, full-time work. You'd have to maintain per-client state per connection as well to implement RMI Servers. Again, this is sizeable work.

2. You could use the Java SASL implementation with Kerberos GSS API right now. For the most part, the only people who seem to use this are folks connecting to OpenLDAP of MS Active Directory. However, if you can adapt the Custom Socket Factory to ride the network traffic through SASLServer and SASLClient, you'd have a solution, albeit some may object to SASL.

It's a very big project. Which is why it hasnt happened yet. Further, the folks out there that have the domain experience with Kerberos and GSS is very thin on the ground, maybe a few dozen people.

-- Jim Doyle (Medford, MA)

[Michael-O]

Jim,

to point 1: One would need both client and server implementations and make sure that RMI still works as expected.
to point 2: SASL is a very good way to go, again RMI must be tunneled. This is a tough task.

For those who really need this, try to resort to a REST API. You get SPENGO for free. I am going to released an improved GSS-API supporting library for the spring framework over Christmas. (RestTemplate will be adapted later).

Is there nothing out-of-the-box for authentication in RMI?

One could start with this project: https://code.google.com/p/rmiauth/ and adapt the code for GSS-API token exchange. I do not know whether RMI socket call can be wrapped with SASL. If so, one could even encrypt the entire traffic with Kerberos and avoid the hassle with SSL and certs.

[jim_doyle]

Jim,
Is there nothing out-of-the-box for authentication in RMI?

It's surprisingly weak and thin considering it is 2012/2013 and I saw fine-grained access control in
DCE as well as GSS-RPC in the late 1990s.

I was able to get RMI over SSL working nicely using keystore/truststore pairs on boths sides of the connection.
I had to carefully assemble work from others and build a prototype. RMI over SSL is wraught with hazards that are
hard to debug if you get the setup wrong because the SSL debug output is limited in its clarity. But when you get
it working, RMI over SSL does do the job! What are the weaknesses? Simple to Explain:

Let's say you want to inject the Caller Principal's X.509 Identity to ThreadLocal scope so that, for example, you
want to use Spring Security to do Method-level Authorization. Well, it turns out that the RMI Runtime mixes threads, so even though you can extract the SSL Peer Identity using a Custom Socket Factory, that identity never
arrives on the Thread that calls the Stub (the UnicastRemoteObject). So, the programming model you'd expect to be honored does not work.

This obscure paper reveals precisely the mechanism deficit I found on my own:
http://www.seas.upenn.edu/~shoulson/papers/rmipaper.pdf

You are stuck... The Calling Principal can be restricted by truststore... But the Caller will have access to *ALL* exported Remote Interfaces from the Server! That may be enough to solve many, but not all, problems.
If you want to do that, please review this article for examples on how to get there:

https://blogs.oracle.com/lmalventosa...ssl_tls_based1

The crux is that the Sun/Oracle RMI Dispatcher uses a complex thread-pool dispatch model that prevents you
from having your Socket Factory bind the Caller Principal to Thread and have that arrive to Server Stub. That
sucks. If you read the details of the UPenn Paper - you'll see the hint to the clever workaround. But, after all,
it is a workaround.

For Kerberos GSS-API based Socket Factories, there'd be considerable work to do. It's maddening that the obvious
solution is just beyond reach.

-- Jim

[Michael-O]

Jim thanks for that insight. One must consider that Kerberos is connection-based. As you have layed out it might be a contradiction to the way RMI works on the server-side.

I have evaluated RMI for a Lucene remote call for a Spring-based app but I need auth with Kerberos and that does not exist with RMI. I rather choose a REST API with JSON.

I do not see any benifit to invest a huge amount of time into this where one could use SASL or a HTTP REST API.