Re: class name?

Mark Brouwer wrote:
> Interesting Gregg, what you might consider over a while is to implement
> it on top Seven. I don't know your exact constraints but Seven is not
> very large in terms of footprint and will provide you with the ability
> to (re)configure all the security requirements [1], things such as
> discovery constraints and proxy preparers configured in Seven are also
> available through an ordinary Configuration object to the service, and
> configuration of Kerberos and SSL has become very imple. As of version
> 0.1.2 it also provides you with the JAR file cache that survives
> restarts of the container for which you also wrote your vhttp protocol
> handler.

How do you deploy a Preparer into a client with Seven?  How does the user know
that they need to use a preparer, and how would the select the appropriate one,
on the fly.

My gosie.dev.java.net project is really trying to be a number of things, but the
one issue that I'm really thinking about, is how a user might be presented with
a service object (obtained from lookup) and be able to inspect constraints and
implementation to know how to "control" it before it's unwrapped. Recall that my
reef.dev.java.net provides the basis that I am using for seeing a service
registration that is still wrapped.

> This is the approach I'm going to take with the Jini Service Browser, if
> you are interested you know where to find me. The thing is that if we
> want to fully utilize Jini security at some point in time IMHO it is
> wise to go with concepts such as proxy preparation et all, regardless of
> the way how we/you configure it. A Jini desktop is very valuable to me
> but I would expect it to not limit my ability to utilize security. From
> what you have told so far security in the ServiceUI desktop seems to
> resolve around granting permissions only and not how to configure
> constraints or how to perform proxy trust verification [2].

I didn't fill in all the details about security which I have some implementation
for.  I do support custom preparation through configuration.  I have connected
to the bantam services for example.  The standing issue though is that you have
to know ahead of time which preparer to use for which service.  That mapping in
a "come as you are" environment is the hard thing to make happen because you
often don't know everything you need, and the JERI stack doesn't really expose
many of the details.  The work that I've done with my reef.dev.java.net was
intended to provide objects that could provide an avenue of exposure into the
constraints and other bits that the service needs/advertises.

> [1] this might require some help from the various Jini utilities as
> there are some limitations at those lower layers.

This is where I think we have a disconnect between the implementation and what
is useful to people.  If security is an important need for me, it should be
trivial to turn on "complete" security to lock things down, and then back off
chosen restrictions (add users to roles, or change limits related to roles) to
allow things to happen as I need them.  I have an ACL based infrastructure that
does this, and I've talked about making this into an Exporter based technology.
  I'm just not finding enough waking hours in the day to do all of the things
that I'd like.  Putting things out on java.net has not resulted in any inflow of
assistance yet, but I keep hoping that people will be interested and find the
stuff useful enough to contribute back.  But, apparently I'm missing the needs
of many in what I've done, so I'm just plowing ahead with the things I need.

My sense is that many are doing that because of the apparently diverse needs.
The confinement that containers provide make it easier for people to take
advantage of others work.

> [2] I'm aware this kind of security is not very often utilized, but I'm
> still hoping that when River actually starts [frustrated typing]
> we can implement Jini across the firewall (in a secure way) so I can
> provide support over the Internet for Seven installations in a 'hidden'
> data center, or that support people otherwise can monitor their
> environment from home or somewhere else. And I bet implementing and
> configuring security becomes an issue then. The same applies of course
> to any other Jini framework, so this is not something Seven specific and
> I don't want to solve this in a Seven proprietary way. It is about time
> we are going to cut the restrictions that confines Jini to the LAN ...
> who is in for it?

I very much want to stop drilling firewall holes and otherwise wasting time with
network issues that are just pointless barriers to productivity.  This firewall
stuff though is a representation of what many expect with security.  They want
to turn everything off with a well known switch, and then turn on the things
that they can.

Because kerberos is built into running processes instead of kernel
infrastructure, I have a hard time turning it on as the only means of auth.
I've experienced hung logins and inability to login.  I remotely support my
applications, and I need to be able to get in if at all possible.  Sometimes,
thread explosions keep sshd from forking even, so even sshing/password-login is
not a complete solution.

What do you think are the most important issues we need to work on to head in
this direction?

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]