Anyone out there still using JERI Kerberos?
If so, I'd like to know.
While the JERI Kerberos implementation (including discovery) hasn't been
testing in a long while (never in the history of Apache River), parts of
the implementation are shared with other JERI implementations. The main
issue has been that testing requires setting up a KDC.
JERI Kerberos supports delegation, so services may act on behalf of
logged in clients, for example this may be useful to access a database a
service utilises.
JERI Kerberos is the last piece of code that still uses sun
implementation code:
com.sun.security.jgss.GSSUtil.createSubject(GSSName name, GSSCredential
credentials)
Basically, this code retrieves the KerberosPrincipal and places the
KerberosTicket's and KerberosKey's it retrieves from the GSSCredentials
into the Subject's private credential set.
So the next time the a Kerberos connection is made using this Subject,
the Principal, tickets and key are used to create the GSSCredentials
used to establish the next connection.
Anyway, it turns out there's a cross platform way to do the same thing.
Set privateCredentials = new Set();
privateCredentials.add(gssCredentials);
Set principals = new Set();
principals.add(new KerberosPrincipal(gssName.toString()));
Subject clientSubject = new Subject(true, principals,
Collections.emptySet(), privateCredentials);
It turns out that the Kerberos provider implementations also look for
GSSCredential in a Subject's private credentials, so this is a cross
platform way of performing delegation.
Something else I'm considering Kerberos for is RPC for the IoT space.
Check out lower power passive wifi here:
http://passivewifi.cs.washington.edu/
When it comes to low power, passive wifi, C, Kerberos and RPC aren't a
bad combination. All they need is a discovery protocol and a RPC
Kerberos jeri endpoint, so a registration service can discover them and
register them with the Jini lookup service.
Cheers,
Peter.
