Issue 2086:  SecurityAdmin Policies (sec-rev)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: Policies in SecurityAdmin are unclear in their interpretations. It is
 clear from discussions we have had in the group, that too many different
 interpretations can ensue. 
 
 
 This is a problem with trying to define security policy in IDL. There
 should be a minimum interface that may be supported that will allow a
 language description to be taken as an argument, that will define the
 policy for the policy object. The query interfaces may be the same.
 
 

Resolution: 
Revised Text: 
Actions taken:
October 15, 1998: received issue
Discussion: 

End of Annotations:=====
Return-Path: <polar@adiron.com>
X-Authentication-Warning: marcy.adiron.com: polar owned process doing
-bs
Date: Thu, 15 Oct 1998 15:02:25 -0400 (EDT)
From: Polar Humenn <polar@adiron.com>
To: issues@omg.org
cc: secsig@omg.org, sec-rev@omg.org
Subject: SecurityAdmin Policies


Issue: Security
Summary:

Policies in SecurityAdmin are unclear in their interpretations. It is
clear from discussions we have had in the group, that too many
different
interpretations can ensue. 


This is a problem with trying to define security policy in IDL. There
should be a minimum interface that may be supported that will allow a
language description to be taken as an argument, that will define the
policy for the policy object. The query interfaces may be the same.

For example, The DomainAccessPolicy has one query operation called

	Security::RightsList
	get_effective_rights(
		in Security::AttributeList attributes
	);

Which tells the access rights for some list of security attributes.

However, the interfaces for describing the policy, namely,
grant_rights,
revoke_rights, are hopelessly left up to an unclear interpretation,
and
restrict the expressability of some policies.

Policies should have the capability to be described by some policy
language more expressive than IDL. We don't have to go and define the
language, it can be implementation and vendor specific. However, we
may be
able to provide a minimum operation for defining security policy such
something like: 

	typedef string PolicyDescription;
	typedef string PolicyLanguage;

	typedef sequence<PolicyLangage> PolicyLanguageList;

	PolicyLanguageList get_supported_languages();

	void
	set_access_policy(
		in PolicyLanguage language,
		in PolicyDescription description
	) raises (
		UnsupportedLanguage,
		InvalidDescription
	);

That way, policies that are more complicated than the ones described
by
the IDL can be expressed, abeit by a proprietary language, but through
a
common interface.

Such languages may become standard or at least published, such that
"Our
DomainAccessPolicy object supports the Vendor XXX's Access Policy
Lanaguge.

		
-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
President                     2-212 Center for Science & Technology
mailto:polar@adiron.com       CASE Center/Syracuse University 
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com


X-Authentication-Warning: marcy.adiron.com: polar owned process doing
-bs
Date: Wed, 10 Mar 1999 10:29:30 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: sec-rev@omg.org
Subject: Re: Open Issues

On 9 Mar 1999, Andre Srinivasan wrote:

> Issue 2086: Yuck.

Any constructive comments?

> Issue 2259: More discussion
About the delegation mode parameter on set_credentials.

I'm confused on this one. 

For a credentials object there is no way to change the
delegation mode of the credentials. So this operation doesn't make
sense,
since you would need special access into the Vault that created the
credentials, destroying the replaceable piece.

The Vault creates Credentials, and Security Contexts to run in the
SECIOP
machine. 

DelegationMode is the delegation capability of the credentials object
when
it is created by the vault. 

The DelegationDirective states whether to actually delegate the
credentials, and this parameter is given in the Vault to
init_security_context. This parameter is currently supplied by using
an
DelegationDirective Policy.

For SSL, Delegation is not an issue.

For mechanisms built on top of SSL, or other security mechanisms, it
might
be, but what are the issues?

-Polar