Issue 1763:  Credentials issue (sec-rev)
Source:  (, )
Nature:  Revision
Severity:  Critical
Summary: Summary: Credentials do not have a mechanism specification, a delegation mode,
 specification, and an origin specification.
 
 I believe the credentials object may be used to hold the means
 necessary to support a security mechansim. It would be much less
 confusing, and easier to specify, if there is one credentials 
 object per mechanism.
 
 We should state that one credential object supports one
 mechanism type.
 
 

Resolution: 
Revised Text: 
Actions taken:
July 30, 1998: received issue
November 13, 1998: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <www>
Date: Thu, 30 Jul 1998 18:41:43 -0400
From: www
To: juergen@omg.org, web-incoming@omg.org
Subject: WWW Form output

Name: Polar Humenn
Company: Adiron, LLC
Email: polar@adiron.com
Notification: Yes
Specification: Services (Security)
Section: 15.5.5.2
Formal #: who knows
Version: v1.2 draft 
Revision_Date: 5 jan 98
Page: 15-95
Nature: Revision
Severity: Critical
full_desc: Credentials do not have a mechanism specification, a
delegation mode,
specification, and an origin specification.

I believe the credentials object may be used to hold the means
necessary to support a security mechansim. It would be much less
confusing, and easier to specify, if there is one credentials 
object per mechanism.

We should state that one credential object supports one
mechanism type.

Also, some other information is needed on the credentials object.
I propose one of two ways to do this. The first way, is my proposed
solution that can be pondered on. The second is at the end, ready 
for the trash can.

PROPOSAL 1:

Bring back (sort of) the credentials type, only a bit different, 
add the following operations to the credentials object.

enum InvocationCredentialType {
	SecOwnCredentials,
	SecReceivedCredentials
};

interface Credentials {
	attribute readonly Security::InvocationCredentialType
credential_type;
	attribute readonly Security::MechanismType
mechanism;
	attribute readonly Security::DelegationMode
delegation_mode_supported;
	attribute readonly Security::AssociationOptions
options_supported;
	attribute          Security::AssociationOptions
invocation_options;
	attribute          Security::AssociationOptions
options_required;
	...
};

Received Credentials are the way that a 
security context is represetned to the application level. 
It is inherently different
than own credentials in that some more information is needed is 
needed about the context. [Getting rid of security features, of
course].

interface ReceivedCredentials : Credentials {
	attribute readonly Security::AssociationOptions  options_used;
	attribute readonly Security::DelegationState
delegation_state;
};

When the credentials object is of the SecOwnCredential credential
type, 
the mechanism attribute specifies the exact mechanism that will be
used 
when that credentials object is used to initialize a security
context. 
(i.e. make an invocation). The options_spported attribute specifies
the association options that can be used to initialize or
accept a security context. A policy may restrict the use of these 
association options to a logical subset of the association options
in the credentials object when initializing or accepting 
a security context. However, a policy cannot direct the use of this
credentials object should the policy stipulate a logical superset of
the
credentials options_supported. Also, while acting
on the server side, the options_supported attribute stipulates the
options that are supported to accept invocations. Likewise, the 
options_required attribute stipulates the optiosn that are
required to accept invocations. The options_required and
options_supported are used to define assoication options that are 
advertised in an IOR.

The invocation_options and options_required are setable by the
application. However, a CORBA::BAD_PARAM exception will be raised
if an attempt to set these attributes to values that are logical
supersets of the options_supported attribute. Initially at the
time of creation of own credentials, invocation_options,
options_required,
have the same value as options_supported.

The delegation_mode attribute stipulates the delegation
capability as an invocation make.

[Okay, this section on delegation
*****REALLY***** needs to be thoough out well. Delegation cannot
effectively be reasoned about with the current credentials model.
I'll get to that later].

As a server, the delegation_mode attribute stipulates the 
delegation capability supported for accepting an invocation, 
i.e. attributes advertised in an IOR.
[Note that a value of SecNoDelegation, will tell potential clients
that want to delegate their credentials, or use delegated credentials
for that matter, that it is not possible]. Of course,
a server side delegation policy can override this to a logical subset
of the capability. 

The delegation_state attribute is always "SecInitiator"
for "own" credentails.

When the Credentials object is of the SecReceivedCrendentials type,
the credentials object also implements the ReceivedCredentials
interface. The options_used attribute represents the assoication
options that were used to accept and establish the security context,
while the options_supported attribute still specifies the association
options that can be used to make an invocation should delegation on 
these credentials be enabled. The delegation_state signifies whether
the credentials received are that of a delegate or an
initiator. [note:
with some mechanisms, this distinction may not be possible].

=======

Other proposal is to code all these shenanagans into security
attributes, which would be a bear, underspecified, vague, and
completely ridiculous. 
submit: Submit Issue Report