Issue 3766: Security needs access to servant and POA (interceptors-rtf) Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: Here are the scenarios needed for interceptor to have access to the servant. 1. We want to provide security to "security unaware" applications. 2. We also want to provide security based on "security aware" applications. (You'll see what I mean later). We need to derive information from a particular object about the security attributes of that object WITHOUT regard to the lifetime or persistence of the object. (IMHO, the security specification made this extreme blunder with the RequiredRights object, I don't want that to happen again) We could use several things about a servant in an interceptor: security attributes "about the servant" owner attributes "about the owner of the servant" (new concept) domain name "domain of the servant" (domain management). Now, the easy thing would say, Set up a domain name and owner data base and just associate it with an object. However, in a generic sense, there isn't an object. If the object is persistent, what happens to this data when the object goes to sleep? What happens if the object is destroyed? Consitency problems all over the place. What we need to do is "derive" the needed information, in a generic sense, from the implementation of a servant. It might be that you have a POA, or a series of POAs, that create references to bank account objects. Depending on the security policy implemented we need to classify the servants (the objects the servant is implementing) into groups. That is, return different owner or domain names derived from information available to the servant. It works very cleanly this way, since all security relevant data is the responsibility of the servant, that is if its transient transient or even in persistent cases, we don't care. We need not make any requirements about persistent or transient servants. The current approach we want to take (for the POA case anyway) is to have a POA policy associated with the creation of a POA or an interceptor. This POA policy has intimate knowledge of the implementations of the servant. Let me illustrate by finding a domain name for a particular servant. We have a policy that has intimate knowledge of the groups of servants underneath it (possibly a POA). interface DomainNamePOAPolicy : CORBA::Policy { DomainNameList get_domain_names( in PortableServer::Servant serv ) raises ( IllegalServant ); }; As a security interceptor, we might like to do the following: RequestInfo ri; // from Interceptor POARequestInfo pri = POARequestInfo.narrow(ri); // for use with a POA POA poa = pri.the_poa(); // POArequestInfo specific attributes Servant serv = pri.the_servant(); // Get the Domain Name finding policy object DomainNamePOAPolicy dnp = DomainNamePOAPolicy.narrow( ri.get_server_policy(DomainNamePOAPolicyType)); DomainName[] dname = dnp.get_domain_name(serv); .. do access control based on domain names Fear and Loathing in ORB land: (I fear the call to get_domain_names() might be orb mediated, and subjected to interception?) Anyway, please excuse the concrete implementation below, but it is just an illustration. Say we want the DomainNamePOAPolicy to base the domain name on some significant part of the servant. Such as grouping all the bank accounts by the salesman under which the bank account is in his jurisdiction. (This IS what policy is all about, of course). class DomainNamePOAPolicy extends _DomainNamePOAPolicyImplBase { DomainName[] get_domain_names(org.omg.PortableServer.Servant serv) { if (serv instanceof BankAccount) { BankAccount ba = (BankAccount) serv; String salesman = ba.salesman(); DomainName[] names = new DomainName[1]; names[0] = convert_salesman_to_domain(salesman); return names; } throw new IllegalServant(); } } We want to derive security information from the attributes in the implementation of the servant, and not store security information about a particular object the servants represent in separate places. The latter approach causes all kinds of consitentcy and lifecycle issues for transient and persistent matters. Using the policy approach as I have outlined solves most of those issues and it is simply mandated that the policy implemented must have intimate knowledge of the servant implementation. We don't care much about the implementation, just the interface of it. This situation is okay, because a security implementer would supply the correct policies to the POA or that would provide the correct information to a security interceptor (i.e. one that had to know about domains) without affecting the implementation of the servant. It's all "plug-and-play". Does this reasoning suffice for the need to gain direct access to the servant? Resolution: Close issue with no change Revised Text: Actions taken: July 21, 2000: received issue April 26, 2010: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 24 Mar 2000 08:37:53 -0500 (EST) From: Polar Humenn To: interceptors-ftf@omg.org, secsig@omg.org Subject: Why Security Interceptors need access to Servant In-Reply-To: <38DAD378.2DE8029@iona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: icf!!hne!!@'I!!gh7e9 Bob and Michi, Here are the scenarios needed for interceptor to have access to the servant. 1. We want to provide security to "security unaware" applications. 2. We also want to provide security based on "security aware" applications. (You'll see what I mean later). We need to derive information from a particular object about the security attributes of that object WITHOUT regard to the lifetime or persistence of the object. (IMHO, the security specification made this extreme blunder with the RequiredRights object, I don't want that to happen again) We could use several things about a servant in an interceptor: security attributes "about the servant" owner attributes "about the owner of the servant" (new concept) domain name "domain of the servant" (domain management). Now, the easy thing would say, Set up a domain name and owner data base and just associate it with an object. However, in a generic sense, there isn't an object. If the object is persistent, what happens to this data when the object goes to sleep? What happens if the object is destroyed? Consitency problems all over the place. What we need to do is "derive" the needed information, in a generic sense, from the implementation of a servant. It might be that you have a POA, or a series of POAs, that create references to bank account objects. Depending on the security policy implemented we need to classify the servants (the objects the servant is implementing) into groups. That is, return different owner or domain names derived from information available to the servant. It works very cleanly this way, since all security relevant data is the responsibility of the servant, that is if its transient transient or even in persistent cases, we don't care. We need not make any requirements about persistent or transient servants. The current approach we want to take (for the POA case anyway) is to have a POA policy associated with the creation of a POA or an interceptor. This POA policy has intimate knowledge of the implementations of the servant. Let me illustrate by finding a domain name for a particular servant. We have a policy that has intimate knowledge of the groups of servants underneath it (possibly a POA). interface DomainNamePOAPolicy : CORBA::Policy { DomainNameList get_domain_names( in PortableServer::Servant serv ) raises ( IllegalServant ); }; As a security interceptor, we might like to do the following: RequestInfo ri; // from Interceptor POARequestInfo pri = POARequestInfo.narrow(ri); // for use with a POA POA poa = pri.the_poa(); // POArequestInfo specific attributes Servant serv = pri.the_servant(); // Get the Domain Name finding policy object DomainNamePOAPolicy dnp = DomainNamePOAPolicy.narrow( ri.get_server_policy(DomainNamePOAPolicyType)); DomainName[] dname = dnp.get_domain_name(serv); .. do access control based on domain names Fear and Loathing in ORB land: (I fear the call to get_domain_names() might be orb mediated, and subjected to interception?) Anyway, please excuse the concrete implementation below, but it is just an illustration. Say we want the DomainNamePOAPolicy to base the domain name on some significant part of the servant. Such as grouping all the bank accounts by the salesman under which the bank account is in his jurisdiction. (This IS what policy is all about, of course). class DomainNamePOAPolicy extends _DomainNamePOAPolicyImplBase { DomainName[] get_domain_names(org.omg.PortableServer.Servant serv) { if (serv instanceof BankAccount) { BankAccount ba = (BankAccount) serv; String salesman = ba.salesman(); DomainName[] names = new DomainName[1]; names[0] = convert_salesman_to_domain(salesman); return names; } throw new IllegalServant(); } } We want to derive security information from the attributes in the implementation of the servant, and not store security information about a particular object the servants represent in separate places. The latter approach causes all kinds of consitentcy and lifecycle issues for transient and persistent matters. Using the policy approach as I have outlined solves most of those issues and it is simply mandated that the policy implemented must have intimate knowledge of the servant implementation. We don't care much about the implementation, just the interface of it. This situation is okay, because a security implementer would supply the correct policies to the POA or that would provide the correct information to a security interceptor (i.e. one that had to know about domains) without affecting the implementation of the servant. It's all "plug-and-play". Does this reasoning suffice for the need to gain direct access to the servant? Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 30 Mar 2000 08:49:36 +1000 (EST) From: Michi Henning To: Polar Humenn cc: interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 61?e9aoJ!!a7Qd9[!dd9 On Fri, 24 Mar 2000, Polar Humenn wrote: > What we need to do is "derive" the needed information, in a generic sense, > from the implementation of a servant. > > It might be that you have a POA, or a series of POAs, that create > references to bank account objects. Depending on the security policy > implemented we need to classify the servants (the objects the servant is > implementing) into groups. That is, return different owner or domain names > derived from information available to the servant. > > It works very cleanly this way, since all security relevant data is the > responsibility of the servant, that is if its transient transient or even > in persistent cases, we don't care. We need not make any requirements > about persistent or transient servants. Polar, just an observation: a single servant can represent multiple CORBA objects simultaneously. So, even with access to the servant from the interceptor, the interface for what you want would have to include the object ID, otherwise the servant cannot know which object's security clearance to use. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 29 Mar 2000 18:00:48 -0500 (EST) From: Polar Humenn To: Michi Henning cc: interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: !imd9di_d9%1id9242!! On Thu, 30 Mar 2000, Michi Henning wrote: > On Fri, 24 Mar 2000, Polar Humenn wrote: > > > What we need to do is "derive" the needed information, in a > generic sense, > > from the implementation of a servant. > > > > It might be that you have a POA, or a series of POAs, that create > > references to bank account objects. Depending on the security > policy > > implemented we need to classify the servants (the objects the > servant is > > implementing) into groups. That is, return different owner or > domain names > > derived from information available to the servant. > > > > It works very cleanly this way, since all security relevant data > is the > > responsibility of the servant, that is if its transient transient > or even > > in persistent cases, we don't care. We need not make any > requirements > > about persistent or transient servants. > > Polar, just an observation: a single servant can represent multiple > CORBA objects simultaneously. So, even with access to the servant > from > the interceptor, the interface for what you want would have to > include > the object ID, otherwise the servant cannot know which object's > security > clearance to use. Ah yes, thanks for pointing that out. I don't suppose that somewhere in this wild abstraction, that a single servant can be associated with different POA's, either, eh? So if we really wanted to access information from the object implementation we really need the adapter_id, object_id, and the servant. True? -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 30 Mar 2000 09:04:53 +1000 (EST) From: Michi Henning To: Polar Humenn cc: interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 75De9]@i!!89jd9~,p!! On Wed, 29 Mar 2000, Polar Humenn wrote: > > Polar, just an observation: a single servant can represent multiple > > CORBA objects simultaneously. So, even with access to the servant from > > the interceptor, the interface for what you want would have to include > > the object ID, otherwise the servant cannot know which object's security > > clearance to use. > > Ah yes, thanks for pointing that out. > > I don't suppose that somewhere in this wild abstraction, that a single > servant can be associated with different POA's, either, eh? A servant can be associated with more than one POA, at least according to the spec. However, doing this is problematic at least. None of the serialization guarantees apply anymore in this case, and the semantics are a bit dubious. So, I wouldn't go out of my way to permit a servant to have more than one POA. > So if we > really wanted to access information from the object implementation > we > really need the adapter_id, object_id, and the servant. True? I'm not sure whether the adapter_id would actually be necessary (unless the servant may want to look up POA policies or some such). Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Bill Binko To: "'Polar Humenn'" , Michi Henning Cc: interceptors-ftf@omg.org, secsig@omg.org Subject: RE: Why Security Interceptors need access to Servant Date: Wed, 29 Mar 2000 18:06:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /=;!!~J=!!S/3e9Fm6!! Polar, I'm coming into this late, but... Are you in an upcall here? More specifically, is the POA Current (::PortableServer::Current) available at your interceptor? It has accessors for object_id() and poa() and I would be a strong proponent (for other reasons) to add a get_servant() method to that interface. Binko >-----Original Message----- >From: Polar Humenn [mailto:polar@adiron.com] >Sent: Wednesday, March 29, 2000 6:01 PM >To: Michi Henning >Cc: interceptors-ftf@omg.org; secsig@omg.org >Subject: Re: Why Security Interceptors need access to Servant > > >On Thu, 30 Mar 2000, Michi Henning wrote: > >> On Fri, 24 Mar 2000, Polar Humenn wrote: >> >> > What we need to do is "derive" the needed information, in >a generic sense, >> > from the implementation of a servant. >> > >> > It might be that you have a POA, or a series of POAs, that create >> > references to bank account objects. Depending on the >security policy >> > implemented we need to classify the servants (the objects >the servant is >> > implementing) into groups. That is, return different owner >or domain names >> > derived from information available to the servant. >> > >> > It works very cleanly this way, since all security >relevant data is the >> > responsibility of the servant, that is if its transient >transient or even >> > in persistent cases, we don't care. We need not make any >requirements >> > about persistent or transient servants. >> >> Polar, just an observation: a single servant can represent multiple >> CORBA objects simultaneously. So, even with access to the >servant from >> the interceptor, the interface for what you want would have >to include >> the object ID, otherwise the servant cannot know which >object's security >> clearance to use. > >Ah yes, thanks for pointing that out. > >I don't suppose that somewhere in this wild abstraction, that a single >servant can be associated with different POA's, either, eh? So if we >really wanted to access information from the object implementation we >really need the adapter_id, object_id, and the servant. True? > >-Polar > > >------------------------------------------------------------------- >Polar Humenn Adiron, LLC >mailto:polar@adiron.com 2-212 CST >Phone: 315-443-3171 Syracuse, NY 13244-4100 >Fax: 315-443-4745 http://www.adiron.com > Date: Thu, 30 Mar 2000 09:14:22 +1000 (EST) From: Michi Henning To: Polar Humenn cc: interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: A-;e94j@!!glf!!i:-!! On Wed, 29 Mar 2000, Polar Humenn wrote: > > I'm not sure whether the adapter_id would actually be necessary (unless > > the servant may want to look up POA policies or some such). > > That, of course, is providing *anything* can find a pesty POA with the > "adapter_id", of which I think it cannot, correct? Yes. The adapter_id is an octet sequence with unspecified contents. As long as the contents remain opaque, there really is no portable way to use the adapter_id to locate the adapter. (Which begs the question: why is an adapter_id provided if I can't use it?) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 30 Mar 2000 09:14:58 +1000 (EST) From: Michi Henning To: Bill Binko cc: "'Polar Humenn'" , interceptors-ftf@omg.org, secsig@omg.org Subject: RE: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Cj)!!%oad9)WYd9:7!"! On Wed, 29 Mar 2000, Bill Binko wrote: > Polar, > I'm coming into this late, but... > > Are you in an upcall here? More specifically, is the POA >Current > (::PortableServer::Current) available at your interceptor? It has >accessors > for object_id() and poa() and I would be a strong proponent (for >other > reasons) to add a get_servant() method to that interface. I think we have already established that an interceptor cannot expect the POA current to be set up. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 29 Mar 2000 18:15:53 -0500 (EST) From: Polar Humenn To: Michi Henning cc: interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: _kZd9\"O!!:%0e9l$2!! On Thu, 30 Mar 2000, Michi Henning wrote: > On Wed, 29 Mar 2000, Polar Humenn wrote: > > > > Polar, just an observation: a single servant can represent > multiple > > > CORBA objects simultaneously. So, even with access to the > servant from > > > the interceptor, the interface for what you want would have to > include > > > the object ID, otherwise the servant cannot know which object's > security > > > clearance to use. > > > > Ah yes, thanks for pointing that out. > > > > I don't suppose that somewhere in this wild abstraction, that a > single > > servant can be associated with different POA's, either, eh? > > A servant can be associated with more than one POA, at least > according to > the spec. However, doing this is problematic at least. None of the > serialization guarantees apply anymore in this case, and the > semantics > are a bit dubious. So, I wouldn't go out of my way to permit a > servant > to have more than one POA. Okay, that would be one step toward implying that some abuse shouldn't happen. > > So if we > > really wanted to access information from the object implementation > > we > > really need the adapter_id, object_id, and the servant. True? > > I'm not sure whether the adapter_id would actually be necessary > > (unless > the servant may want to look up POA policies or some such). That, of course, is providing *anything* can find a pesty POA with the "adapter_id", of which I think it cannot, correct? Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 30 Mar 2000 09:19:44 +1000 (EST) From: Michi Henning To: Polar Humenn cc: interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: )!pd9S7Ee9095e98> > Yes. The adapter_id is an octet sequence with unspecified contents. As > > long as the contents remain opaque, there really is no portable way to use the > > adapter_id to locate the adapter. (Which begs the question: why is an > > adapter_id provided if I can't use it?) > > I think the intent was to provide a unique identifier for an object within > a server. Sure. But that identifier doesn't help me if I can't map it to an instance. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 29 Mar 2000 18:21:37 -0500 (EST) From: Polar Humenn To: Bill Binko cc: Michi Henning , interceptors-ftf@omg.org, secsig@omg.org Subject: RE: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: @0H!!6iFe9:QLe9]Cdd9 On Wed, 29 Mar 2000, Bill Binko wrote: > Polar, > I'm coming into this late, but... > > Are you in an upcall here? I never know what is an "upcall". I'm still trying to figure out "upload" and "download". > More specifically, is the POA Current > (::PortableServer::Current) available at your interceptor? I would imagine so, but probably only a certain interceptor point. Anybody care to comment? > It has accessors > for object_id() and poa() and I would be a strong proponent (for > other > reasons) to add a get_servant() method to that interface. If that is possible, sure. Or we could go the way of putting them on the RequestInfo object. -Polar > > Binko > > >-----Original Message----- > >From: Polar Humenn [mailto:polar@adiron.com] > >Sent: Wednesday, March 29, 2000 6:01 PM > >To: Michi Henning > >Cc: interceptors-ftf@omg.org; secsig@omg.org > >Subject: Re: Why Security Interceptors need access to Servant > > > > > >On Thu, 30 Mar 2000, Michi Henning wrote: > > > >> On Fri, 24 Mar 2000, Polar Humenn wrote: > >> > >> > What we need to do is "derive" the needed information, in > >a generic sense, > >> > from the implementation of a servant. > >> > > >> > It might be that you have a POA, or a series of POAs, that > create > >> > references to bank account objects. Depending on the > >security policy > >> > implemented we need to classify the servants (the objects > >the servant is > >> > implementing) into groups. That is, return different owner > >or domain names > >> > derived from information available to the servant. > >> > > >> > It works very cleanly this way, since all security > >relevant data is the > >> > responsibility of the servant, that is if its transient > >transient or even > >> > in persistent cases, we don't care. We need not make any > >requirements > >> > about persistent or transient servants. > >> > >> Polar, just an observation: a single servant can represent > multiple > >> CORBA objects simultaneously. So, even with access to the > >servant from > >> the interceptor, the interface for what you want would have > >to include > >> the object ID, otherwise the servant cannot know which > >object's security > >> clearance to use. > > > >Ah yes, thanks for pointing that out. > > > >I don't suppose that somewhere in this wild abstraction, that a > single > >servant can be associated with different POA's, either, eh? So if > we > >really wanted to access information from the object implementation > we > >really need the adapter_id, object_id, and the servant. True? > > > >-Polar > > > > > >------------------------------------------------------------------- > >Polar Humenn Adiron, LLC > >mailto:polar@adiron.com 2-212 CST > >Phone: 315-443-3171 Syracuse, NY 13244-4100 > >Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST 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, 29 Mar 2000 18:23:17 -0500 (EST) From: Polar Humenn To: Michi Henning cc: interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: T=Zd97%^d9)kFe9^X#"! On Thu, 30 Mar 2000, Michi Henning wrote: > On Wed, 29 Mar 2000, Polar Humenn wrote: > > > > I'm not sure whether the adapter_id would actually be necessary > (unless > > > the servant may want to look up POA policies or some such). > > > > That, of course, is providing *anything* can find a pesty POA with > the > > "adapter_id", of which I think it cannot, correct? > > Yes. The adapter_id is an octet sequence with unspecified > contents. As > long as the contents remain opaque, there really is no portable way > to use the > adapter_id to locate the adapter. (Which begs the question: why is > an > adapter_id provided if I can't use it?) I think the intent was to provide a unique identifier for an object within a server. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST 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, 29 Mar 2000 18:31:35 -0500 (EST) From: Polar Humenn To: Michi Henning cc: interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: \bm!!W@2!!:ND!!']fd9 On Thu, 30 Mar 2000, Michi Henning wrote: > On Wed, 29 Mar 2000, Polar Humenn wrote: > > > > Yes. The adapter_id is an octet sequence with unspecified > contents. As > > > long as the contents remain opaque, there really is no portable > way to use the > > > adapter_id to locate the adapter. (Which begs the question: why > is an > > > adapter_id provided if I can't use it?) > > > > I think the intent was to provide a unique identifier for an > object within > > a server. > > Sure. But that identifier doesn't help me if I can't map it to an > instance. True. I guess. To have a unique id for an object would be helpful, but only if the interceptor knew what the structure of the adapter id was in order to make the right decision about what to key off of it. At that point, I guess the interceptor wouldn't be portable now, would it? :) what to do? -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 30 Mar 2000 09:35:24 +1000 (EST) From: Michi Henning To: Polar Humenn cc: interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: WdA!!ML&!!TGQ!!T^Me9 On Wed, 29 Mar 2000, Polar Humenn wrote: > True. I guess. > > To have a unique id for an object would be helpful, but only if the > interceptor knew what the structure of the adapter id was in order > to make > the right decision about what to key off of it. At that point, I > guess the > interceptor wouldn't be portable now, would it? :) > > what to do? No idea... Someone else suggested to make an adapter base class, so I could try a downcast. However, I think it was Bob who didn't like this idea because of the coupling it creates. We could do something that, albeit, is a bit ugly: pass in an adapter type identifier of some kind, similar to the vendor-specific tag identifiers. That could be used by the interceptor to identify the adapter type, which, in turn, could be used as a handle to interpret the adapter_id octets correctly. But it's clumsy and I can't say I like much... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <38E293BF.DA783C85@floorboard.com> Date: Wed, 29 Mar 2000 15:37:35 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Michi Henning , interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *^7e9p+%"!JDOd9T(!e9 Polar Humenn wrote: > > Polar, just an observation: a single servant can represent multiple > > CORBA objects simultaneously. So, even with access to the servant from > > the interceptor, the interface for what you want would have to include > > the object ID, otherwise the servant cannot know which object's security > > clearance to use. > > Ah yes, thanks for pointing that out. > > I don't suppose that somewhere in this wild abstraction, that a single > servant can be associated with different POA's, either, eh? So if we > really wanted to access information from the object implementation we > really need the adapter_id, object_id, and the servant. True? Unfortunatly yes. I don't think it is wise to use a servant in more than one POA, but it is legal. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 29 Mar 2000 19:02:25 -0500 (EST) From: Polar Humenn To: Michi Henning cc: interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Y0^!!??ad9bE[!!B/Pe9 On Thu, 30 Mar 2000, Michi Henning wrote: > On Wed, 29 Mar 2000, Polar Humenn wrote: > > > True. I guess. > > > > To have a unique id for an object would be helpful, but only if > the > > interceptor knew what the structure of the adapter id was in order > to make > > the right decision about what to key off of it. At that point, I > guess the > > interceptor wouldn't be portable now, would it? :) > > > > what to do? > > No idea... Someone else suggested to make an adapter base class, so > I could > try a downcast. However, I think it was Bob who didn't like this > idea > because of the coupling it creates. I can't remember what the problem was for extending the RequestInfo interface to a POA RequestInfo interface that would get you the POA and the Servant. That does not proclude that the RequestInfo interface can be be extended for other different adapters as well. However, it just might mean that the extentions attributes would only be available at an interceptor point that is determined to have located both the POA and the Servant. > We could do something that, albeit, is a bit ugly: pass in an adapter > type identifier of some kind, similar to the vendor-specific tag identifiers. > That could be used by the interceptor to identify the adapter type, which, > in turn, could be used as a handle to interpret the adapter_id octets > correctly. But it's clumsy and I can't say I like much... Seems like jumping through hoops to get what we need above. I still think there is a need for a unique id for an object, at least within a server. Whether portable or not, the intercetor could be written with a particular vendor in mind and have knowledge of the format of the adapter id and object id. Interceptors that want to associate assocation access control information that way need some implementation specific way of hanging stuff off of ids anyway, lest all ids are created the same way. (something I think is impractical and impossible to enforce). However, if one wants to be truely portable, the information on which to hang access control information must come from the servant in a standard way. We can use POA policies for that, as long as we can get the policies from the POA and feed the servant (and object_id? and adapter_id) to a query operation on the Policy retrieve the access control information from the servant implementation. I believe this can work, we just need to be able to get ahold of the servant. Correct? Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Sender: juergen@emerald.omg.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 30 Mar 2000 09:57:28 -0500 To: Michi Henning , Polar Humenn From: Juergen Boldt Subject: Re: Why Security Interceptors need access to Servant Cc: interceptors-ftf@omg.org, secsig@omg.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ;ePd9BAhd9XGXd90p]d9 Hi all, want an issue number for this thread? -Juergen At 08:49 AM 3/30/2000 +1000, Michi Henning wrote: >On Fri, 24 Mar 2000, Polar Humenn wrote: > >> What we need to do is "derive" the needed information, in a generic sense, >> from the implementation of a servant. >> >> It might be that you have a POA, or a series of POAs, that create >> references to bank account objects. Depending on the security policy >> implemented we need to classify the servants (the objects the servant is >> implementing) into groups. That is, return different owner or domain names >> derived from information available to the servant. >> >> It works very cleanly this way, since all security relevant data is the >> responsibility of the servant, that is if its transient transient or even >> in persistent cases, we don't care. We need not make any requirements >> about persistent or transient servants. > >Polar, just an observation: a single servant can represent multiple >CORBA objects simultaneously. So, even with access to the servant from >the interceptor, the interface for what you want would have to include >the object ID, otherwise the servant cannot know which object's security >clearance to use. > > Cheers, > > Michi. >-- >Michi Henning +61 7 3891 5744 >Object Oriented Concepts +61 4 1118 2700 (mobile) >Suite 4, 904 Stanley St +61 7 3891 5009 (fax) >East Brisbane 4169 michi@ooc.com.au >AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html > ================================================================ Juergen Boldt Senior Member of Technical Staff Object Management Group Tel. +1-781 444 0404 ext. 132 250 First Avenue, Suite 201 Fax: +1-781 444 0320 Needham, MA 02494, USA Email: juergen@omg.org ================================================================ From: Paul Kyzivat To: interceptors-ftf@omg.org, secsig@omg.org Subject: RE: Why Security Interceptors need access to Servant Date: Thu, 30 Mar 2000 18:52:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: nXL!!ochd9P@Ud9[Ybd9 I think I missed a bunch of messages when I was having trouble with mail earlier in the week, so I may not fully understand what was discussed here. I agree with the observation that a servant may be associated with more than one poa, though the implications of that seem not to have been considered by the designers. It would probably be unwise to do anything very complicated that way, but it doesn't present problems in simple cases. (For instance, stateless servants.) It really isn't our problem. More interesting is that servants may rely on POACurrent. This is quite likely to be the case with default servants. If a servant depends on POACurrent, and that isn't set up during an interceptor, then the interceptor can't call methods on the servant that depend on it. In some sense this isn't our problem either. It is user written interceptor code that has decided to call the servant, and it will have a certain set of groundrules to work within. This is a non-poa-mediated call, and will suffer the same problems as any other non-mediated call. So, we at least have the option of telling people not to do it if it hurts. But if this is going to be a common use case, and it presents problems in implementing a useful security service, then we may need to set up POACurrent in such a way that this can be a POA mediated call. On the broader question - I think it is essential that the security interceptors have a *reasonable* and *convenient* way to get access to the POA (if there is one) and the Servant. They are going to be needed to access security policies on the POA and to gather data from the servant needed to decide domain membership. (The exact means to obtain this information are negotiable.) Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Wednesday, March 29, 2000 6:05 PM > To: Polar Humenn > Cc: interceptors-ftf@omg.org; secsig@omg.org > Subject: Re: Why Security Interceptors need access to Servant > > > On Wed, 29 Mar 2000, Polar Humenn wrote: > > > > Polar, just an observation: a single servant can > represent multiple > > > CORBA objects simultaneously. So, even with access to the > servant from > > > the interceptor, the interface for what you want would > have to include > > > the object ID, otherwise the servant cannot know which > object's security > > > clearance to use. > > > > Ah yes, thanks for pointing that out. > > > > I don't suppose that somewhere in this wild abstraction, > that a single > > servant can be associated with different POA's, either, eh? > > A servant can be associated with more than one POA, at least > according to > the spec. However, doing this is problematic at least. None of the > serialization guarantees apply anymore in this case, and the semantics > are a bit dubious. So, I wouldn't go out of my way to permit a servant > to have more than one POA. > > > So if we > > really wanted to access information from the object > implementation we > > really need the adapter_id, object_id, and the servant. True? > > I'm not sure whether the adapter_id would actually be > necessary (unless > the servant may want to look up POA policies or some such). > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 28 Jun 2000 08:58:58 -0230 From: Matthew Newhook To: Michi Henning Cc: Polar Humenn , interceptors-ftf@omg.org, secsig@omg.org Subject: Re: Why Security Interceptors need access to Servant Message-ID: <20000628085858.A30194@ooc.com> References: Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: ((Fe9M?5e9fR0!!^0/!! Hi, On Thu, Mar 30, 2000 at 09:14:22AM +1000, Michi Henning wrote: > On Wed, 29 Mar 2000, Polar Humenn wrote: > > > > I'm not sure whether the adapter_id would actually be necessary (unless > > > the servant may want to look up POA policies or some such). > > > > That, of course, is providing *anything* can find a pesty POA with the > > "adapter_id", of which I think it cannot, correct? > > Yes. The adapter_id is an octet sequence with unspecified contents. As > long as the contents remain opaque, there really is no portable way to use the > adapter_id to locate the adapter. (Which begs the question: why is an > adapter_id provided if I can't use it?) Actually, I don't understand what the problem is. Given an adapter_id from an interceptor I can find the POA that has this adapter_id -- what's the issue here? > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA >http://www.ooc.com.au/staff/michi-henning.html Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Why Security Interceptors need access to Servant Date: Wed, 28 Jun 2000 14:35:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: >`#!!4CAe9+o2e9\di!! > From: Matthew Newhook [mailto:matthew@ooc.com] > Actually, I don't understand what the problem is. Given an adapter_id > from an interceptor I can find the POA that has this adapter_id -- > what's the issue here? How? Date: Wed, 28 Jun 2000 16:33:44 -0230 From: Matthew Newhook To: Paul Kyzivat Cc: interceptors-ftf@omg.org Subject: Re: Why Security Interceptors need access to Servant Message-ID: <20000628163344.A4195@ooc.com> References: <9B164B713EE9D211B6DC0090273CEEA926BF0D@bos1.noblenet.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BF0D@bos1.noblenet.com> Content-Type: text/plain; charset=us-ascii X-UIDL: j_6e9=*Pe9/,0!!9J_!! Hi, On Wed, Jun 28, 2000 at 02:35:19PM -0400, Paul Kyzivat wrote: > > From: Matthew Newhook [mailto:matthew@ooc.com] > > > Actually, I don't understand what the problem is. Given an adapter_id > > from an interceptor I can find the POA that has this adapter_id -- > > what's the issue here? > > How? Traverse the POA heirarchy? Given the root POA you can search all children. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Why Security Interceptors need access to Servant Date: Thu, 29 Jun 2000 07:56:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: hMPe9kR6!!k9Be9JHA!! I was afraid you were going to say that. This is a need that must be met in a practical way, not just theoretically. It appears that in many practical cases every invocation will need to make an access decision by consulting the POA and probably the servant as well. Traversing the POA hierarchy to find the POA makes no sense in that context. In fact, I don't consider requiring the use of a map indexed by octet sequence to be much better. The ORB clearly knows what adapter in involved at the interception point. We need some way to make this directly available to the interceptor. Paul > -----Original Message----- > From: Matthew Newhook [mailto:matthew@ooc.com] > Sent: Wednesday, June 28, 2000 3:04 PM > To: Paul Kyzivat > Cc: interceptors-ftf@omg.org > Subject: Re: Why Security Interceptors need access to Servant > > > Hi, > > On Wed, Jun 28, 2000 at 02:35:19PM -0400, Paul Kyzivat wrote: > > > From: Matthew Newhook [mailto:matthew@ooc.com] > > > > > Actually, I don't understand what the problem is. Given > an adapter_id > > > from an interceptor I can find the POA that has this adapter_id -- > > > what's the issue here? > > > > How? > > Traverse the POA heirarchy? Given the root POA you can search all > children. > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > Date: Thu, 29 Jun 2000 10:06:16 -0230 From: Matthew Newhook To: Paul Kyzivat Cc: interceptors-ftf@omg.org Subject: Re: Why Security Interceptors need access to Servant Message-ID: <20000629100615.A7603@ooc.com> References: <9B164B713EE9D211B6DC0090273CEEA926BF0F@bos1.noblenet.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BF0F@bos1.noblenet.com> Content-Type: text/plain; charset=us-ascii X-UIDL: (b`!!`X?!!3+p!!b]bd9 Hi, On Thu, Jun 29, 2000 at 07:56:37AM -0400, Paul Kyzivat wrote: > I was afraid you were going to say that. > This is a need that must be met in a practical way, not just theoretically. > It appears that in many practical cases every invocation will need to > make an access decision by consulting the POA and probably the servant as > well. > Traversing the POA hierarchy to find the POA makes no sense in that context. > > In fact, I don't consider requiring the use of a map indexed by octet > sequence > to be much better. The ORB clearly knows what adapter in involved at the > interception point. We need some way to make this directly available to the > interceptor. A more obvious solution that comes to mind is to make the POACurrent available from within an the receive_request invocation... I'm not sure whether we can actually make it available from within the receive_request_service_contexts invocation, however. If "Servant get_servant();" was added to the POACurrent interface then this would seem to fit the bill... > Paul Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA23942 for ; Thu, 29 Jun 2000 08:38:09 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id IAA96258 for ; Thu, 29 Jun 2000 08:59:35 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690D.00475E9B ; Thu, 29 Jun 2000 08:59:32 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <8525690D.0047556A.00@d54mta03.raleigh.ibm.com> Date: Thu, 29 Jun 2000 08:58:05 -0400 Subject: Re: Why Security Interceptors need access to Servant Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: -Wbd9*@jd9OFF!!?%;e9 Matthew Newhook on 06/29/2000 05:06:16 AM > > If "Servant get_servant();" was added to the POACurrent interface then > this would seem to fit the bill... > This was actually requested by Don Flynn in Oslo. He was tasked with opening an issue describing security's particular use case. The folks in attendance did not see any problem with supplying this. Russell Butek butek@us.ibm.com Date: Thu, 29 Jun 2000 11:20:16 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: interceptors-ftf@omg.org, Polar Humenn , Don Flinn Subject: Re: Why Security Interceptors need access to Servant References: <8525690D.0047556A.00@d54mta03.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~Fgd9EYHe9!E9!!XT@!! As you can probably tell, I have been reacting rather negatively to all these changes being considered by the Interceptors FTF. We worked hard during the entire submission process, and particularly at the start with our initial submission and the early work on the joint submisssion, to make sure that the approach taken would be compatable with pluggable ORB architectures. We still consider it a requirement that the Portable Interceptors APIs do not expose object adapter or transport specifics, that they be implementable without requiring extra interactions between the core, the object adapters, and the transports, and that they favor a style of interceptor implementation that does not become OA or transport dependent. I have no problem with adding a POACurrent::get_servant operation. But I don't think its reasonable to require the POACurrent to be setup during all interceptor callouts during a server side invocation. This might be doable in a monolithic ORB where the core, transport, and POA are intertwined. But in a plugable ORB architecture, having the core call into the POA to setup POACurrent before all other intercept points would add significant overhead. In our case, it is not a problem to make the POACurrent available during the receive_request intercept point, but making it available from the other server side intercept points would have serious performance and architectural implications. Would making POACurrent available just during receive_request, combined with a POACurrent::get_servant operation, meet security's requirments? Looking back at Polar's original email that started this thread, I think his scenario would then be workable, provided that the Servant parameter was elimited from his DomainNamePOAPolicy::get_domain_names operation signature. The Policy could then be renamed DomainNamePolicy, since it would no longer be POA specific. An implementation supplied by a POA based application would access the POACurrent to get the servant, object_id, or whatever it wants to use to map to the object's DomainNameList. An implementation of the policy for a different object adapter could use that adapter's Current to get whatever information it needs. This approach seems to allow decoupling of the security APIs and the security interceptor implementation from the POA APIs, both of which we consider very important. -Bob butek@us.ibm.com wrote: > > Matthew Newhook on 06/29/2000 05:06:16 AM > > > > If "Servant get_servant();" was added to the POACurrent interface then > > this would seem to fit the bill... > > > > This was actually requested by Don Flynn in Oslo. He was tasked with > opening an issue describing security's particular use case. The folks in > attendance did not see any problem with supplying this. > > Russell Butek > butek@us.ibm.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Why Security Interceptors need access to Servant Date: Thu, 29 Jun 2000 13:36:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 'hAe9[`3!!"M4e9RZ?!! > From: Matthew Newhook [mailto:matthew@ooc.com] > A more obvious solution that comes to mind is to make the POACurrent > available from within an the receive_request invocation... I'm > not sure whether we can actually make it available from within the > receive_request_service_contexts invocation, however. > > If "Servant get_servant();" was added to the POACurrent interface > then > this would seem to fit the bill... That is a fine solution from my point of view, but first we have to see if anybody objects to that. It implies that POACurrent is in place when the interceptor call is made. BTW, we already make the servant available from an extension to POACurrent. Paul From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Why Security Interceptors need access to Servant Date: Thu, 29 Jun 2000 14:22:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: `6O!!28,e9I!h!!pWad9 > From: Bob Kukura [mailto:kukura@iona.com] > I have no problem with adding a POACurrent::get_servant > operation. But > I don't think its reasonable to require the POACurrent to be setup > during all interceptor callouts during a server side > invocation. This > might be doable in a monolithic ORB where the core, transport, and > POA > are intertwined. But in a plugable ORB architecture, having the core > call into the POA to setup POACurrent before all other > intercept points > would add significant overhead. In our case, it is not a problem to > make the POACurrent available during the receive_request intercept > point, but making it available from the other server side intercept > points would have serious performance and architectural > implications. This seems reasonable to me. The receive_request intercept point is the only one where we require the servant to be available. This is quite closely aligned with the point where POACurrent must be set up anyway. > > Would making POACurrent available just during > receive_request, combined > with a POACurrent::get_servant operation, meet security's > requirments? Since they want it in order to get the servant, and the servant is only available for that point, it *ought* to meet their needs. > > Looking back at Polar's original email that started this > thread, I think > his scenario would then be workable, provided that the > Servant parameter > was elimited from his DomainNamePOAPolicy::get_domain_names > operation > signature. The Policy could then be renamed DomainNamePolicy, since > it > would no longer be POA specific. An implementation supplied by a > POA > based application would access the POACurrent to get the servant, > object_id, or whatever it wants to use to map to the object's > DomainNameList. An implementation of the policy for a different > object > adapter could use that adapter's Current to get whatever > information it > needs. This approach seems to allow decoupling of the > security APIs and > the security interceptor implementation from the POA APIs, > both of which > we consider very important. This complete scenario sounds reasonable and clean. It also eliminates the performance issues I have been worrying about. Paul Date: Thu, 29 Jun 2000 16:19:28 -0230 From: Matthew Newhook To: Paul Kyzivat Cc: interceptors-ftf@omg.org Subject: Re: Why Security Interceptors need access to Servant Message-ID: <20000629161928.A10676@ooc.com> References: <9B164B713EE9D211B6DC0090273CEEA926BF13@bos1.noblenet.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BF13@bos1.noblenet.com> Content-Type: text/plain; charset=us-ascii X-UIDL: MSf!!pT9e9`0@!!87Ae9 Hi On Thu, Jun 29, 2000 at 02:22:24PM -0400, Paul Kyzivat wrote: >[..] > This complete scenario sounds reasonable and clean. > It also eliminates the performance issues I have been worrying about. Assuming that it actually meets Polars requirements then I think that this is the best solution all around. > Paul Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 29 Jun 2000 15:07:52 -0400 (EDT) From: Polar Humenn To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: Why Security Interceptors need access to Servant In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BF13@bos1.noblenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9Y]d9eU5!!CbGe9Kn\d9 On Thu, 29 Jun 2000, Paul Kyzivat wrote: > This complete scenario sounds reasonable and clean. > It also eliminates the performance issues I have been worrying > about. I've been on vacation for about three weeks, so I'm having trouble getting back into all of this. I'd rather be outside kayaking, you know. :) I think the approach being taken here will be fine with me. I think I just need a way to have somebody associate a policy object that can extract certain information from a particular implementation when it is called by an access control interceptor. Think of this policy object as an "plug-in" into an access control system that is performed by a standard access control interceptor (I'm still trying to figure that one out). It needs to extract attributes and domain name information. If POACurrent is set up correctly at that call, and it can get the POA and the servant all hidden below the policy interface, then I think we're set on that one. Now that I thnk about it (abeit quickly) this approach would also require that SecurityCurrent be set up correctly as well, because the policy object would have to access the "received_credentials" as well as the domain names and attributes of the object implemenation. A point to think about: How many other "Currents" would have to be set up correctly at the various intercept points? How many Currents are actually set up by the interceptors? -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 29 Jun 2000 15:34:59 -0400 From: Matthew Mihic Organization: IONA Technologies, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Paul Kyzivat , interceptors-ftf@omg.org Subject: Re: Why Security Interceptors need access to Servant References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: W@l!![,^!!995e9:e"e9 > A point to think about: How many other "Currents" would have to be set up > correctly at the various intercept points? How many Currents are actually > set up by the interceptors? Since receive_request_service_contexts is specifically intended to allow interceptors to set up Currents, I think that applications can only rely on Currents being established after this point (e.g. in receive_request). Regards, Matt Date: Wed, 26 Jul 2000 10:59:43 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Boldt Subject: Re: PI Comment Cutoff Date: July 21 References: <00be01bfeeab$31134cf0$8d907bcf@concept5.com> <3973330C.F9E5BFEF@sun.com> <006301bff382$4c51cab0$eb927bcf@concept5.com> <4.2.0.58.20000726134828.00c608b0@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -cp!!64$e9I/)!!,;#!! Yes, its needs an interceptors-ftf issue number - with the title: "Security needs access to servant and POA" Thanks, H Juergen Boldt wrote: > > Harold, > > no...looked more like general discussion to me....want me to assign a issue > number on Polars comments?.....should go under the interceptors-ftf > umbrella then? > > -Juergen > > At 10:39 AM 7/26/00 -0700, you wrote: > > >Juergen, > > > >Did this get issued a number? > > > >H > > > >Don Flinn wrote: > > > > > > Thanks for the heads up Harold. > > > > > > The Security Domain Membership Management Specification, called simply the > > > new specification below, deals with the structure of Security Domains and > > > the means by which CORBA objects are associated with a Security Domain. It > > > is the later situation for which we are requesting additional functionality > > > or specificity from the Portable Interceptors. This functionality is as > > > Harold stated below: > > > access to the POA from the portable interceptor and > > > access to the servant with assurance that the servant has been created at > > > the security service interceptor point. > > > > > > The following is a brief overview of the object / security domain > > > association in the new specification. As is know the security service is > > > called from within the interceptors. When the security service performs > > > access decision at the target it must associate the active object with a > > > Security Domain. In the POA case, the new specification, has added a > > > security policy to the POA. The end user developer will use the IDL > > methods > > > from the new specification to access the their POA security policy. Note > > > that it is only the end user who knows what the association of object to > > > domain should be. In addition, the end user will, in many cases, want > > > access to information in the servant, e.g. the values of the servant > > > parameters. > > > > > > I've copied mail that Polar send to the Interceptor group March 24, 2000 > > > which I believe gives the rational for the two requests on the Portable > > > Interceptors. > > > > > > From Polar --- > > > > > > Here are the scenarios needed for interceptor to have access to the > > > servant. > > > > > > 1. We want to provide security to "security unaware" applications. > > > 2. We also want to provide security based on "security aware" > > > applications. (You'll see what I mean later). > > > > > > We need to derive information from a particular object about the security > > > attributes of that object WITHOUT regard to the lifetime or persistence of > > > the object. (IMHO, the security specification made this extreme blunder > > > with the RequiredRights object, I don't want that to happen again) > > > > > > We could use several things about a servant in an interceptor: > > > > > > security attributes "about the servant" > > > owner attributes "about the owner of the servant" (new concept) > > > domain name "domain of the servant" (domain management). > > > > > > Now, the easy thing would say, Set up a domain name and owner data base > > > and just associate it with an object. However, in a generic sense, there > > > isn't an object. If the object is persistent, what happens to this data > > > when the object goes to sleep? What happens if the object is destroyed? > > > Consitency problems all over the place. > > > > > > What we need to do is "derive" the needed information, in a generic sense, > > > from the implementation of a servant. > > > > > > It might be that you have a POA, or a series of POAs, that create > > > references to bank account objects. Depending on the security policy > > > implemented we need to classify the servants (the objects the servant is > > > implementing) into groups. That is, return different owner or domain names > > > derived from information available to the servant. > > > > > > It works very cleanly this way, since all security relevant data is the > > > responsibility of the servant, that is if its transient transient or even > > > in persistent cases, we don't care. We need not make any requirements > > > about persistent or transient servants. > > > > > > The current approach we want to take (for the POA case anyway) is to have > > > a POA policy associated with the creation of a POA or an interceptor. This > > > POA policy has intimate knowledge of the implementations of the servant. > > > Let me illustrate by finding a domain name for a particular servant. > > > We have a policy that has intimate knowledge of the groups of servants > > > underneath it (possibly a POA). > > > > > > interface DomainNamePOAPolicy : CORBA::Policy { > > > DomainNameList get_domain_names( > > > in PortableServer::Servant serv > > > ) raises ( > > > IllegalServant > > > ); > > > }; > > > > > > As a security interceptor, we might like to do the following: > > > > > > RequestInfo ri; // from Interceptor > > > > > > POARequestInfo pri = POARequestInfo.narrow(ri); // for use with a POA > > > > > > POA poa = pri.the_poa(); // POArequestInfo specific attributes > > > Servant serv = pri.the_servant(); > > > > > > // Get the Domain Name finding policy object > > > DomainNamePOAPolicy dnp = > > > DomainNamePOAPolicy.narrow( > > > ri.get_server_policy(DomainNamePOAPolicyType)); > > > > > > DomainName[] dname = dnp.get_domain_name(serv); > > > > > > .. do access control based on domain names > > > > > > Fear and Loathing in ORB land: > > > (I fear the call to get_domain_names() might be orb > > > mediated, and subjected to interception?) > > > > > > Anyway, please excuse the concrete implementation below, but it is just an > > > illustration. Say we want the DomainNamePOAPolicy to base the domain name > > > on some significant part of the servant. Such as grouping all the bank > > > accounts by the salesman under which the bank account is in his > > > jurisdiction. (This IS what policy is all about, of course). > > > > > > class DomainNamePOAPolicy extends _DomainNamePOAPolicyImplBase { > > > DomainName[] get_domain_names(org.omg.PortableServer.Servant serv) > > > { > > > if (serv instanceof BankAccount) { > > > BankAccount ba = (BankAccount) serv; > > > > > > String salesman = ba.salesman(); > > > DomainName[] names = new DomainName[1]; > > > names[0] = convert_salesman_to_domain(salesman); > > > return names; > > > } > > > throw new IllegalServant(); > > > } > > > } > > > > > > We want to derive security information from the attributes in the > > > implementation of the servant, and not store security information about a > > > particular object the servants represent in separate places. The latter > > > approach causes all kinds of consitentcy and lifecycle issues for > > > transient and persistent matters. > > > > > > Using the policy approach as I have outlined solves most of those issues > > > and it is simply mandated that the policy implemented must have intimate > > > knowledge of the servant implementation. We don't care much about the > > > implementation, just the interface of it. > > > > > > This situation is okay, because a security implementer would supply the > > > correct policies to the POA or that would provide the correct information > > > to a security interceptor (i.e. one that had to know about domains) > > > without affecting the implementation of the servant. It's all > > > "plug-and-play". > > > > > > Does this reasoning suffice for the need to gain direct access to the > > > servant? > > > > > > ----- Original Message ----- > > > From: "Harold Carr" > > > To: "Don Flinn" > > > Cc: ; > > > Sent: Monday, July 17, 2000 12:23 PM > > > Subject: PI Comment Cutoff Date: July 21 > > > > > > > Don, in Oslo you came to the PI-FTF and said you would raise issues > > > > regarding: > > > > > > > > access to servant > > > > access to POA > > > > > > > > for domain management. > > > > > > > > I just want you to know that the cutoff date for raising issues is this > > > > Friday. If these are something you need you need to send mail to > > > > issues@omg.org and interceptors-ftf@omg.org. You should provide a solid > > > > use-case if you hope these issues to pass. > > > > > > > > Cheers, > > > > Harold > > > > > > > > > > ----- Original Message ----- > > > From: "Harold Carr" > > > To: "Don Flinn" > > > Cc: ; > > > Sent: Monday, July 17, 2000 12:23 PM > > > Subject: PI Comment Cutoff Date: July 21 > > > > > > > Don, in Oslo you came to the PI-FTF and said you would raise issues > > > > regarding: > > > > > > > > access to servant > > > > access to POA > > > > > > > > for domain management. > > > > > > > > I just want you to know that the cutoff date for raising issues is this > > > > Friday. If these are something you need you need to send mail to > > > > issues@omg.org and interceptors-ftf@omg.org. You should provide a solid > > > > use-case if you hope these issues to pass. > > > > > > > > Cheers, > > > > Harold > > > > > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > ================================================================ Date: Tue, 23 Jan 2001 11:57:43 -0600 From: Konstantin Beznosov X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: SDMM Submitters Mail list CC: interceptors-rtf@omg.org Subject: Re: Response to Domain Management issues 4 & 5 or "Security needs access to servant and POA" issue References: <0BA85ABE7E49D411A3BF0090279369B4630F3A@mars.hi.com> Content-Type: multipart/mixed; boundary="------------24BE9A0724A63C76AA899878" X-UIDL: f "Burghart, Ted" wrote: > > I could live with that addition, but this is not a new subject - see > http://cgi.omg.org/issues/issue3766 which was left unresolved in the > PI FTF's final report (ptc/00-08-05). At least some contributors to > the discussion expressed the same concern I mention below about more > tightly coupling the semantically modular ORB and OA, but it looks > as > though all could live with requiring PortableServer::Current to be > valid during receive_request processing. This didn't find its way > into the spec, though, and it may be possible to nudge it toward > closure by providing the text of the change in the SDMM submission. > We'd probably want to reference that issue to refresh people's > memories. > > That same issue touches upon the usefullness of the adapter_id > parameter provided in the ServerRequestInfo interface, with some > discussion of providing a means by which it might be resolved, but > this approach didn't seem to garner as much support as the former. > > - Ted > > -----Original Message----- > From: Konstantin Beznosov [mailto:beznosov@concept5.com] > Sent: Monday, January 22, 2001 5:41 PM > To: dom_mgt@concept5.com > Subject: Re: Response to Domain Management issues 4 & 5 > > All, > > SDMM submission, as a submission to any other RFP, has a section > (6.3 > in > the case of SDMM) describing changes/extensions to Adopted OMG > specifications. It seems to me that SDMM submission could limit the > resolution of these issues by having appropriate text in 6.3 > suggesting > exact text that should go either in PI or ORB chapters. I know that > it's > usually painful to change any adopted spec., especially when the > spec > is > very "close" to the ORB core, however I don't see any other way > around. > > If we agree on this, how about adding the following sub-section in > 6.3 > > of SDMM submission? > --------------------------------------------------------- > 6.3.1 Changes to Portable Interceptors Specification > > Append the following sentence to the first paragraph in section > 21.3.9.2 > titled "receive_request": "During execution of a receive_request > interceptor the PortableServer::Current instance, or equivalent > interface of an alternate object adapter, is valid and populated for > the > current invocation." > --------------------------------------------------------- > > I use ptc/00-03-03 a reference document for PI spec, which is the > latest version of the spec I have found on the OMG www site. > > To me, it also makes sense to include (slightly revised) version of > Ted's description of the issue in the ODM's architecture overview, > namely section 4.1.2."General Architecture Model in Regards to > Security > Interceptor". It could go in the section text, for example, in the > form > of a note. > > Any thoughts? We can also finalize these issues resolution during > the > fac-to-face meeting this week. > > > "Burghart, Ted" wrote: > > > > References: > > ORB orbos/00-11-07 > > PI orbos/99-12-02 > > > > 4. Can security interceptor find ref. to adapter by the Adapter > ID? > > > > Not within current specifications. I can find no means by which > the > > > adapter_id can be resolved. The adapter_id is opaque and although > it > > is acknowledged that the ORB/POA implementation must be able to > > resolve the adapter [ORB 11.2.1], it is implicit that this is an > > implementation detail and is therefore not exposed. > > > > Within the receive_request interception point [PI 5.3.1.2] it may > be > > > possible to infer that the PortableServer::Current object is > valid, > > however this is by no means explicit. If we could be certain that > the > > interceptor was invoked inside the context in which the > > PortableServer::Current object was valid, it would make POA > resolution > > simple and efficient. > > > > 5. Can security interceptor find ref. to servant by adapter and > object > > ID? > > > > In order to resolve the servant from the execution context of the > > interceptor, the servant must exist and be active. Hence, > resolution > > of the servant is only assumed to be viable from within the > > receive_request interception point [PI 5.3.1.2]. > > > > This relies heavily on and may be considered part of issue #4. As > > long as the adapter can be resolved, the servant can be resolved. > > > > Assuming the adapter can be resolved: > > With POA, yes, through the PortableServer::POA::id_to_servant > > method. > > Other object adapters would have to provide similar > functionality. > > > > > If PortableServer::Current is valid: > > Servant is resolved through > PortableServer::Current::get_servant() > > > > > Conclusion: > > > > Within the current specifications, resolution of the object > adapter > > and servant from within the execution context of an interceptor is > not > > guaranteed to be possible. > > > > I see two possible spec changes that would disambiguate the > current > > situation: > > > > 1. Change the ORB interface spec to include the ability to resolve > an > > opaque object adapter ID. Since the current interface explicitly > > avoids any direct reference to object adapters or their > operations, > > this would depart significantly from the present semantic model > and > > would seem undesirable. > > > > 2. Change the PI spec to explicitly state that during execution of > a > > > receive_request interceptor the PortableServer::Current instance, > or > > > equivalent interface of an alternate object adapter, is valid and > > populated for the current invocation. This has the unfortunate > side > > > effect of prescribing a more detailed sequence of interactions > between > > the ORB and the OA than that which exists currently or may be > > desirable. > > > > -- > > Ted Burghart > > Hitachi Computer Products (America), Inc. > > 1601 Trapelo Road > > Waltham MA 02451-7300 > > email: tburghart@hi.com > > voice: 781 768-5819 > > fax: 781 890-4998 > > -- > Konstantin Beznosov -- Konstantin Beznosov [] beznosov.vcf From: "Burghart, Ted" To: "'Konstantin Beznosov '" , "'SDMM Submitters Mail list '" Cc: "'interceptors-rtf@omg.org '" Subject: RE: OA::Current visibility within receive_request, PI issue 3766 Date: Wed, 24 Jan 2001 06:21:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C085F7.D180F640" X-UIDL: 2n"!!]b7!!PQ2!!#~=e9 It occurs to me that while having access to ::Current from the receive_request interception point takes care of context identification in an implementation using a single OA with which the interceptor is familiar, it falls short when the system may contain multiple OAs and/or OAs that are unknown to the interceptor. To be sure, in a POA-only system this all works fine, but let's consider what a workable implementation starts to look like in the presence of multiple OAs. In this case, we have to call some operation on each ::Current that we know of and see what succeeds. Each of these operations is likely to have a different signature and throw a different exception to indicate an invalid context, so we can't even do it in any kind of loop, we'd have to have a series of try/catch blocks attempting to hook up to each one until we either succeed with one or have exhausted all of the OAs with which we're familiar. Worse, we force any application that uses such an interceptor to have access to the implementation of each of these OA types, completely breaking the modularity and opaqueness of the desired model. In short, if we accept the desirability of the concept of pluggable OAs, this just doesn't work by itself. At one point in previous discussions of this issue, the possibility of providing some identifier of the OAs type to the interceptor was touched upon briefly but then seemed to get left behind. Also in the arena from time to time has been discussion of a common ObjectAdapter interface that all OA types inherit. I think there may be an approach taking some of each of these that works where none of them alone does. Let's suppose that the inheritance graph for ::Current includes another level, as follows: module ObjectAdapter { typedef string AdapterType; exception NoContext {}; interface Current : CORBA::Current { AdapterType adapter_type() raises ( NoContext ); }; }; module PortableServer { interface Current : ObjectAdapter::Current { . . . }; }; module SomeSpecializedOA { interface Current : ObjectAdapter::Current { . . . }; }; In this example I'm using a string as the adapter type identifier so that a specialized object adapter doesn't need to register with OMG to get a unique integral identifier. The obvious choice for the contents of the identifier is the OAs repository id, though certainly there are other possibilities. As this approach doesn't force any specific parentage on the OA itself and only modifies a specified inheritance on the OA::Current object, I hope that it would be deemed acceptable to those who don't want to enforce inheritance of a common ObjectAdapter base class. In combination with validity of the OA::Current object during receive_request processing, this provides the interceptor with identification of the target context and the ability to efficiently determine whether it knows how to deal with the context while preserving opaqueness of the object adapter implementation. - Ted -- Ted Burghart Hitachi Computer Products (America), Inc. Waltham MA tburghart@hi.com -----Original Message----- From: Konstantin Beznosov To: SDMM Submitters Mail list Cc: interceptors-rtf@omg.org Sent: 1/23/01 12:57 PM Subject: Re: Response to Domain Management issues 4 & 5 or "Security needs access to servant and POA" issue After reading through the mail thread pertaining to issue 3766, it seems to me too that most participants did not mind for an interceptor to set up a valid POA current at the receive_request interception point. I'm not aware why the issue was left unresolved by PI FTF. Does interceptors RTF have any position on this issue, i.e. kill/resolve it? If resolve it, would the text below suffice or it needs more than that? I'm cc-ing to the RTF so that we can have one discussion and maybe get with this issue over. > "Burghart, Ted" wrote: > > I could live with that addition, but this is not a new subject - see > http://cgi.omg.org/issues/issue3766 which was left unresolved in the > PI FTF's final report (ptc/00-08-05). At least some contributors to > the discussion expressed the same concern I mention below about more > tightly coupling the semantically modular ORB and OA, but it looks > as > though all could live with requiring PortableServer::Current to be > valid during receive_request processing. This didn't find its way > into the spec, though, and it may be possible to nudge it toward > closure by providing the text of the change in the SDMM submission. > We'd probably want to reference that issue to refresh people's > memories. > > That same issue touches upon the usefullness of the adapter_id > parameter provided in the ServerRequestInfo interface, with some > discussion of providing a means by which it might be resolved, but > this approach didn't seem to garner as much support as the former. > > - Ted > > -----Original Message----- > From: Konstantin Beznosov [mailto:beznosov@concept5.com] > Sent: Monday, January 22, 2001 5:41 PM > To: dom_mgt@concept5.com > Subject: Re: Response to Domain Management issues 4 & 5 > > All, > > SDMM submission, as a submission to any other RFP, has a section > (6.3 > in > the case of SDMM) describing changes/extensions to Adopted OMG > specifications. It seems to me that SDMM submission could limit the > resolution of these issues by having appropriate text in 6.3 > suggesting > exact text that should go either in PI or ORB chapters. I know that > it's > usually painful to change any adopted spec., especially when the > spec > is > very "close" to the ORB core, however I don't see any other way > around. > > If we agree on this, how about adding the following sub-section in > 6.3 > > of SDMM submission? > --------------------------------------------------------- > 6.3.1 Changes to Portable Interceptors Specification > > Append the following sentence to the first paragraph in section > 21.3.9.2 > titled "receive_request": "During execution of a receive_request > interceptor the PortableServer::Current instance, or equivalent > interface of an alternate object adapter, is valid and populated for > the > current invocation." > --------------------------------------------------------- > > I use ptc/00-03-03 a reference document for PI spec, which is the > latest version of the spec I have found on the OMG www site. > > To me, it also makes sense to include (slightly revised) version of > Ted's description of the issue in the ODM's architecture overview, > namely section 4.1.2."General Architecture Model in Regards to > Security > Interceptor". It could go in the section text, for example, in the > form > of a note. > > Any thoughts? We can also finalize these issues resolution during > the > fac-to-face meeting this week. > > > "Burghart, Ted" wrote: > > > > References: > > ORB orbos/00-11-07 > > PI orbos/99-12-02 > > > > 4. Can security interceptor find ref. to adapter by the Adapter > ID? > > > > Not within current specifications. I can find no means by which > the > > > adapter_id can be resolved. The adapter_id is opaque and although > it > > is acknowledged that the ORB/POA implementation must be able to > > resolve the adapter [ORB 11.2.1], it is implicit that this is an > > implementation detail and is therefore not exposed. > > > > Within the receive_request interception point [PI 5.3.1.2] it may > be > > > possible to infer that the PortableServer::Current object is > valid, > > however this is by no means explicit. If we could be certain that > the > > interceptor was invoked inside the context in which the > > PortableServer::Current object was valid, it would make POA > resolution > > simple and efficient. > > > > 5. Can security interceptor find ref. to servant by adapter and > object > > ID? > > > > In order to resolve the servant from the execution context of the > > interceptor, the servant must exist and be active. Hence, > resolution > > of the servant is only assumed to be viable from within the > > receive_request interception point [PI 5.3.1.2]. > > > > This relies heavily on and may be considered part of issue #4. As > > long as the adapter can be resolved, the servant can be resolved. > > > > Assuming the adapter can be resolved: > > With POA, yes, through the PortableServer::POA::id_to_servant > > method. > > Other object adapters would have to provide similar > functionality. > > > > > If PortableServer::Current is valid: > > Servant is resolved through > PortableServer::Current::get_servant() > > > > > Conclusion: > > > > Within the current specifications, resolution of the object > adapter > > and servant from within the execution context of an interceptor is > not > > guaranteed to be possible. > > > > I see two possible spec changes that would disambiguate the > current > > situation: > > > > 1. Change the ORB interface spec to include the ability to resolve > an > > opaque object adapter ID. Since the current interface explicitly > > avoids any direct reference to object adapters or their > operations, > > this would depart significantly from the present semantic model > and > > would seem undesirable. > > > > 2. Change the PI spec to explicitly state that during execution of > a > > > receive_request interceptor the PortableServer::Current instance, > or > > > equivalent interface of an alternate object adapter, is valid and > > populated for the current invocation. This has the unfortunate > side > > > effect of prescribing a more detailed sequence of interactions > between > > the ORB and the OA than that which exists currently or may be > > desirable. > > > > -- > > Ted Burghart > > Hitachi Computer Products (America), Inc. > > 1601 Trapelo Road > > Waltham MA 02451-7300 > > email: tburghart@hi.com > > voice: 781 768-5819 > > fax: 781 890-4998 > > -- > Konstantin Beznosov -- Konstantin Beznosov <> From: "Burghart, Ted" To: "''SDMM Submitters Mail list ' '" Cc: "''interceptors-rtf@omg.org ' '" Subject: RE: OA::Current visibility within receive_request, PI issue 3766 Date: Wed, 24 Jan 2001 07:10:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C085FE.9376AEB0" X-UIDL: <(I!!p(od9cAg!!dn::Current not follow the rules and leave the global Current pointing nowhere or to the wrong ::Current, the result would be a NoContext exception, which could be easily identified and converted to an OBJ_ADAPTER exception should it propagate out to the ORB. - Ted -----Original Message----- From: Burghart, Ted To: 'Konstantin Beznosov '; 'SDMM Submitters Mail list ' Cc: 'interceptors-rtf@omg.org ' Sent: 1/24/01 6:21 AM Subject: RE: OA::Current visibility within receive_request, PI issue 3766 It occurs to me that while having access to ::Current from the receive_request interception point takes care of context identification in an implementation using a single OA with which the interceptor is familiar, it falls short when the system may contain multiple OAs and/or OAs that are unknown to the interceptor. To be sure, in a POA-only system this all works fine, but let's consider what a workable implementation starts to look like in the presence of multiple OAs. In this case, we have to call some operation on each ::Current that we know of and see what succeeds. Each of these operations is likely to have a different signature and throw a different exception to indicate an invalid context, so we can't even do it in any kind of loop, we'd have to have a series of try/catch blocks attempting to hook up to each one until we either succeed with one or have exhausted all of the OAs with which we're familiar. Worse, we force any application that uses such an interceptor to have access to the implementation of each of these OA types, completely breaking the modularity and opaqueness of the desired model. In short, if we accept the desirability of the concept of pluggable OAs, this just doesn't work by itself. At one point in previous discussions of this issue, the possibility of providing some identifier of the OAs type to the interceptor was touched upon briefly but then seemed to get left behind. Also in the arena from time to time has been discussion of a common ObjectAdapter interface that all OA types inherit. I think there may be an approach taking some of each of these that works where none of them alone does. Let's suppose that the inheritance graph for ::Current includes another level, as follows: module ObjectAdapter { typedef string AdapterType; exception NoContext {}; interface Current : CORBA::Current { AdapterType adapter_type() raises ( NoContext ); }; }; module PortableServer { interface Current : ObjectAdapter::Current { . . . }; }; module SomeSpecializedOA { interface Current : ObjectAdapter::Current { . . . }; }; In this example I'm using a string as the adapter type identifier so that a specialized object adapter doesn't need to register with OMG to get a unique integral identifier. The obvious choice for the contents of the identifier is the OAs repository id, though certainly there are other possibilities. As this approach doesn't force any specific parentage on the OA itself and only modifies a specified inheritance on the OA::Current object, I hope that it would be deemed acceptable to those who don't want to enforce inheritance of a common ObjectAdapter base class. In combination with validity of the OA::Current object during receive_request processing, this provides the interceptor with identification of the target context and the ability to efficiently determine whether it knows how to deal with the context while preserving opaqueness of the object adapter implementation. - Ted -- Ted Burghart Hitachi Computer Products (America), Inc. Waltham MA tburghart@hi.com -----Original Message----- From: Konstantin Beznosov To: SDMM Submitters Mail list Cc: interceptors-rtf@omg.org Sent: 1/23/01 12:57 PM Subject: Re: Response to Domain Management issues 4 & 5 or "Security needs access to servant and POA" issue After reading through the mail thread pertaining to issue 3766, it seems to me too that most participants did not mind for an interceptor to set up a valid POA current at the receive_request interception point. I'm not aware why the issue was left unresolved by PI FTF. Does interceptors RTF have any position on this issue, i.e. kill/resolve it? If resolve it, would the text below suffice or it needs more than that? I'm cc-ing to the RTF so that we can have one discussion and maybe get with this issue over. > "Burghart, Ted" wrote: > > I could live with that addition, but this is not a new subject - see > http://cgi.omg.org/issues/issue3766 which was left unresolved in > the > PI FTF's final report (ptc/00-08-05). At least some contributors to > the discussion expressed the same concern I mention below about more > tightly coupling the semantically modular ORB and OA, but it looks > as > though all could live with requiring PortableServer::Current to be > valid during receive_request processing. This didn't find its way > into the spec, though, and it may be possible to nudge it toward > closure by providing the text of the change in the SDMM submission. > We'd probably want to reference that issue to refresh people's > memories. > > That same issue touches upon the usefullness of the adapter_id > parameter provided in the ServerRequestInfo interface, with some > discussion of providing a means by which it might be resolved, but > this approach didn't seem to garner as much support as the former. > > - Ted > > -----Original Message----- > From: Konstantin Beznosov [ mailto:beznosov@concept5.com ] > Sent: Monday, January 22, 2001 5:41 PM > To: dom_mgt@concept5.com > Subject: Re: Response to Domain Management issues 4 & 5 > > All, > > SDMM submission, as a submission to any other RFP, has a section > (6.3 > in > the case of SDMM) describing changes/extensions to Adopted OMG > specifications. It seems to me that SDMM submission could limit the > resolution of these issues by having appropriate text in 6.3 > suggesting > exact text that should go either in PI or ORB chapters. I know that > it's > usually painful to change any adopted spec., especially when the > spec > is > very "close" to the ORB core, however I don't see any other way > around. > > If we agree on this, how about adding the following sub-section in > 6.3 > > of SDMM submission? > --------------------------------------------------------- > 6.3.1 Changes to Portable Interceptors Specification > > Append the following sentence to the first paragraph in section > 21.3.9.2 > titled "receive_request": "During execution of a receive_request > interceptor the PortableServer::Current instance, or equivalent > interface of an alternate object adapter, is valid and populated for > the > current invocation." > --------------------------------------------------------- > > I use ptc/00-03-03 a reference document for PI spec, which is the > latest version of the spec I have found on the OMG www site. > > To me, it also makes sense to include (slightly revised) version of > Ted's description of the issue in the ODM's architecture overview, > namely section 4.1.2."General Architecture Model in Regards to > Security > Interceptor". It could go in the section text, for example, in the > form > of a note. > > Any thoughts? We can also finalize these issues resolution during > the > fac-to-face meeting this week. > > > "Burghart, Ted" wrote: > > > > References: > > ORB orbos/00-11-07 > > PI orbos/99-12-02 > > > > 4. Can security interceptor find ref. to adapter by the Adapter > ID? > > > > Not within current specifications. I can find no means by which > the > > > adapter_id can be resolved. The adapter_id is opaque and although > it > > is acknowledged that the ORB/POA implementation must be able to > > resolve the adapter [ORB 11.2.1], it is implicit that this is an > > implementation detail and is therefore not exposed. > > > > Within the receive_request interception point [PI 5.3.1.2] it may be > > > possible to infer that the PortableServer::Current object is valid, > > however this is by no means explicit. If we could be certain that > the > > interceptor was invoked inside the context in which the > > PortableServer::Current object was valid, it would make POA > resolution > > simple and efficient. > > > > 5. Can security interceptor find ref. to servant by adapter and > object > > ID? > > > > In order to resolve the servant from the execution context of the > > interceptor, the servant must exist and be active. Hence, > resolution > > of the servant is only assumed to be viable from within the > > receive_request interception point [PI 5.3.1.2]. > > > > This relies heavily on and may be considered part of issue #4. As > > long as the adapter can be resolved, the servant can be resolved. > > > > Assuming the adapter can be resolved: > > With POA, yes, through the PortableServer::POA::id_to_servant > > method. > > Other object adapters would have to provide similar functionality. > > > > > If PortableServer::Current is valid: > > Servant is resolved through PortableServer::Current::get_servant() > > > > > Conclusion: > > > > Within the current specifications, resolution of the object adapter > > and servant from within the execution context of an interceptor is > not > > guaranteed to be possible. > > > > I see two possible spec changes that would disambiguate the current > > situation: > > > > 1. Change the ORB interface spec to include the ability to resolve > an > > opaque object adapter ID. Since the current interface explicitly > > avoids any direct reference to object adapters or their operations, > > this would depart significantly from the present semantic model and > > would seem undesirable. > > > > 2. Change the PI spec to explicitly state that during execution of a > > > receive_request interceptor the PortableServer::Current instance, or > > > equivalent interface of an alternate object adapter, is valid and > > populated for the current invocation. This has the unfortunate side > > > effect of prescribing a more detailed sequence of interactions > between > > the ORB and the OA than that which exists currently or may be > > desirable. > > > > -- > > Ted Burghart > > Hitachi Computer Products (America), Inc. > > 1601 Trapelo Road > > Waltham MA 02451-7300 > > email: tburghart@hi.com > > voice: 781 768-5819 > > fax: 781 890-4998 > > -- > Konstantin Beznosov -- Konstantin Beznosov <>