Issue 4290: Problem with CSIv2 and GIOP LocateRequest (corba-rtf) Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: CSIv2 uses GIOP ServiceContexts to associate a security context with a given GIOP message, but the GIOP LocateRequest & LocateReply messages to not have a ServiceContext field to carry the CSIv2 security context information. Thus, it is impossible to use LocateReuest & LocateReply when using CSIv2. Resolution: see above Revised Text: In formal/02-06-01 insert the following section immediately following section 24.5.3: 1. 24.5.4 Server Side Consideration If the target requires client authentication, and the transport does not provide that authentication, then the target should always respond with OBJECT_HERE to LocateRequest messages and defer the real forwarding response until it receives a GIOP Request message. 2. Replace the text in Footnote 11 on page 24-44 by: "CSS can use the Object::validate_connection operation to get the ORB to issue a locate request." Actions taken: April 20, 2001: received issue April 28, 2003: closed issue Discussion: Resolution: From the archive the bottom line concern appears to be that rejecting LocateRequests is bad, since that breaks clients that use the RebindPolicy and validate_connection(). If a client does that, it must use a LocateRequest in order to validate the connection, and if the server rejects LocateRequests, the client can't communicate. A feasible fix to this problem is to have the spec say that if the target requires client authentication, and the transport does not provide that authentication, then the target should always respond with OBJECT_HERE to LocateRequest messages and defer the real forwarding response until it receives a GIOP Request message. This will annoy the client, since it will have to explicitly rebind the connection, but clients have to be coded to do that anyway. This change is a compatible one and pretty much silently improves the usability of the standard. Server sides that are yet to incorporate this change will simply fail to communicate with some clients under the circumstances described in the archive. Servers with the fix will succeed in those cases. End of Annotations:===== Sender: jon@corvette.floorboard.com Message-ID: <3AE0B5EE.B9E13147@floorboard.com> Date: Fri, 20 Apr 2001 15:19:26 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org, issues@omg.org Subject: Problem with CSIv2 and GIOP LocateRequest Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: #F7e9dQld95Djd9`0*!! CSIv2 uses GIOP ServiceContexts to associate a security context with a given GIOP message, but the GIOP LocateRequest & LocateReply messages to not have a ServiceContext field to carry the CSIv2 security context information. Thus, it is impossible to use LocateReuest & LocateReply when using CSIv2. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 30 Apr 2001 13:57:32 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: csiv2-ftf@omg.org, issues@omg.org Subject: Re: Problem with CSIv2 and GIOP LocateRequest References: <3AE0B5EE.B9E13147@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: N+N!!19$!!=V3!!G$~!! Jon, You are correct about the absence of service context in these msgs, but you are not correct when you say "it is impossible to use LocateReuest & LocateReply when using CSIv2". CSIv2 has two channels, the control channel communicated in IORs, and the invocation channel, where requests that sometimes but not always carry service context elements, are sent over sometimes but not always protected transports. So the CSIv2 IOR tags include a way to describe how to set up a confidential association over a protected transport without need to send any service context elements in requests made over this channel. In your example, the target of such an invocation will be something that processes the LocateRequest msg. Take a look at http://cgi.omg.org/pub/csiv2-ftf/draft-adopted-spec.pdf". Section "16.5.3 Client-Side Requirements and "Location Binding" is the closest thing to describing how to do what you are looking for, Ron Jonathan Biggar wrote: > > CSIv2 uses GIOP ServiceContexts to associate a security context with a > given GIOP message, but the GIOP LocateRequest & LocateReply messages to > not have a ServiceContext field to carry the CSIv2 security context > information. Thus, it is impossible to use LocateReuest & LocateReply > when using CSIv2. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Sender: jon@corvette.floorboard.com Message-ID: <3AEDF09B.AED74B22@floorboard.com> Date: Mon, 30 Apr 2001 16:09:15 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo CC: csiv2-ftf@omg.org, interop@omg.org Subject: Re: Problem with CSIv2 and GIOP LocateRequest References: <3AE0B5EE.B9E13147@floorboard.com> <3AEDA78C.2B135BC6@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [SQ!!5ddd9-&-!!o#ld9 Ron Monzillo wrote: > > CSIv2 uses GIOP ServiceContexts to associate a security context with a > > given GIOP message, but the GIOP LocateRequest & LocateReply messages to > > not have a ServiceContext field to carry the CSIv2 security context > > information. Thus, it is impossible to use LocateReuest & LocateReply > > when using CSIv2. > You are correct about the absence of service context in these msgs, but > you are not correct when you say "it is impossible to use LocateReuest & > LocateReply when using CSIv2". > > CSIv2 has two channels, the control channel communicated in IORs, and > the invocation channel, where requests that sometimes but not always > carry service context elements, are sent over sometimes but not always > protected transports. > > So the CSIv2 IOR tags include a way to describe how to set up a > confidential association over a protected transport without need to send > any service context elements in requests made over this channel. In your > example, the target of such an invocation will be something that > processes the LocateRequest msg. > > Take a look at http://cgi.omg.org/pub/csiv2-ftf/draft-adopted-spec.pdf". > Section "16.5.3 Client-Side Requirements and "Location Binding" is the > closest thing to describing how to do what you are looking for, I still feel this is a significant issue. It's not the LocateRequest itself that is the problem, but the information that may be carried in the LocateReply. If the server requires trust in the client, then it has no business responding to a LocateRequest with information that could be considered sensitive, since the LocateRequest can't carry the authentication information that allows the server to establish trust in the client. In light of the current situation with GIOP 1.2, a server that requires trust in the client should always respond to a LocateRequest with OBJECT_HERE (since that effectively gives nothing away) and wait for the client to send the actual request that it can properly authenticate before sending a LOCATION_FORWARD reply. However, that conflicts with the RebindPolicy from the messaging spec, since if a client specifies NO_REBIND or NO_RECONNECT and uses validate_connection, which presumably sends a LocateRequest, the client will receive many more REBIND system exceptions. This isn't fatal, but would be very annoying. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 01 May 2001 09:07:27 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Ron Monzillo , csiv2-ftf@omg.org, interop@omg.org Subject: Re: Problem with CSIv2 and GIOP LocateRequest References: <3AE0B5EE.B9E13147@floorboard.com> <3AEDA78C.2B135BC6@east.sun.com> <3AEDF09B.AED74B22@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: YQNd9?@=e9[F""!CYPd9 Jonathan Biggar wrote: > > Ron Monzillo wrote: > > > > CSIv2 uses GIOP ServiceContexts to associate a security context with a > > > given GIOP message, but the GIOP LocateRequest & LocateReply messages to > > > not have a ServiceContext field to carry the CSIv2 security context > > > information. Thus, it is impossible to use LocateReuest & LocateReply > > > when using CSIv2. > > > You are correct about the absence of service context in these msgs, but > > you are not correct when you say "it is impossible to use LocateReuest & > > LocateReply when using CSIv2". > > > > CSIv2 has two channels, the control channel communicated in IORs, and > > the invocation channel, where requests that sometimes but not always > > carry service context elements, are sent over sometimes but not always > > protected transports. > > > > So the CSIv2 IOR tags include a way to describe how to set up a > > confidential association over a protected transport without need to send > > any service context elements in requests made over this channel. In your > > example, the target of such an invocation will be something that > > processes the LocateRequest msg. > > > > Take a look at http://cgi.omg.org/pub/csiv2-ftf/draft-adopted-spec.pdf". > > Section "16.5.3 Client-Side Requirements and "Location Binding" is the > > closest thing to describing how to do what you are looking for, > > I still feel this is a significant issue. It's not the LocateRequest > itself that is the problem, but the information that may be carried in > the LocateReply. If the server requires trust in the client, then it has > no business responding to a LocateRequest with information that could be > considered sensitive, since the LocateRequest can't carry the > authentication information that allows the server to establish trust in > the client. Jon, If you are worried about only giving object location information to trusted clients, then CSIv2 allows you to establish TrustInClient in the transport (e.g. using SSL) without exchanging service context elements. Depending on the transport you chose, this may require an SSL certificate; which not all clients have. I am not sure that I completely understand your use model, but if you must issue LocateRequests, and you must authenticate clients before responding to such requests, then it seems you can either use SSL to authenticate those clients that have a certificate, use an alternate transport (e.g. SECIOP) that supports a client authentication mechanism accessible to your clients, or do something like you describe below. With CSIv2, you can do all of the above in a single server (if you chose to). I agree that unless there is service context in the msg you send to the location service, you will not be able to authenticate above the transport, which arguably is the authentication mechanism most readly available to clients. I don't disagree with the potential utility of a variant of the LocateRequest msg that can carry service context. However, this is a bit different than saying that LocateRequest cannot be used with CSIv2. Ron > > In light of the current situation with GIOP 1.2, a server that > requires > trust in the client should always respond to a LocateRequest with > OBJECT_HERE (since that effectively gives nothing away) and wait for > the > client to send the actual request that it can properly authenticate > before sending a LOCATION_FORWARD reply. > > However, that conflicts with the RebindPolicy from the messaging > spec, > since if a client specifies NO_REBIND or NO_RECONNECT and uses > validate_connection, which presumably sends a LocateRequest, the > client > will receive many more REBIND system exceptions. This isn't fatal, > but > would be very annoying. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Sender: jon@corvette.floorboard.com Message-ID: <3AF0ABEB.84BD93A2@floorboard.com> Date: Wed, 02 May 2001 17:52:59 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo CC: csiv2-ftf@omg.org, interop@omg.org Subject: Re: Problem with CSIv2 and GIOP LocateRequest References: <3AE0B5EE.B9E13147@floorboard.com> <3AEDA78C.2B135BC6@east.sun.com> <3AEDF09B.AED74B22@floorboard.com> <3AEEB50F.ACE99EAB@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \D&!!!Rp!!d > I still feel this is a significant issue. It's not the LocateRequest > > itself that is the problem, but the information that may be carried in > > the LocateReply. If the server requires trust in the client, then it has > > no business responding to a LocateRequest with information that could be > > considered sensitive, since the LocateRequest can't carry the > > authentication information that allows the server to establish trust in > > the client. > > Jon, > > If you are worried about only giving object location information to > trusted clients, then CSIv2 allows you to establish TrustInClient in the > transport > (e.g. using SSL) without exchanging service context elements. Depending > on the transport you chose, this may require an SSL certificate; which > not all clients have. This is appropriate if your access control model is based only on the authenticated identity of the client, and not on a role-based or label-based scheme. That would requires an authorization token which must be carried in the service context. > I am not sure that I completely understand your use model, but if you > must issue LocateRequests, and you must authenticate clients before > responding to such requests, then it seems you can either use SSL to > authenticate those clients that have a certificate, use an alternate > transport (e.g. SECIOP) that supports a client authentication mechanism > accessible to your clients, or do something like you describe below. > With CSIv2, you can do all of the above in a single server (if you chose > to). You have raised my awareness that LocateRequest/Reply is not completely broken in CSIv2, but I think that the spec must specifically address what a server must do to avoid leaking potentially sensitive information via LocateReply, based on the trust requirements that the server needs. Right now, the spec is entirely silent on the issue. > I agree that unless there is service context in the msg you send to the > location service, you will not be able to authenticate above the > transport, which arguably is the authentication mechanism most readly > available to clients. I don't disagree with the potential utility of a > variant of the LocateRequest msg that can carry service context. I am currently pushing the Interop RTF, which is starting to consider GIOP 1.3 changes to go ahead and add the serve context. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 03 May 2001 11:33:23 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Ron Monzillo , csiv2-ftf@omg.org, interop@omg.org Subject: Re: Problem with CSIv2 and GIOP LocateRequest References: <3AE0B5EE.B9E13147@floorboard.com> <3AEDA78C.2B135BC6@east.sun.com> <3AEDF09B.AED74B22@floorboard.com> <3AEEB50F.ACE99EAB@east.sun.com> <3AF0ABEB.84BD93A2@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _ik!!`eWd9&'^!! > Ron Monzillo wrote: > > > I still feel this is a significant issue. It's not the LocateRequest > > > itself that is the problem, but the information that may be carried in > > > the LocateReply. If the server requires trust in the client, then it has > > > no business responding to a LocateRequest with information that could be > > > considered sensitive, since the LocateRequest can't carry the > > > authentication information that allows the server to establish trust in > > > the client. > > > > Jon, > > > > If you are worried about only giving object location information to > > trusted clients, then CSIv2 allows you to establish TrustInClient in the > > transport > > (e.g. using SSL) without exchanging service context elements. Depending > > on the transport you chose, this may require an SSL certificate; which > > not all clients have. > > This is appropriate if your access control model is based only on the > authenticated identity of the client, and not on a role-based or > label-based scheme. That would requires an authorization token which > must be carried in the service context. Jon, Servers cannot (using CSIv2) require their clients to "push" authorization tokens to them. Servers who wish to make attribute based authorization decisions, may "pull" such attributes from a policy repository (when they are not supplied by the client). > > > I am not sure that I completely understand your use model, but if you > > must issue LocateRequests, and you must authenticate clients before > > responding to such requests, then it seems you can either use SSL to > > authenticate those clients that have a certificate, use an alternate > > transport (e.g. SECIOP) that supports a client authentication mechanism > > accessible to your clients, or do something like you describe below. > > With CSIv2, you can do all of the above in a single server (if you chose > > to). > > You have raised my awareness that LocateRequest/Reply is not completely > broken in CSIv2, but I think that the spec must specifically address > what a server must do to avoid leaking potentially sensitive information > via LocateReply, based on the trust requirements that the server needs. > Right now, the spec is entirely silent on the issue. > The spec does not describe the mechanism definition(s) a target must include in its IORs if it requires trustInClient for LocateRequest messages. That is, the target must require client authentication, either in the transport, or in service context. In the case of LocateRequest, the latter will not be possible, and if it is all that is supported, the target will reject LocateRequests. I can see where it could be useful to say something like this near section 16.5.3. Ron > > I agree that unless there is service context in the msg you send to the > > location service, you will not be able to authenticate above the > > transport, which arguably is the authentication mechanism most readly > > available to clients. I don't disagree with the potential utility of a > > variant of the LocateRequest msg that can carry service context. > > I am currently pushing the Interop RTF, which is starting to consider > GIOP 1.3 changes to go ahead and add the serve context. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Sender: jon@corvette.floorboard.com Message-ID: <3AF19309.4E6B3A7F@floorboard.com> Date: Thu, 03 May 2001 10:19:05 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo CC: csiv2-ftf@omg.org, interop@omg.org Subject: Re: Problem with CSIv2 and GIOP LocateRequest References: <3AE0B5EE.B9E13147@floorboard.com> <3AEDA78C.2B135BC6@east.sun.com> <3AEDF09B.AED74B22@floorboard.com> <3AEEB50F.ACE99EAB@east.sun.com> <3AF0ABEB.84BD93A2@floorboard.com> <3AF17A43.7CFBEE6D@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -H8!!f@2!!P)ld9<~9!! Ron Monzillo wrote: > > This is appropriate if your access control model is based only on the > > authenticated identity of the client, and not on a role-based or > > label-based scheme. That would requires an authorization token which > > must be carried in the service context. > > Jon, > > Servers cannot (using CSIv2) require their clients to "push" > authorization tokens to them. Servers who wish to make attribute based > authorization decisions, may "pull" such attributes from a policy > repository (when they are not supplied by the client). Ah, more illumination. Ok, the only issue is if the target requires authentication of the client, but the transport that the client used doesn't authenticate the client at that level. > The spec does not describe the mechanism definition(s) a target must > include in its IORs if it requires trustInClient for LocateRequest > messages. > > That is, the target must require client authentication, either in > the > transport, or in service context. In the case of LocateRequest, the > latter will not be possible, and if it is all that is supported, the > target will reject LocateRequests. > > I can see where it could be useful to say something like this near > section 16.5.3. Rejecting LocateRequests is bad, since that breaks clients that use the RebindPolicy and validate_connection(). If a client does that, it must use a LocateRequest in order to validate the connection, and if the server rejects LocateRequests, the client can't communicate. It would be better for the spec to say that if the target requires client authentication, and the transport does not provide that authentication, then the target should always respond with OBJECT_HERE to LocateRequest messages and defer the real forwarding response until it receives a GIOP Request message. This will annoy the client, since it will have to explicitly rebind the connection, but clients have to be coded to do that anyway. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org 5. I think Issue 4290: Problem with CSIv2 and GIOP LocateRequest should > be deferred. Date: Wed, 13 Nov 2002 14:29:57 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Proposed resolution for Issue 4290 What do people think of the following resolution for Issue 4290? Thanks, Jishnu. _________________________________________________________________________ Issue 4290: Problem with CSIv2 and GIOP LocateRequest (csiv2-ftf) Click here for this issue's archive. Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: CSIv2 uses GIOP ServiceContexts to associate a security context with a given GIOP message, but the GIOP LocateRequest & LocateReply messages do not have a ServiceContext field to carry the CSIv2 security context information. Thus, it is impossible to use LocateRequest & LocateReply when using CSIv2. Resolution: From the archive the bottom line concern appears to be that rejecting LocateRequests is bad, since that breaks clients that use the RebindPolicy and validate_connection(). If a client does that, it must use a LocateRequest in order to validate the connection, and if the server rejects LocateRequests, the client can't communicate. A feasible fix to this problem is to have the spec say that if the target requires client authentication, and the transport does not provide that authentication, then the target should always respond with OBJECT_HERE to LocateRequest messages and defer the real forwarding response until it receives a GIOP Request message. This will annoy the client, since it will have to explicitly rebind the connection, but clients have to be coded to do that anyway. This change is a compatible one and pretty much silently improves the usability of the standard. Server sides that are yet to incorporate this change will simply fail to communicate with some clients under the circumstances described in the archive. Servers with the fix will succeed in those cases. Revised Text: In formal/02-06-01 insert the following section immediately following section 24.5.3: 24.5.4 Server Side Consideration If the target requires client authentication, and the transport does not provide that authentication, then the target should always respond with OBJECT_HERE to LocateRequest messages and defer the real forwarding response until it receives a GIOP Request message. Actions taken: Incorporate change and close issue X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 13 Nov 2002 11:58:17 -0800 To: Jishnu Mukerji , corba-rtf@omg.org From: Andy Piper Subject: Re: Proposed resolution for Issue 4290 At 02:29 PM 11/13/2002 -0500, Jishnu Mukerji wrote: What do people think of the following resolution for Issue 4290? Is this necessary? Usually the IOR for LocateRequest is synthesized rather than obtained from the server so its impossible to tell the authentication requirements at first blush. raising OBJECT_HERE will not yield those requirements. andy Date: Wed, 13 Nov 2002 20:05:00 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Andy Piper CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Proposed resolution for Issue 4290 Hello Andy, Andy Piper wrote: > Is this necessary? Usually the IOR for LocateRequest is synthesized rather > than obtained from the server so its impossible to tell the authentication > requirements at first blush. raising OBJECT_HERE will not yield those > requirements. If whatever agent is responding to LocateRequest with OBJECT_HERE is based on ORT then it can have all the information that the server exposes in the ORT to build the necessary IOR. H Date: Wed, 13 Nov 2002 15:15:48 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Andy Piper Cc: corba-rtf@omg.org, Jonathan Biggar Subject: Re: Proposed resolution for Issue 4290 I'll let Jon answer that one since I merely extracted the gist of the lengthy discussion that took place between him and Ron Monzillo. Jishnu. Andy Piper wrote: > > At 02:29 PM 11/13/2002 -0500, Jishnu Mukerji wrote: > >What do people think of the following resolution for Issue 4290? > > Is this necessary? Usually the IOR for LocateRequest is synthesized rather > than obtained from the server so its impossible to tell the authentication > requirements at first blush. raising OBJECT_HERE will not yield those > requirements. > > andy X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 13 Nov 2002 13:55:18 -0800 To: Harold Carr From: Andy Piper Subject: Re: Proposed resolution for Issue 4290 Cc: Jishnu Mukerji , corba-rtf@omg.org At 08:05 PM 11/13/2002 +0000, Harold Carr wrote: If whatever agent is responding to LocateRequest with OBJECT_HERE is based on ORT then it can have all the information that the server exposes in the ORT to build the necessary IOR. You've lost me :) What's ORT? Surely the problem is that the client doesn't have any information until its connected to the server and then its too late in this scenario? andy Date: Wed, 13 Nov 2002 22:15:05 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Andy Piper CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Proposed resolution for Issue 4290 Hello Andy, > You've lost me :) What's ORT? Surely the problem is that the client doesn't > have any information until its connected to the server and then its too > late in this scenario? The standalone ORT chapter is ptc/01-08-31. One of its goals is to allow one to build redirection agents using standard APIs. When the redirection agent builds the new IOR, it must be one that includes everything that would have been included if the server had created the IOR itself. That way you know important info (like security) before attempting to connect to the server. Check it out. H Date: Wed, 13 Nov 2002 17:30:03 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Harold Carr Cc: Andy Piper , corba-rtf@omg.org Subject: Re: Proposed resolution for Issue 4290 Harold Carr wrote: > > Hello Andy, > > > You've lost me :) What's ORT? Surely the problem is that the client doesn't > > have any information until its connected to the server and then its too > > late in this scenario? > > The standalone ORT chapter is ptc/01-08-31. One of its goals is to > allow one to build redirection agents using standard APIs. When the > redirection agent builds the new IOR, it must be one that includes > everything that would have been included if the server had created the > IOR itself. That way you know important info (like security) before > attempting to connect to the server. BTW, this is I believe an integral part of CORBA 3.0 also as in formal/02-06-01. It has been integrated completely into the appropriate sections of the CORBA spec as per instructions in ptc/01-08-31. Jishnu. Sender: jon@floorboard.com Date: Wed, 13 Nov 2002 20:05:35 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Andy Piper CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Proposed resolution for Issue 4290 Andy Piper wrote: > > At 02:29 PM 11/13/2002 -0500, Jishnu Mukerji wrote: > >What do people think of the following resolution for Issue 4290? > > Is this necessary? Usually the IOR for LocateRequest is synthesized rather > than obtained from the server so its impossible to tell the authentication > requirements at first blush. raising OBJECT_HERE will not yield those > requirements. Yup, it's necessary, but it shouldn't jeopardize the case you are thinking of. The resolution makes it a requirement that if a client authentication check is necessary, that it only be done for incoming Request messages, not LocateRequest messages. If a "synthesized" IOR doesn't contain any components that specify that client authentication is necessary, then authentication won't happen at that point, but will be deferred until the "real" target IOR is received. Since a client must be prepared to handle a forward response at any time, this fixes the problem at the cost of an extra Request/Response exchange. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Date: Wed, 13 Nov 2002 20:47:24 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: corba-rtf@omg.org Subject: Re: Proposed resolution for Issue 4290 Jishnu Mukerji wrote: > > What do people think of the following resolution for Issue 4290? Overall it looks ok to me. I just noticed that footnote 11 in 24.5.3 is incorrect. There is a standard way to make the client ORB issue a LocateRequest, and that is by calling Object::validate_connection. Why don't we fix that also, since we are visiting this part of the spec anyway. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org