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