Issue 2440: Need to get Received Credentials from the Server (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Currently there is now way to examine the credentials of a server. We would like this capability in order to examine the fact that we have authenticated who we expected to contact. Resolution: Close issue 2440 "Need to get Received Credentials from the Server" Revised Text: Add the following section before 15.5.6 "Operations on Object Reference". The TargetCredentials Object A Target Credentials object is the dual of the ReceivedCredentials object as it represents a remote principal’s authentication information for the client’s secure association with a target. The TargetCredentials object may not be used for invocations. The TargetCredentials object represents the secure association to the application. Therefore, the TargetCredentials object contains the properties of that association, such as the Credentials local to the capsule used to initiate the association and the association options in effect. The TargetCredentials object is a locality constrained object, and it contains a credentials_type value of SecTargetCredentials. The SecurityLevel2::TargetCredentials Interface The TargetCredentials interface is defined as follows: interface TargetCredentials : Credentials { readonly attribute Credentials initiating_credentials; readonly attribute Security::AssociationOptions association_options_used; }; initiating_credentials This readonly attribute contains the reference to the credentials object that is used on the initiating side of the negotiation of the secure association with the remote principal. association_options_used This readonly attribute contains the association options in effect for the secure association with the remote principal. Add to page 15-183 Section on attribute to ClientSecurityContext after section on "client_credentials". target_credentials The target_credentials readonly attribute returns the credentials object that represents the secure association with the target. readonly attribute TargetCredentials target_credentials; Return Value The credentials representing authentication of the principal of the target. Remove definition of get_security_mechansims on page 15-111 and 15-116. Appendix A.1, Page 15-308 Remove definition of SecurityMechanismData and SecurityMechanismDataList. Appendix A.4, Remove definition of operation get_security_mechanisms from Current, Page 15-316 Actions taken: February 5, 1999: received issue June 18, 1999: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 4 Feb 1999 17:41:51 -0500 (EST) From: Polar Humenn To: issues@omg.org cc: secsig@omg.org, sec-rev@omg.org Subject: Received Credentials of Server Document:Security RTF 1.5 Severity: Medium Issue: Need to get Received Credentials from the Server Currently there is now way to examine the credentials of a server. We would like this capability in order to examine the fact that we have authenticated who we expected to contact. We have Current::get_security_mechanism_data(), but this really only examines the IOR. The ReceivedCredentials object will work fine for this, with two additions. Also this will address a concern Andre had about getting the received credentials for a server on the client side. Hope this works for you Andre. ReceivedCredentials has an interface called "accepting_credentials". Which on the server side, the ReceivedCredentials represents the security context with a client, this attribute is the credentials object of the server that was used to negotiate the security context. However, on the client side, when received credentials would represent the credentials of the server, "accepting_credentials" doesn't really have the right semantic meaning, because it didn't "accept" the security context, it initiated it. I propose one addition to module Security, two additions to SecurityLevel2::ReceivedCredentials interface, and one addition to the SecurityLevel2::Current interface. Just the addtions are below: module Security { enum SecOrientation { SecClientOrientation, SecServerOrientation }; module SecurityLevel2 { interface ReceivedCredentials { readonly attribute Security::SecOrientation orientation; readonly Credentials initiating_credentials; }; interface Current : SecurityLevel2::Current { ReceivedCredentials get_received_credentials( Object obj ); }; }; When orientation has the value SecClientOrientation, accessing accepting_credentials raises a BAD_PARAM exception; When orientation has the value SecServerOrientation, accessing initiating_credentials raises a BAD_PARAM exception. ------------------------------------------------------------------- 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 From: "Andre Srinivasan" Date: Mon, 8 Feb 1999 08:44:48 -0800 (PST) To: issues@omg.org, sec-rev@omg.org Subject: Re: issue 2440 Security Revision Issue References: <3.0.32.19990205100400.0074ae68@emerald.omg.org> Reply-To: andre@inprise.com X-Disclaimer: These are my statements and opinions. Mine Mine Mine Mine. X-Disclaimer: To assume or infer that these statements represent X-Disclaimer: Inprise Corporation would be, without a doubt, your error. JB> This is issue # 2440 Need to get Received Credentials from the JB> Server JB> Currently there is now way to examine the credentials of a server. JB> We would like this capability in order to examine the fact that we JB> have authenticated who we expected to contact. Is solving this more difficult than changing the SecurityLevel2::Current::received_credentials attribute so that it does not throw a BAD_OPERATION when accessed by a 'pure client'? -andre. Date: Mon, 08 Feb 1999 15:44:00 -0500 From: Bob Kukura Organization: IONA Technologies X-Accept-Language: en To: andre@inprise.com CC: issues@omg.org, sec-rev@omg.org Subject: Re: issue 2440 Security Revision Issue References: <3.0.32.19990205100400.0074ae68@emerald.omg.org> <14015.5248.123307.268717@ahi.visigenic.com> I think I may be confused about this issue. As I understand it, the goal is to provide a way for a client to get a server's authenticated credentials. If so, I don't see how Current, or particularly, SecurityLevel2::Current::received_credentials() is relevant. In a server role, this operation provides the client credentials used to make the invocation (if any) that is active in the current thread. In a client role, there is no similar context associated with a thread. A thread can make invocations on any available object reference, and each might have different server credentials. So wouldn't an API for a client to use to get a server's credentials have to involve the object reference in question? By the way, if anyone cares to explore possible solutions, I'd recommend taking a close look at the messaging specification. For one thing, the RebindPolicy may be useful in order to turn of transparent rebinding so that the client can be ensured that, after it observes what credentials have been authenticated for a particular object reference, those same credential will be used for subsequent invocations. -Bob Andre Srinivasan wrote: > > JB> This is issue # 2440 Need to get Received Credentials from the > JB> Server > > JB> Currently there is now way to examine the credentials of a > server. > JB> We would like this capability in order to examine the fact that > we > JB> have authenticated who we expected to contact. > > Is solving this more difficult than changing the > SecurityLevel2::Current::received_credentials attribute so that it > does not throw a BAD_OPERATION when accessed by a 'pure client'? > > > -andre. From: "Andre Srinivasan" Date: Mon, 8 Feb 1999 13:49:24 -0800 (PST) To: kukura@iona.com Cc: issues@omg.org, sec-rev@omg.org Subject: Re: issue 2440 Security Revision Issue References: <3.0.32.19990205100400.0074ae68@emerald.omg.org> <14015.5248.123307.268717@ahi.visigenic.com> <36BF4C90.64ED7CBE@iona.com> Reply-To: andre@inprise.com X-Disclaimer: These are my statements and opinions. Mine Mine Mine Mine. X-Disclaimer: To assume or infer that these statements represent X-Disclaimer: Inprise Corporation would be, without a doubt, your error. BK> I think I may be confused about this issue. As I understand it, the BK> goal is to provide a way for a client to get a server's authenticated BK> credentials. No, I think you got it and made a very good point. Off to wade through the OMG web site for the messaging spec... -andre. To: Polar Humenn Cc: sec-rev@omg.org Subject: Re: Open Issues References: From: "Andre Srinivasan" Date: 09 Mar 1999 22:53:04 -0800 Lines: 65 Issue 339: I vote to close Issue 357: I vote to defer Issue 374: Isn't this the same as 998? I think we've made this even more difficult with the addition of ReceivedCredentials (since we no longer even have a chance of seeing the delegation chain). Vote to argue. Issue 375: Its moot whether we took care of this in 1.5. I don't recall the conversation so we need to talk about it again. Issue 379: Already closed Issue 714: Vote to close. We'll get back into this with CSIv2. Issue 716: Already closed Issue 998: Same as 374 Issue 1633: Same as 714 Issue 1723: I vote to accept Polar's picture. Issue 2027: I vote to get rid of the policy stuff in Current and stick with get/set credentials. Issue 2033: I vote to Defer. Issue 2063: I was pretty sure everyone liked Polar's suggestion. We should discuss again. Issue 2069: Need to finish meeting with messaging folks. I vote to defer. Issue 2086: Yuck. Issue 2169: I vote to make the editorial change. Issue 2170: I vote to make the editorial change. Issue 2199: I vote to make the editorial change. Issue 2259: More discussion Issue 2344: I vote to make the editorial change Question: Are nulls *allowed* to be passed to locality constrained y are not for non-locality constrained. I would argue that making that distinction is just asking for trouble. Let's be consistent and stick with the no nulls rule. Besides with the Component/Persistence spec, there's a new IDL modifier for locality constrained objects. Issue 2437: I vote no on Polar's recommendataion. We need to discuss this more. Issue 2440: I vote no on Polar's recommendataion. The credentials that the client sees from the server must come from the object reference. Cool, we need another policy. Issue 2451: We need discussion. Issue 2452: We need discussion. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 10 Mar 1999 10:36:26 -0500 (EST) From: Polar Humenn To: sec-rev@omg.org Subject: Re: Open Issues On 9 Mar 1999, Andre Srinivasan wrote: > Issue 2440: I vote no on Polar's recommendataion. The credentials > that the client sees from the server must come from the object > reference. Cool, we need another policy. Your comment leads me to believe that there is a misunderstanding. The interfaces I proposed use the object reference to get the information. This was proposed: interface Current : SecurityLevel1::Current { ReceivedCredentials get_received_credentials( Object obj ); }; which uses the object reference. -Polar Date: Tue, 30 Mar 1999 10:49:15 +1000 (EST) From: Michi Henning To: Paul H Kyzivat cc: Core Revision Task Force Subject: Re: deactivate_object asymmetry Organization: Triodia Technologies Content-ID: On Mon, 29 Mar 1999, Paul H Kyzivat wrote: > Michi, > > Am I missing some critical point about this subject, or does it just > not > make any sense? > > activate_object is given a servant, generates an object id, and then > activates the servant with the object id. Even though it is not an > input > to the call, the object id is the key for the activation. > > To deactivate an object I need somehow to specify which activation > is to > be deactivated. Your revised deactivate_object takes no arguments, > so it > has no way of selecting an activation. Sorry, I didn't make this very clear. deactivate_object() would still need a servant parameter or, alternatively, you could make it an operation on the servant itself, so the servant would be implicit. > I suppose you could have: > > void deactivate_servant(in Servant s) raises(...); > > but this would only work with UNIQUE_ID in effect. Exactly. It just struck me as odd that I can activate a servant and have a unique ID assigned to it automatically, but that, to deactivate it, I have to know the ID. The ID is not, strictly speaking, necessary, unless the POA uses MULTIPLE_ID. I don't think this is major issue -- I mainly noticed the lack of symmetry here. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Cc: Polar Humenn , juergen@omg.org To: sec-rev@omg.org, issues@omg.org Subject: Re: ReceivedCredentials (security issue #2440) References: X-Disclaimer: These are my statements and opinions. Mine Mine Mine Mine. X-Disclaimer: To assume or infer that these statements represent X-Disclaimer: Inprise Corporation would be, without a doubt, your error. From: "Andre Srinivasan" Date: 30 Mar 1999 23:24:27 -0800 Lines: 14 I agree with the idea of introducing a new Credentials type and making the inheritance tree a bit more complicated. I know I'm reversing myself but I also don't see how to deal with the problem. The security context change (choice #1) is still ugly, but it would work. I need to go back and review my notes form RTF 1.5 about the split of security context into the child types. For now, this looks good. -andre.