Issue 2558: ReceivedCredentials. (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: I think we have a further problem representing the received credentials from the server. We have more than just two attributes on received credentials which are more suited to the nature of a client, as opposed to a server/target. We have readonly attribute Credentials accepting_credentials; readonly Security::DelegationState delegation_state; readonly attribute Security::DelegationMode delegation_mode; readonly attribute Security::AssociationOptions association_options_used; What do we do about delegation_state or delegation_mode for received credentials from the server? Resolution: Revised Text: Actions taken: March 29, 1999: received issue March 31, 1999: issue closed, same as 2440 Discussion: End of Annotations:===== X-Authentication-Warning: gothics.adiron.com: polar owned process doing -bs Date: Sat, 27 Mar 1999 16:52:24 -0500 (EST) From: Polar Humenn To: Andre Srinivasan cc: sec-rev@omg.org Subject: ReceivedCredentials. Andre, I think we have a further problem representing the received credentials from the server. We have more than just two attributes on received credentials which are more suited to the nature of a client, as opposed to a server/target. We have readonly attribute Credentials accepting_credentials; readonly Security::DelegationState delegation_state; readonly attribute Security::DelegationMode delegation_mode; readonly attribute Security::AssociationOptions association_options_used; What do we do about delegation_state or delegation_mode for received credentials from the server? Delegation_state can be Security::SecInitiator, but that doesn't make sense. Delegation_Mode can be always Security:SecNoDelegation. Even so, you can put ReceivedCredentials on the invocation credentials list! However, it doesn't make sense to put them on the list if they are really representing some client's view of the target's credentials. We thought of the following approach during the RTF. structure, but before you comment, I don't like it, either. However, I have a better solution below it. This is to refresh your memory and for reference for modifications later. ++++++++++ WHAT WE HAVE NOW +++++++++++++ module Security { enum InvocationCredentialsType { SecOwnCredentials, SecReceivedCredentials }; }; module SecurityLevel2 { inteface Current : SecurityLevel1::Current { ReceivedCredentials get_received_credentials( in CORBA::Object obj ); }; interface Credentials { readonly attribute Security::InvocationCredentialsType credentials_type; }; interface ReceivedCredentials : Credentials { readonly attribute Security::DelegationState delegation_state; readonly attribute Security::DelegationMode delegation_mode; reaondly attribute Credentials accepting_credentials; readonly attribute Security::AssocationOptions association_options_used; }; +++++++++++++++++++++++++++ WHAT WE TALKED ABOUT BUT DIDN'T LIKE ++++++++++++++++++++++++++++++++ interface ReceivedCredentials : Credentials { readonly attribute Security::SecOrientation orientation; readonly attribute Security::AssocationOptions association_options_used; } interface ClientCredentials : ReceivedCredentials { readonly attribute Security::DelegationState delegation_state; readonly attribute Security::DelegationMode delegation_mode; reaondly attribute Credentials accepting_credentials; }; interface ServerCredentials : ReceivedCredentials { readonly attribute Credentials initiating_credentials; }; }; +++++++++++++++++++++++++++++ As I said before, I don't like it either, it's too cumbersome. However, we might be able to introduce a new kind of credentials, and leave received credentials right were it is. The new type "TargetCredentials" will not be allowed or available for "invocation" credentials. (i.e. they will not be allowed be used to make invocations). This might require a couple of different changes. So, what I am proposing is the following inheritance structure: Credentials | ----------------------- | | / \ / \ ReceivedCredentials TargetCredentials First we deprecate the Security module's enum "CredentialType" (no mistake or typeO here, it's really specified as non-pural) because it doesn't fit with the rest of the "pural"-ness of the "Credentials" object type. It's inconsistent Anyway the only reason we needed this type was for the get/set credentials, which we agreed to deprecate as well. So we deprecate CredentialType and its two values, SecInvocationCredentials, and SecNRCredentials. We can get rid of the SecNRCredentials enum value, since non repudiation credentials are an entirely different animal altogther, and it comes from an entirely different place of the security service. However, it's not a problem if it really is included, but semantically I don't see why it should exist. nclude all the types of authentication and association credentials we have: module Security { enum CredentialsType { SecOwnCredentials, SecReceivedCredentials, SecTargetCredentials // new type }; }; Then we get rid of the Security::InvocationCredentialsType. And we use the type values we just created. module SecurityLevel2 { interface Credentials { readonly Security::CredentialsType credentials_type; }; interface TargetCredentials : Credentials { readonly attribute Security::AssociationOptions association_options_used; readonly attribute Credentials initiating_credentials; }; interface Current : SecurityLevel1::Current { TargetCredentials get_target_credentials( in CORBA::Object target ); }; }; I believe this solution would be incredibly cleaner for the need to get a target's credentials. First, look at the semantic implications: 1. TargetCredentials are not allowed on the credentails list of an InvocationCredentialsPolicy. Makes sense and can be enforced by type. 2. The "accepting_credentials" attribute on ReceivedCredentials has the correct semantics. No need for that overloaded name we were looking for at the RTF meeting. 3. The "initiating_credentials" attribute on the TargetCredentials has the correct semantics, as well. Second, all the operations work. However, this fix would require a couple of minor name changes to SecurityReplacable as well to be aligned with the above proposal. The problem is with only one attribute on SecurityContext. interface SecurityContext { readonly attribute SecurityLevel2::ReceivedCredentials is received_credentials; }; This attribute could now only work if the context was a ClientSecurityContext. Therefore I would vote for one of the following changes: 1. A. Deprecate "received_credentials". B. introduce readonly attribute SecurityLevel2::Credentials peer_credentials; and let the examiner narrow to proper type, (i.e. ReceivedCredentials or TargetCredentials) depending on whether the SecurityContext is a ClientSecurityContext or a ServerSecurityContext). OR 2. A. Deprecate "received_credentials" on SecurityContext B. and re-introduce it on ServerSecurityContext readonly attribute SecurityLevel2:ReceivedCredentials received_credentials; C. introduce the following on ClientSecurityContext readonly attribute SecurityLeve2::TargetCredentials target_credentials; To everyone, please respond with *constructive* and *informative* comments. Thank you. ------------------------------------------------------------------- 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