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;
}
