Re: class name?

Gregg Wonderly wrote:

> 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.

Gregg, I try to keep it short but that will be hard I'm afraid.

Strictly spoken a client in Seven would be an object implementing
JiniService that doesn't export any service providers, has no
administration functionality added by the container and doesn't
represent a service event listener (to get service discovery event from
a lookup service in case no pull events are utyilized). That means that
in reality all clients turn out to be servers as well.

But even for such a strict client (which I doubt a ServiceUI desktop
will be) you can configure proxy preparers as part of the configuration
that are represented as an entry in the Configuration as obtained
through the ServiceContext. The ProxyPreparers obtained are dynamic,
i.e. when the underlying configuration is changed the characteristics of
the proxy preparers are too. I already have documentation but as it is
in flux therefore I rather don't want to provide it yet, but if you are
interested I can get you a link.

So the client can add or change on the fly the underlying configuration,
or if you want to do it programmatically the upcoming 1.0 release of
Seven allows the modification of the underlying configuration through
the administration interface. In fact you can write code as part of your
service/client that gives you full control over the container utilizing
the distributed administration interface of Seven or the local
equivalent that uses Bob's slightly enhanced memory endpoints (it
contains a hack to get the client principals as part of the
ServerContext for access control purposes).

As you know the only currently available configuration plugin for Seven
is based on XML, so it is rather easy to write code to manipulate the
XML configuration programmatically, in fact that is what I'm doing in
the ServiceUI for the next major release. And you can obtain a
(distributed) lock on various levels in the container to ensure there is
no conflict if multiple entities want to modify the underlying
configuration. I talked a bit about this in Brussels as this would open
the road to those who would like to make a provisioning platform on top
of Seven as in the past some people of universities contacted me to see
whether they could build these kind of platforms on top of Seven, but
support then was poor.

> 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.

If you mean by constraints InvocationConstraints then I don't belief a
client should have to inspect those constraints in whatever form to
determine whether it will be successful in communication. If you want a
means to pick the right services I'm thinking of a scheme through lookup
attributes (finding by convention), to me this also looks like the best
way to reduce getting too many services in.

I can't recall the exact details of Reef other than that you wanted to
prevent from unmarshalling your services, but if I'm missing something
no doubt you will fill me in.

> 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.

I agree Jini security is often perceived as static, when I was and still
am implementing security for Seven I got totally frustrated by that (I'm
a trial and error person with a short attention span). The good thing
though is that the security framework has been designed with a lot of
dynamics in mind and is in itself not the real roadblock. IMHO it is the
way that people know their Jini world often only as (static) policy and
configuration files that requires a lot of up-front thinking.

I believe it should be able to also temporarily allow access to your
services for a client that can identify as a certain principal. Is there
a specific reason you don't want to use PKI based infrastructure for
these kind of puposes, I know you have some sort of password
authentication, but I wonder whether you also support confidentiality
and integrity of data. Or is that you just want to know who is at the
other end of the wire, without being concerned that it might be an impostor.

> 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 don't see a disconnect Gregg, although I'm not progressed to the point
I can publish an alpha release, but my expectations (based on a PKI or
Kerberos infrastructure) are that enabling security (also discovery) in
a uniform way for all services in Seven should be trivial [1] with the
ability to fine tune where needed (and at runtime) without blocking the
ability to implement scenarios that would be the equivalent of thousands
of lines of configuration and security policy files. I was even thinking
of hiring Amazing Mike (http://en.wikipedia.org/wiki/Mike_Levey) and to
do a competition with Bob S. and Brian M. who have to write the
equivalent in configuration file syntax, but I just found out Mike
unfortunately passed away.

To what extent your role model maps to principals is not clear to me.
Without knowing the details I do wonder why you want to implement your
ACL mechanism as part of an exporter and not just as a dynamic proxy
that 'wraps' the service provider you actually export, that way it would
also work with frameworks that under the hood export in different ways.

[1] If you can create self-signed certificates with a GUI keytool such
as Portecle (http://portecle.sourceforge.net/) there should be no excuse
to not use security where needed. I exclude writing proxy trust
verifiers because I think will remain hard for most people, but enabling
access control and using SSL or Kerberos should be a minimum as well as
not granting AllPermission to all protection domains which happens too
often.

> 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.

I guess there are 2 levels here, the first is system monitoring and the
need to access parts of your infrastructure, and the other one is
application monitoring. I was thinking of application monitor only, for
the first I don't envision the use of Jini.

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

You saw my presentation at JCM10 about "Jini accross the Firewall" the
last pages represented the work that IMHO needs to be done, I'm still
behind that list and also of the opinion that this is the kind of work
that needs to be done as part of River. Some things are rather
straightforward but likely the most important one and that is HTTPS from
the client to an Apache proxy and from there with an AJP13
ServerEndpoint still needs to be done and I don't think that one is trivial.

Lately I've been deep with my nose in the code of the secure endpoints
to really understand what is going on. I can only conclude that the code
is brilliant (I always say that when I can't wrap my head around it
completely) and for an Ajp13ServerEndpoint I guess we need the help of
those who created those endpoints. Also I can't extend my sabbatical
forever so I'm running out of time too ...
--
Mark

--------------------------------------------------------------------------
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]