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?
Basically anything you can specify in an existing Java policy file, can
be performed by the RemotePolicy.
So you can take your local policy files on one node and replicate it
across all nodes.
The best way to understand the impact is to trial it in a small djinn first.
You can't perform dynamic proxy grant's to ClassLoader's, this still has
to be done locally (I have a way in mind to attach the Permissions code
requires to the jar file, to make it easy for the client to determine
the proxy's required permissions, but that's another topic).
I've pondered having a logging service, to log SecurityException's,
however the difficulty is one change could cause an avalanche of
logging, a self inflicted denial of service.
Perhaps an AdminLog, that could be obtained through administrable, I'm
not sure.
It would be possible to have a pseudo RemotePolicy service that logs the
updates and prints PermissionGrant's, so an administrator can view
changes as they occur remotely.
Any ideas?
Cheers,
Peter.
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;
}
