On 8/3/2011 3:08 PM, Dan Creswell wrote:
I recall Waldo saying some time ago that systems get harder and harder
to do as you in order from:
(1) Single-thread single machine.
(2) Multi-thread single machine.
(3) Multi-machine.
(4) Multi-machine with security.
On that basis, I'm tempted to say we should make our lives easier by
setting something that limits the amount of heavy-lifting we need
before we have anything to show for it/play with. Thus, I'd say we do,
in order:
(1) We should look at easing the admin burden - in terms of scooping
up exceptions, logging, monitoring and such.
The thing that keeps coming to mind for me, is a visible list of "Exporter",
"Lease", "Transaction" and other "RemoteObject" instances. This could for
example be done through a "TrackedConfiguration" object that would provide a
place to attach JMX or just export it for tracking etc. Everything that
TrackedConfiguration returned could thus have lifecycle visibility as well as
other uses. Later, TrackedConfiguration could be removed from use too.
(2) Sort out a bare bones out of the box experience - minimal configs,
intelligent auto-setup for network interface selection.
Multiple interfaces on one machine is always "hard" to make "simple", but it's
possible to make reasonable guesses. The TrackedConfiguration class, would
actually need to have a higher level interface that would speak to the types of
objects being retrieved so that defaults could be provided.
As in this kind of business:
public abstract class TrackedConfiguration extends ConfigurationFile {
public abstract Exporter getExporterEntry(
String component, String name );
public abstract Endpoint getSSLEndpointEntry(
String component, String name );
public abstract Endpoint getTcpEndpointEntry(
String component, String name );
public abstract ProxyPreparer getPreparerEntry(
String component, String name );
public abstract List<Exporter> activeExporters();
public abstract List<Endpoint> activeEndpoints();
public abstract List<ProxyPreparer> activePreparers();
public abstract List<Remote> activeRemoteObjects();
}
> (3) Security for all the above.
You might then imagine it being a pretty high level sync interface for a few
other things, such as turning on default security doing things like:
public void setRequiresSSL(boolean how);
public void setRequiresSubject( Subject sub );
public void setRequiresPrincipal( Principal prin );
public void setRequiresPermissionForRemoteCode(
boolean how, PermissionCollection perms );
Now, I know and it's right to say on some levels, baking in security
from the start often is what needs to be done but Jini itself managed
without security early on and we probably ought to plan to "throw one
away" (as per Mythical Man Month) as we figure these things out so I
personally believe security can wait.
What I want to try and achieve is to demonstrate that security is not a barrier,
but a convenient necessity. This would be the number one issue, for me to vote
on addressing the simplification thereof.
+1 for doing as much through JMX as possible by default if that's
practical (fear with multiple JVMs on one box a la simulating
distributed services it might get tough).
The com.sun.jini.start mechanism, is what I use all the time now. It's
something that we should try and work on to make it easier to "add services" to.
As I've said before, I have a version of that code that includes a drag-n-drop
desktop deployment interface that would allow us to package the River services
into something that people could deploy trivially and visibly to always get it
"right". There services would need to be built with a specific packaging
mechanism, and I have not "finished" that.
What I did was put together a "jar in a jar" jar: protocol handling support so
that a deployed service could easily be matched with the exact versions of the
platform it was built with so that file systems get out of view for deployment.
Making this happen with maven now, might make a lot of sense.
Gregg
On 3 August 2011 20:48, Gregg Wonderly<[email protected]> wrote:
On 8/2/2011 3:15 AM, Dan Creswell wrote:
How will an administrator know when their djinn has reached equilibrium?
Answer: Probably by observation rather than providing a guaranteed time
period.
Next question: Do your interfaces support the administrator need to
understand their djinn's behaviour?
This is where I think there is a giant "hole" in management for Jini. We
could provide something through JMX (with a jini connector perhaps) as a
"use what others might have" mechanism. But, in the end, it seems like we
really need to have a "local service" that is automatically secured that
services connect to and announce state, exceptions etc. That local service
would be the one with a JMX interface I think. Basically, I still find
boot-strapping services to be frustratingly prolonged because there's so
much "initial" stuff that has to be "right" before something "sane" happens.
If we could standardize such a "local service" and it's interface, then we
might be able to at least provide generic tooling that would make a lot of
things "just work". In the end, that "local service" should feel as easy to
use as "echo 'Help I can't proceed'" does in a shell script.
The big issues, are always about "security" as a starting point. And it's
hard to manage security without some pre-established settings. What do we
all think about a "default" security configuration (such as binding to
localhost, asserting a download permission and using SSL) that fall out of
the APIs (or new APIs) more naturally.
For example, the design of Configuration is great, except for the fact that
you have to provide your own default values, and "property names" are
random, so you have to engineer, yourself, something to "get it right"
before you can get started (the startnow project's PersistentJiniService and
ConfigurableApplication classes were aimed at trying to fill this void.
It seems like we also could use a good desktop ServiceUI client that would
provide good features out of the box to allow application development to be
faster without so many "little bits" being required to get started.
Thoughts?
Gregg Wonderly
On 2 August 2011 01:52, Peter Firmstone<[email protected]> wrote:
Just get some feedback on this potential remote policy service. The main
intent here is to provide a secure centralised policy administrator to
simplify java security policy management for a djinn group. Note this is
new work, so it doesn't yet support encrypted policy files.
I've used code from Apache Harmony to parse standard syntax java policy
files.
Cheers,
Peter.
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.river.api.security;
import java.io.IOException;
import net.jini.security.GrantPermission;
import net.jini.security.policy.UmbrellaGrantPermission;
import org.apache.river.impl.security.policy.util.PolicyParser;
import org.apache.river.impl.security.policy.util.DefaultPolicyParser;
import org.apache.river.impl.security.policy.util.DefaultPolicyScanner;
/**
* RemotePolicy is a service implemented by a Policy Provider, that allows
* the java security Policy to be updated remotely by a djinn group
administrator.
*
* For security purposes, only secure jeri Endpoint's should be used and
must
* require client and server authentication, in addition the proxy must be
a
* reflective proxy only, DownloadPermission should not be granted, which
is
* also beneficial to reduced network load at the administrator client. *
RemotePolicy may be submitted to a lookup service, where an administrator
* client will look it up and replace PermissionGrant's periodically.
*
* To reduce network load, the administrator client may delay updates by
* lazily processing updates in a serial manner. New RemotePolicy
services
* obtained by the administrator client's via RemoteEvent notification
should
* be processed as a priority over policy updates. Eventually a djinn
group
* policy should reach equilibrium where all nodes have had their policy's
* updated.
*
* This policy, in addition to any local policy provider, allows a network
djinn
* administrator to provide a list of PermissionGrant's, from a single or
* replicated remote location, distributed to all nodes in a djinn group
the
* administrator is responsible for.
*
* In addition, replicating administrator clients may register a pseudo
RemotePolicy
* in order to track the primary administrator client and take over in the
* event it fails. Failure may be failure to authenticate or failure to
renew
* a Lease.
*
* RemotePolicy, if it encapsulates an underlying RemotePolicy, does not
* delegate updates to the base RemotePolicy, this is in case an
* implementer wants a number of different layers of RemotePolicy, where
* each layer represents a different administrator role or responsibility.
*
The administrator's subject must hold the necessary permissions in order
* to grant them, including RuntimePermission("getProtectionDomain").
*
* A node may join more than one djinn group, in this case RemotePolicy's
may
* be used as nested basePolicy's.
*
* The intent of RemotePolicy is to simplify granting of DowloadPermission
to
* new signer Certificates and adding new Principals and Permission's to
* distributed policy providers.
*
* Local policy files should be used to restrict the Permissions grantable
* via a RemotePolicy.
*
* PermissionGrant's that are replaced and no longer exist in the
RemotePolicy
* will no longer be implied by the policy.
*
* DefaultPolicyParser has been provided for an administrator client to
* parse standard java format policy file's, to create PermissionGrant's
* custom policy file formats may be used by extending
DefaultPolicyScanner.
*
* @author Peter Firmstone
* @see GrantPermission
* @see UmbrellaGrantPermission
* @see PolicyParser
* @see DefaultPolicyParser
* @see DefaultPolicyScanner
*/
public interface RemotePolicy {
/**
* Replaces the existing RemotePolicy's PermissionGrant's.
*
* The array is defensively copied, the caller, must have
* RuntimePermission("getProtectionDomain")
* as well as GrantPermission or UmbrellaGrantPermission for every
* Permission granted by each PermissionGrant.
*
* In this case the caller will be the client Subject.
*
* These Permissions should be set in the local policy files at the
* RemotePolicy server.
*
* @param policyPermissions
* @throws java.io.IOException
*/
public void replace(PermissionGrant[] policyPermissions) throws
IOException;
}
