river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: On Kerberos Endpoints and other interesting stuff.
Date Tue, 25 Jul 2017 10:56:49 GMT
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<jini@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.


Mime
View raw message