river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: RemotePolicy service
Date Wed, 03 Aug 2011 21:10:49 GMT
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.


> On 3 August 2011 20:48, Gregg Wonderly<greggwon@gmail.com>  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<jini@zeus.net.au>    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,
>>>> 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;
>>>> }

View raw message