Sure does.
Kerberos, like Jini / River has, been limited by IPv4 NAT to internal
networks. IPv6 restores end to end connectivity. Kerberos, unlike Jini
/ River, is ubiquitous (included in all operating systems, for single
sign on), consumes very little processing power, while also providing
authentication and encryption and it works with ONC RPC. Both Kerberos
and ONC RPC are ubiquitous, so are available on all operating systems
and are written in C. NFS is written using ONC RPC.
So it would seem a good option for very low power devices to participate
in a djinn, if a JERI ONC RPC Kerberos implementation existed. There
would of course need to be a discovery protocol, so these devices could
be discovered and smart proxy's registered with a lookup service on
their behalf.
It also seems useful to start testing the JERI Kerberos endpoints again,
these are currently the only endpoints that haven't been tested since
the original Sun Jini team last tested them.
Of course there are lots of other protocols and there is no one size
fits all, the beauty of River is protocols are abstracted behind service
api.
Peter.
On 23/07/2017 1:13 PM, Dan Rollo wrote:
Hi Peter,
I don’t know diddly about Kerberos, but that passive wifi sure looks nifty.
Dan
From: Peter<j...@zeus.net.au>
Subject: On Kerberos Endpoints and other interesting stuff.
Date: July 20, 2017 at 5:22:44 AM EDT
To: "<dev@river.apache.org>"<dev@river.apache.org>
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.
