Issue 2789: Security: SSL reference no longer valid (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: This is an issue vs the Security specification. The reference to SSL, ftp://ierf.cnsi.reston.va.us/internet-drafts/draft-freier-ssl-version3- 01.txt is not valid even if you correct the domain from "ierf" to "ietf". In fact, the Internet Draft (which was only valid for six months) has been withdrawn and I was unable to find a copy anywhere on the web. Possible solutions: If someone has a copy, and copyright permissions allow, we can post it on the OMG server and reference it even though it"s not a valid IETF specification. Otherwise, the spec should be updated to conform to TLS 1.0 and the reference updated to this spec instead of the SSL draft. In the future, IETF drafts (which have limited lifetime) should not be normative refereces in any OMG specifications. Resolution: close issue 2789 Revised Text: ++Add Required Rights, Access Decision, Audit Decision definintions and attributes (from Current), and get_security_policy (from Current:get_policy) to Security Manager. ++Install the following paragraphs (taken from the previous Operations on Security Current section) into the Security Manager section: required_rights_object This readonly attribute is the RequiredRights object available in the environment. This object is rarely used by applications directly. It could be used directly by applications if the application wishes to do all its own access control based on rights. readonly attribute RequiredRights required_rights_object; Return Value An object reference to RequiredRights. The operation in the interface of this object are defined in Section 15.6.4, "Access Policies", on page 15-???. access_decision This read only attribute is the AccessDecision object available in the environment. It can be used by the application to obtain decisions regarding accessibility of specific objects from this environment. readonly attribute AccessDecision access_decision; Return Value An object reference to an AccessDecision object. The operations in the interface of this object are defined in Section 15.5.10, "Access Control", on page 15-??? audit_decision This read only attribute is the AuditDecision object available in the environment. It can be used by the application to obtain information about what needs to be audited for the specified object/interface in this environment. readonly attribute AuditDecision audit_decision; Return Value An object reference to an AuditDecision object. The operation in the interface of this object are defined in Section 15.5.8, "Security Audit", on page 15-??? get_security_policy This operation gets the security policy of the specified policy_type that is relevant to the ORB instance and security service. CORBA::Policy get_security_policy( in CORBA::PolicyType policy_type ); Parameters policy_type The type of policy requested. Return Value The policy in effect for the ORB instance. If no policy of that type is in effect, a CORBA::INV_POLICY exception is raised. ++Fix all references to Current::get_policy to PolicyCurrent::get_policy_overrides or SecurityManager::get_security_policy where appropriate. ++Change the paragraph [632], starting with "The SecurityLevel2::AccessDecision Interface" and change the corresponding definition of AccessDecision in appendix A.4. The SecurityLevel2::AccessDecision Interface The Access Decision object is a locality constrained object. This object has the following interface: interface AccessDecision { boolean access_allowed( in ReceivedCredentials creds, in Object target, in CORBA::Identifier operation_name, in CORBA::RepositoryId target_interface_name ); }; Parameters creds The Credentials representing principal of a client. target The reference of the target object. operation_name The name of the operation on the target object for which access is being requested. target_interface_name The repository identifier which must name the most derived interface of the target object. Return Value boolean A return value of TRUE indicates that access to the particular operation is allowed. A return value of FALSE indicates that access to the particular operation is denied. ++Remove the paragraph [695], starting with "A RequiredRights object is available as an attribute of Current...." which stipulates that RequiredRights is an attribute off of Current and also eliminating the part about "every" required rights object in every execution context as this is confusing: ++Remove paragraph [840] starting with "While man of these objects have interfaces...." ++Replace paragraph 910, "The Access Decision Object" on page 15-186 with the following, and add the interface definition to Appendix A.7. The Access Decision Object The Access Decision object is responsible for determining whether the specified credentials allow an operation to be performed on a target object. The target uses its access_allowed operation to determine whether a client principal’s privileges, which are obtained from the SecurityCurrent, are sufficient to meet the access criteria for the requested operation for a target object of the specified interface. The SecurityReplaceable::AccessDecision Interface The SecurityReplaceable::AccessDecision object is a locality constrained object. This object has the following interface: interface AccessDecision { boolean access_allowed( in ReceivedCredentials creds, in Object target, in CORBA::Identifier operation_name, in CORBA::RepositoryId target_interface_name ); }; Parameters creds The Credentials representing principal of a client. target The reference of the target object. operation_name The name of the operation on a target object for which access is being requested. target_interface_name The CORBA repository identifier which represents the most derived interface name of a target object. Return Value boolean A return value of TRUE indicates that access to the particular operation is allowed. A return value of FALSE indicates that access to the particular operation is denied. ++Add paragraphs after paragraph 909 and add the interface definition to Appendix A.7 The Required Rights Object The Required Rights object has operations for retrieving and setting the rights required for operations on interfaces. It is replaceable since the replaceable Access Decision depends upon its implementation, if the Access Decision object uses RequiredRights. Note that the following behaviors of systems conforming to CORBA Security are unspecified and therefore may be implementation-dependent. o Assignment of initial required rights to newly created interfaces. o Inheritance of required rights by newly created derived interfaces. The SecurityReplaceable::RequiredRights Interface The SecurityReplaceable::RequiredRights Interface has the following operations: get_required_rights This operation retrieves the rights required for access to the operation specified by operation_name from the interface specified by interface_name. The returned values are a list of rights and a combinator that describes the the interpretation of multiple rights. void get_required_rights( in CORBA::Identifier operation_name, in CORBA::RepositoryId interface_name, out RightsList rights, out RightsCombinator rights_combinator ); Parameters operation_name The name of the operation for which required rights are to be returned. interface_name The CORBA Repository identifier which names the interface to which the operation belongs. rights The returned list of rights. rights_combinator The returned rights combinator. Return Value None. set_required_rights This operation updates the rights required to execute the operation specified by the operation_name of the interface specified by interface_name. The caller must provide a list of rights and a combinator describing the interpretation of multiple rights. void set_required_rights( in CORBA::Identifier operation_name, in CORBA::RepositoryId interface_name, in RightsList rights, in RightsCombinator rights_combinator ); Parameters operation_name The name of the operation for which requires rights are to be updated. interface_name The CORBA Repository identifier which names the interface to which the operation belongs. rights The list of rights. rights_combinator The rights combinator. Return Value None. ++Change paragraph [911] and [912] with the following and add the interface definitions to Appendix A.7. The Audit Decision Object The Audit Decision object is used to determine if an event needs to be audited. The SecurityReplaceable::AuditDecision Interface The AuditDecision object has the following attributes and operations: audit_needed This operation is used to determine if an audit record is to be written to the audit channel. The caller specifies and event type and values for the selectors. It has the following definition: boolean audit_needed( in AuditEventType event_type, in SelectorValueList value_list ); Parameters event_type The event type. value_list A list of zero or more selector value pairs. Return Value TRUE If an audit record should be created and sent to the audit channel FALSE If an audit record is not needed. audit_channel This attribute provides the audit channel associated with the audit decision object. readonly attribute AuditChannel audit_channel; Return Value The AuditChannel object associated with the AuditDecision object. The AuditChannel Object An AuditChannel Object contains the operations necessary to generate audit records. audit_channel_id The readonly attribute contains an identifier with which to identify the particular audit channel object. readonly attribute AuditChannelId audit_channel_id; Return Value The audit channel identifier. audit_write This operation writes an audit record on the audit channel. void audit_write( in AuditEventType event_type, in CredentialsList creds_list, in UtcT time, in SelectorValueList descriptors, in any event_specific_data ); Parameters event_type The type of event. creds_list The list of credentials of the principal responsible for the event. time The time the event occurred. descriptors The set of values to be recorded that are associated with the event. event_specific_data Data specific to a particular type of event. Return Value None. Actions taken: July 7, 1999: received issue May 4, 2000: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 7 Jul 1999 13:39:16 -0400 (EDT) From: Polar Humenn To: sec-rev@omg.org Subject: AccessDecision Is there any more discussion about bringing the access decision object in line with the current credentials model and the POA? Namely: interface AccessDecision { //locality constrained boolean access_allowed( ReceivedCredentials creds, POA::Servant objimpl, CORBA::Identifier operation ); }; -Polar From: "David M. Chizmadia" To: Subject: Re: AccessDecision Date: Wed, 7 Jul 1999 13:54:33 -0400 X-Mailer: Microsoft Outlook Express 4.71.1712.3 Polar, This would be an object acquired via resolve_initial_references, correct? It would also be available only on the server (since there isn't a POA on the client)? (The basic interface looks fine, I'm just trying to understand how it fits into the larger picture - specifically, how one gets a reference to it.) -DMC -----Original Message----- From: Polar Humenn To: sec-rev@omg.org Date: Wednesday, July 07, 1999 1:42 PM Subject: AccessDecision > >Is there any more discussion about bringing the access decision object in >line with the current credentials model and the POA? Namely: > >interface AccessDecision { //locality constrained > boolean access_allowed( > ReceivedCredentials creds, > POA::Servant objimpl, > CORBA::Identifier operation > ); >}; > >-Polar > Date: Wed, 07 Jul 1999 14:38:53 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en To: Polar Humenn CC: sec-rev@omg.org Subject: Re: AccessDecision Polar Humenn wrote: > > Is there any more discussion about bringing the access decision object in > line with the current credentials model and the POA? Namely: > > interface AccessDecision { //locality constrained > boolean access_allowed( > ReceivedCredentials creds, > POA::Servant objimpl, > CORBA::Identifier operation > ); > }; > > -Polar I'm not at all comfortable with using PortableServer::Servant here. CORBA 2.3 (and earlier versions) explicitly acknowledge that there might be multiple object adapters: > 2.1.11 Object Adapters > An object adapter is the primary way that an object implementation accesses services > provided by the ORB. There are expected to be a few object adapters that will be > widely available, with interfaces that are appropriate for specific kinds of objects. > Services provided by the ORB through an Object Adapter often include: generation > and interpretation of object references, method invocation, security of interactions, > object and implementation activation and deactivation, mapping object references to > implementations, and registration of implementations. > The wide range of object granularities, lifetimes, policies, implementation styles, and > other properties make it difficult for the ORB Core to provide a single interface that is > convenient and efficient for all objects. Thus, through Object Adapters, it is possible > for the ORB to target particular groups of object implementations that have similar > requirements with interfaces tailored to them. Although the POA may be the only current standardized object adapter, that does not mean ORBs can't include alternatives. For example, an ORB might even keep its BOA around indefinitely in order to not force existing applications to migrate to the POA. I'd hope that request-level security interceptors could remain OA-independent. I think it would be much better to pass in instance of some Security-defined interface (SecurityLevel2::Target?) as the objimpl parameter, and include whatever attributes are needed (readonly attribute CORBA::RepositoryId primary_interface) on this interface in an OA-neutral manner. Or maybe just pass the RepositoryId to the AccessDecision object if thats all thats needed. -Bob X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 7 Jul 1999 15:03:28 -0400 (EDT) From: Polar Humenn To: Bob Kukura cc: sec-rev@omg.org Subject: Re: AccessDecision On Wed, 7 Jul 1999, Bob Kukura wrote: > Polar Humenn wrote: > > > > Is there any more discussion about bringing the access decision object in > > line with the current credentials model and the POA? Namely: > > > > interface AccessDecision { //locality constrained > > boolean access_allowed( > > ReceivedCredentials creds, > > POA::Servant objimpl, > > CORBA::Identifier operation > > ); > > }; > > > > -Polar > > I'm not at all comfortable with using PortableServer::Servant here. > CORBA 2.3 (and earlier versions) explicitly acknowledge that there might > be multiple object adapters: Cool! Some knowledgable input. Thanks. > > 2.1.11 Object Adapters > > An object adapter is the primary way that an object implementation accesses services > > provided by the ORB. There are expected to be a few object adapters that will be > > widely available, with interfaces that are appropriate for specific kinds of objects. > > Services provided by the ORB through an Object Adapter often include: generation > > and interpretation of object references, method invocation, security of interactions, > > object and implementation activation and deactivation, mapping object references to > > implementations, and registration of implementations. > > The wide range of object granularities, lifetimes, policies, implementation styles, and > > other properties make it difficult for the ORB Core to provide a single interface that is > > convenient and efficient for all objects. Thus, through Object Adapters, it is possible > > for the ORB to target particular groups of object implementations that have similar > > requirements with interfaces tailored to them. > > Although the POA may be the only current standardized object adapter, > that does not mean ORBs can't include alternatives. For example, an ORB > might even keep its BOA around indefinitely in order to not force > existing applications to migrate to the POA. I'd hope that > request-level security interceptors could remain OA-independent. I see. > I think it would be much better to pass in instance of some > Security-defined interface (SecurityLevel2::Target?) as the objimpl > parameter, and include whatever attributes are needed (readonly > attribute CORBA::RepositoryId primary_interface) on this interface in an > OA-neutral manner. Or maybe just pass the RepositoryId to the > AccessDecision object if thats all thats needed. Ahh, here lies the base argument. Is AccessDecision suppose to be general enough to handle more than just access decision based on interface alone? If not, then just the repository id will be fine, provided that there is always a way to get it (on the server side). BOA or POA, I think that can be accomplished. If it cannot, please let me know. (I'm familiar with the Java mapping, where the portability interfaces for ObjectImpl have an operation called String[] _ids(), of which the 0th element is the Repository of the MDI. However, there could be a need for "more complex" access decisions, which requires more information, particularly based on attributes answered by the implementation of the object. Also, namely, this pestky "_get_domain_managers" operation. The question is, should the security service be providing such complex access decisions, or should it be prohibited from doing so, leaving access decision to another "service"? However, my interpretation of what you stipulate above, is apparently, BOA, POA, it just doesn't matter, because all you need is *an* "Object Adaptor" and there is no requirement, or standard requirement for an ORB to implement either the POA or BOA. Is that interpretation really true? Or do *all* CORBA 2.3 ORBS require a standard POA implementation? I am now really confused. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 07 Jul 1999 16:15:08 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en To: Polar Humenn CC: sec-rev@omg.org Subject: Re: AccessDecision Polar Humenn wrote: > > On Wed, 7 Jul 1999, Bob Kukura wrote: > > > Polar Humenn wrote: > > > > > > Is there any more discussion about bringing the access decision object in > > > line with the current credentials model and the POA? Namely: > > > > > > interface AccessDecision { //locality constrained > > > boolean access_allowed( > > > ReceivedCredentials creds, > > > POA::Servant objimpl, > > > CORBA::Identifier operation > > > ); > > > }; > > > > > > -Polar > > > > I'm not at all comfortable with using PortableServer::Servant here. > > CORBA 2.3 (and earlier versions) explicitly acknowledge that there might > > be multiple object adapters: > > Cool! Some knowledgable input. Thanks. > > > > 2.1.11 Object Adapters > > > An object adapter is the primary way that an object implementation accesses services > > > provided by the ORB. There are expected to be a few object adapters that will be > > > widely available, with interfaces that are appropriate for specific kinds of objects. > > > Services provided by the ORB through an Object Adapter often include: generation > > > and interpretation of object references, method invocation, security of interactions, > > > object and implementation activation and deactivation, mapping object references to > > > implementations, and registration of implementations. > > > The wide range of object granularities, lifetimes, policies, implementation styles, and > > > other properties make it difficult for the ORB Core to provide a single interface that is > > > convenient and efficient for all objects. Thus, through Object Adapters, it is possible > > > for the ORB to target particular groups of object implementations that have similar > > > requirements with interfaces tailored to them. > > > > Although the POA may be the only current standardized object adapter, > > that does not mean ORBs can't include alternatives. For example, an ORB > > might even keep its BOA around indefinitely in order to not force > > existing applications to migrate to the POA. I'd hope that > > request-level security interceptors could remain OA-independent. > > I see. > > > I think it would be much better to pass in instance of some > > Security-defined interface (SecurityLevel2::Target?) as the objimpl > > parameter, and include whatever attributes are needed (readonly > > attribute CORBA::RepositoryId primary_interface) on this interface in an > > OA-neutral manner. Or maybe just pass the RepositoryId to the > > AccessDecision object if thats all thats needed. > > Ahh, here lies the base argument. > > Is AccessDecision suppose to be general enough to handle more than just > access decision based on interface alone? If not, then just the repository > id will be fine, provided that there is always a way to get it (on the > server side). BOA or POA, I think that can be accomplished. If it cannot, > please let me know. (I'm familiar with the Java mapping, where the > portability interfaces for ObjectImpl have an operation called String[] > _ids(), of which the 0th element is the Repository of the MDI. I don't know enough about where CORBA security is heading to answer that. I thought AccessDecision objects were typically provided by the security service, and not the application. I don't see what a general-purpose security service could do with general access to the POA's Servant other than to access the functions defined by the language mapping of Servant. But it sounds like there is only a single AccessDecision instance per ORB instance. What if an ORB implementation allowed multiple different OAs to coexist in the same process under that same ORB instance? > > However, there could be a need for "more complex" access decisions, which > requires more information, particularly based on attributes answered by > the implementation of the object. Also, namely, this pestky > "_get_domain_managers" operation. If you are talking about having the AccessDecision object invoke IDL-defined operations/attributes of the Servant, then I don't see how this possibly could relate to a general-purpose security service. If its an application specific thing, then we'd still have the problem of the AccessDecision object having to figure out which type of servant an invocation is for, and then doing the right thing for that type. I really doubt the majority of users want/need to get into this kind of thing. If they really need to, can't they always just implement access decisions in the methods of their servants? Couldn't the DomainManager be provided to the AccessDecision object via either a parameter or an attribute of SecurityLevel2::Target? I'm not sure having the Servant helps in (efficiently) getting the DomainManager, anyway. The ORB could probably do better than to convert the Servant to a reference and then invoke _get_domain_managers on the reference. > > The question is, should the security service be providing such complex > access decisions, or should it be prohibited from doing so, leaving access > decision to another "service"? Or maybe just acknowledge that some kinds of access decisions are best made by the Servants themselves. > > However, my interpretation of what you stipulate above, is apparently, > BOA, POA, it just doesn't matter, because all you need is *an* "Object > Adaptor" and there is no requirement, or standard requirement for an ORB > to implement either the POA or BOA. > > Is that interpretation really true? > Or do *all* CORBA 2.3 ORBS require a standard POA implementation? A CORBA 2.2 or CORBA 2.3 compliant ORB must implement the POA. But it is not prohibited from implementing other object adapters as well. > > I am now really confused. > > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > Principal 2-212 Center for Science & Technology > mailto:polar@adiron.com CASE Center/Syracuse University > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 7 Jul 1999 17:11:08 -0400 (EDT) From: Polar Humenn To: Bob Kukura cc: sec-rev@omg.org Subject: Re: AccessDecision Bob, comments are in the following: On Wed, 7 Jul 1999, Bob Kukura wrote: > > > Polar Humenn wrote: > > > > On Wed, 7 Jul 1999, Bob Kukura wrote: > > > > > Polar Humenn wrote: > > > > > > > > Is there any more discussion about bringing the access decision object in > > > > line with the current credentials model and the POA? Namely: > > > > > > > > interface AccessDecision { //locality constrained > > > > boolean access_allowed( > > > > ReceivedCredentials creds, > > > > POA::Servant objimpl, > > > > CORBA::Identifier operation > > > > ); > > > > }; > > > > > > > > -Polar > > > > > > I'm not at all comfortable with using PortableServer::Servant here. > > > CORBA 2.3 (and earlier versions) explicitly acknowledge that there might > > > be multiple object adapters: > > > > Cool! Some knowledgable input. Thanks. > > > > > > 2.1.11 Object Adapters > > > > An object adapter is the primary way that an object implementation accesses services > > > > provided by the ORB. There are expected to be a few object adapters that will be > > > > widely available, with interfaces that are appropriate for specific kinds of objects. > > > > Services provided by the ORB through an Object Adapter often include: generation > > > > and interpretation of object references, method invocation, security of interactions, > > > > object and implementation activation and deactivation, mapping object references to > > > > implementations, and registration of implementations. > > > > The wide range of object granularities, lifetimes, policies, implementation styles, and > > > > other properties make it difficult for the ORB Core to provide a single interface that is > > > > convenient and efficient for all objects. Thus, through Object Adapters, it is possible > > > > for the ORB to target particular groups of object implementations that have similar > > > > requirements with interfaces tailored to them. > > > > > > Although the POA may be the only current standardized object adapter, > > > that does not mean ORBs can't include alternatives. For example, an ORB > > > might even keep its BOA around indefinitely in order to not force > > > existing applications to migrate to the POA. I'd hope that > > > request-level security interceptors could remain OA-independent. > > > > I see. > > > > > I think it would be much better to pass in instance of some > > > Security-defined interface (SecurityLevel2::Target?) as the objimpl > > > parameter, and include whatever attributes are needed (readonly > > > attribute CORBA::RepositoryId primary_interface) on this interface in an > > > OA-neutral manner. Or maybe just pass the RepositoryId to the > > > AccessDecision object if thats all thats needed. > > > > Ahh, here lies the base argument. > > > > Is AccessDecision suppose to be general enough to handle more than just > > access decision based on interface alone? If not, then just the repository > > id will be fine, provided that there is always a way to get it (on the > > server side). BOA or POA, I think that can be accomplished. If it cannot, > > please let me know. (I'm familiar with the Java mapping, where the > > portability interfaces for ObjectImpl have an operation called String[] > > _ids(), of which the 0th element is the Repository of the MDI. > > I don't know enough about where CORBA security is heading to answer > that. I thought AccessDecision objects were typically provided by the > security service, and not the application. I don't see what a > general-purpose security service could do with general access to the > POA's Servant other than to access the functions defined by the language > mapping of Servant. But it sounds like there is only a single > AccessDecision instance per ORB instance. What if an ORB implementation > allowed multiple different OAs to coexist in the same process under that > same ORB instance? Apparently, how can we provide cohabitations with things that aren't standardized? aka OA's that we don't know about. If we must abstract away from the fact that there is an object adaptor, what good is the standard? This security stuff should really be aligned as close to the "system" as possible. That, I believe, is why there are a lot of locality constrained interfaces. I'd rather use the type system to enforce certain architecture issues. > > However, there could be a need for "more complex" access decisions, which > > requires more information, particularly based on attributes answered by > > the implementation of the object. Also, namely, this pestky > > "_get_domain_managers" operation. > > If you are talking about having the AccessDecision object invoke > IDL-defined operations/attributes of the Servant, then I don't see how > this possibly could relate to a general-purpose security service. If > its an application specific thing, then we'd still have the problem of > the AccessDecision object having to figure out which type of servant an > invocation is for, and then doing the right thing for that type. I > really doubt the majority of users want/need to get into this kind of > thing. If they really need to, can't they always just implement access > decisions in the methods of their servants? Or in their own interceptors? Think Security Programmers -> Interceptors vs Application Programmers -> Application. I think the idea was for AccessDecision to be a "replaceable" thing. I see no reason why you cannot provide an implemenation of access decision that analyses in a general way, the type of the object implemenation, and realizes what do do with it. The problem is where to stop, I agree, such as including the arguments. > Couldn't the DomainManager be provided to the AccessDecision object via > either a parameter or an attribute of SecurityLevel2::Target? I'm not > sure having the Servant helps in (efficiently) getting the > DomainManager, anyway. The ORB could probably do better than to convert > the Servant to a reference and then invoke _get_domain_managers on the > reference. I have no idea how "_get_domain_managers" is (will be?) implemented on the client side or the target side at all. Does anybody have a clue? There are still debates over whether the client side issues a call to the server for the answer, and whether the server actually asks the servant. I really wish some ORB vendors got in on this Domain Membership RFP. However, to have the ORB create a reference for a servant for which it already has an invocation, seems to be an inefficient way of getting the job done. Especially, if you consider that the "interceptor" should be called for local stubs on the object reference. If the access decision needs to call "_get_domain_managers" on the object reference, then a recursive interception would result. Providing the interceptor machinery to avoid that scenario would complicate matters to no end. > > The question is, should the security service be providing such complex > > access decisions, or should it be prohibited from doing so, leaving access > > decision to another "service"? > > Or maybe just acknowledge that some kinds of access decisions are best > made by the Servants themselves. That will be true in any case. And I am in whole hearted agreement with your statement. First of all, I don't think access decision should be in the security service at all, it should be a separate service that applications can take advantage of, in either interceptors or their own applications. The security service, being heavily integrated in the ORB (through transport, SECIOP, SSLIOP, service context, etc) should provide (simply) the wherewithall to make an intelligent access and trust decision. So you can use an ORB with a security service, and use somebody else's AccessDecision logic as a different service. But that's just my two cents worth. Until ORB's become operating systems, in which the ORB lies in a separate protected space, and applications are separated from that space, the point is really moot. Actually, for "general" purpose security, as you put it, I don't see a real need for an AccessDecision interface at all. If anything, for "general" purpose security, the AccessDecision interface should be the request level interceptor itself. There is really no need to expose anything to the application if the decision is going to be made before the servant gets the dispatch. > > However, my interpretation of what you stipulate above, is apparently, > > BOA, POA, it just doesn't matter, because all you need is *an* "Object > > Adaptor" and there is no requirement, or standard requirement for an ORB > > to implement either the POA or BOA. > > > > Is that interpretation really true? > > Or do *all* CORBA 2.3 ORBS require a standard POA implementation? > > A CORBA 2.2 or CORBA 2.3 compliant ORB must implement the POA. But it > is not prohibited from implementing other object adapters as well. Yeah, okay, an besides my treatise above, we have a problem with the current specification. Why don't/shouldn't we supply interfaces that ahere to a tight model that provides efficient use of it. This is closely "system" related stuff. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: "William Z Pope" To: "Polar Humenn" , "Bob Kukura" Cc: Subject: RE: AccessDecision Date: Wed, 7 Jul 1999 15:00:23 -0700 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal Bob, Some comments in-line below ... > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Wednesday, July 07, 1999 2:11 PM > To: Bob Kukura > Cc: sec-rev@omg.org > Subject: Re: AccessDecision > > > Bob, > comments are in the following: > > On Wed, 7 Jul 1999, Bob Kukura wrote: > > > > > > > Polar Humenn wrote: > > > > > > On Wed, 7 Jul 1999, Bob Kukura wrote: > > > > > > > Polar Humenn wrote: > > > > > > > > > > Is there any more discussion about bringing the access > decision object in > > > > > line with the current credentials model and the POA? Namely: > > > > > > > > > > interface AccessDecision { //locality constrained > > > > > boolean access_allowed( > > > > > ReceivedCredentials creds, > > > > > POA::Servant objimpl, > > > > > CORBA::Identifier operation > > > > > ); > > > > > }; > > > > > > > > > > -Polar > > > > > > > > I'm not at all comfortable with using PortableServer::Servant here. > > > > CORBA 2.3 (and earlier versions) explicitly acknowledge > that there might > > > > be multiple object adapters: .... > However, to have the ORB create a reference for a servant for which it > already has an invocation, seems to be an inefficient way of getting the > job done. Especially, if you consider that the "interceptor" should be > called for local stubs on the object reference. If the access decision > needs to call "_get_domain_managers" on the object reference, then a > recursive interception would result. Providing the interceptor machinery > to avoid that scenario would complicate matters to no end. > > > > The question is, should the security service be providing such complex > > > access decisions, or should it be prohibited from doing so, > > > leaving access decision to another "service"? > > > > Or maybe just acknowledge that some kinds of access decisions are best > > made by the Servants themselves. I disagree. Most all access decisions will be made based on information that is available in the servant or applications. That doesn't mean that the servant is the best place to make that decision. While this is more difficult than making a decision based on interface it is not unmanageable. DASCOM, and I'm sure others, are getting experience now in making decisions based on factors other than interface. The problem can be separated into parts; 1) associating a policy evaluator with the access decision point, 2) getting the additional information from the servant/application into the AccessDecision function, 3) making the access decision from all of the pertinent information. This can be described as taking the code that would have made the decision in the servant and externalizing it. The benefit of this is that the servant doesn't have to change if the policy changes. It also means that the information necessary for evaluating under the current and future policies must be available. Again, that sounds more problematic than it is. There are typically a standard set of factors (e.g., identity, PAC, date/time) that are shared across all access decision evaluators. Then there are some application specific fields that are important for a specific access decision point (e.g., withdrawal amount, account). This can be managed using typed access decision evaluators. The type can be defined by an interface signature or any other means that seems appropriate. While this seems like it might be a lot of work it is better than putting the access decision code into the application. Just ask your customers (if they disagree would you let me know? :^). > That will be true in any case. And I am in whole hearted agreement with > your statement. First of all, I don't think access decision should be in > the security service at all, it should be a separate service that > applications can take advantage of, in either interceptors or their own > applications. The security service, being heavily integrated in the ORB > (through transport, SECIOP, SSLIOP, service context, etc) should provide > (simply) the wherewithall to make an intelligent access and trust > decision. So you can use an ORB with a security service, and use somebody > else's AccessDecision logic as a different service. But that's just my two > cents worth. Until ORB's become operating systems, in which the ORB lies > in a separate protected space, and applications are separated from that > space, the point is really moot. > > Actually, for "general" purpose security, as you put it, I don't see a > real need for an AccessDecision interface at all. If anything, for > "general" purpose security, the AccessDecision interface should be the > request level interceptor itself. There is really no need to expose > anything to the application if the decision is going to be made before the > servant gets the dispatch. If you are talking about making decisions based on interfaces I agree. There is little benefit to having the application participate in this level of decision. The current AccessDecision is useful when called within a security interceptor. To me that's useful because it means that you can replace the AccessDecision implementation that the interceptor uses as well as replace the AccessDecision function that's visible to the application. Typical benefit of having a standardized interface signature for a service. > > > However, my interpretation of what you stipulate above, is apparently, > > > BOA, POA, it just doesn't matter, because all you need is *an* "Object > > > Adaptor" and there is no requirement, or standard requirement > for an ORB > > > to implement either the POA or BOA. > > > > > > Is that interpretation really true? > > > Or do *all* CORBA 2.3 ORBS require a standard POA implementation? > > > > A CORBA 2.2 or CORBA 2.3 compliant ORB must implement the POA. But it > > is not prohibited from implementing other object adapters as well. > > Yeah, okay, an besides my treatise above, we have a problem with the > current specification. Why don't/shouldn't we supply interfaces that ahere > to a tight model that provides efficient use of it. This is closely > "system" related stuff. I don't understand the ramifications of Bob's reply. Even if a compliant ORB has implemented the POA does that guarantee that all objects bound to the ORB are accessible through a POA? Is the functionality provided by the POA guaranteed to be there for every object invocation? =bill X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 7 Jul 1999 18:27:08 -0400 (EDT) From: Polar Humenn To: William Z Pope cc: Bob Kukura , sec-rev@omg.org Subject: RE: AccessDecision Bill, I agree with your points that you made on Bob's reply, so I'll snip those out and prune this hairy message. Thanks for joining in. On Wed, 7 Jul 1999, William Z Pope wrote: > [snip] > The benefit of this is that the servant doesn't have to change if > the policy changes. [snip] I just wanted to echo that sentiment. > > That will be true in any case. And I am in whole hearted agreement with > > your statement. First of all, I don't think access decision should be in > > the security service at all, it should be a separate service that > > applications can take advantage of, in either interceptors or their own > > applications. The security service, being heavily integrated in the ORB > > (through transport, SECIOP, SSLIOP, service context, etc) should provide > > (simply) the wherewithall to make an intelligent access and trust > > decision. So you can use an ORB with a security service, and use somebody > > else's AccessDecision logic as a different service. But that's just my two > > cents worth. Until ORB's become operating systems, in which the ORB lies > > in a separate protected space, and applications are separated from that > > space, the point is really moot. > > > > Actually, for "general" purpose security, as you put it, I don't see a > > real need for an AccessDecision interface at all. If anything, for > > "general" purpose security, the AccessDecision interface should be the > > request level interceptor itself. There is really no need to expose > > anything to the application if the decision is going to be made before the > > servant gets the dispatch. > > If you are talking about making decisions based on interfaces I agree. > There > is little benefit to having the application participate in this level of > decision. > > The current AccessDecision is useful when called within a security > interceptor. To me that's useful because it means that you can replace > the AccessDecision implementation that the interceptor uses as well as > replace the AccessDecision function that's visible to the application. > Typical benefit of having a standardized interface signature for a service. I don't see it, why then just you don't replace the security interceptor? Assuming that the "security" interceptor is the only thing calling the access decision object, it really needs to understand the semantics behind the access decision object. Of course, we could get to all kinds of levels of replaceablity, but let's not go "too" far, and muck up the works. If you can replace the AccessDecision object, there really isn't a need for a security interceptor, so to speak, or the interceptor's implemenation must be the *same* for ALL ORBs. I don't get it. I think the AccessDecision object is used to "explain" a model of a service that could be provided/enforced by a security interceptor and what it would need to do this. I say this because there is also an implication of AccessDecision implementation (RR/AP), which would proclude it's replacement in any case. I still think Access Control should be a separate service above the security service. But I think we are stuck in anycase. Got any suggestions? > > > > However, my interpretation of what you stipulate above, is apparently, > > > > BOA, POA, it just doesn't matter, because all you need is *an* "Object > > > > Adaptor" and there is no requirement, or standard requirement > > for an ORB > > > > to implement either the POA or BOA. > > > > > > > > Is that interpretation really true? > > > > Or do *all* CORBA 2.3 ORBS require a standard POA implementation? > > > > > > A CORBA 2.2 or CORBA 2.3 compliant ORB must implement the POA. But it > > > is not prohibited from implementing other object adapters as well. > > > > Yeah, okay, an besides my treatise above, we have a problem with the > > current specification. Why don't/shouldn't we supply interfaces that ahere > > to a tight model that provides efficient use of it. This is closely > > "system" related stuff. > > I don't understand the ramifications of Bob's reply. Even if a compliant > ORB has implemented the POA does that guarantee that all objects bound to > the ORB are accessible through a POA? Is the functionality provided by > the POA guaranteed to be there for every object invocation? Well, only for 2.3 compliant ORBs, which is what this RTF is focused on. My question is do we really have to provide interfaces that work with "value-added" orbs (like ones that want to keep the BOA around)? -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: "William Z Pope" To: "Polar Humenn" Cc: "Bob Kukura" , , "Konstantin Beznosov" Subject: RE: AccessDecision Date: Wed, 7 Jul 1999 18:01:04 -0700 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal Polar, I expanded on some of the ideas a little more to expose the rationale behind it. Basically that the ADO that is called from within the security interceptor is a different beast than the ADO that is called from an application. The differences may be exposed through formal interfaces or hidden behind the implementation. > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Wednesday, July 07, 1999 3:27 PM > To: William Z Pope > Cc: Bob Kukura; sec-rev@omg.org > Subject: RE: AccessDecision > > > Bill, > > I agree with your points that you made on Bob's reply, so I'll snip those > out and prune this hairy message. Thanks for joining in. > > > On Wed, 7 Jul 1999, William Z Pope wrote: > > > [snip] > > > The benefit of this is that the servant doesn't have to change if > > the policy changes. [snip] > > I just wanted to echo that sentiment. > > > > That will be true in any case. And I am in whole hearted > agreement with > > > your statement. First of all, I don't think access decision > should be in > > > the security service at all, it should be a separate service that > > > applications can take advantage of, in either interceptors or > their own > > > applications. The security service, being heavily integrated > in the ORB > > > (through transport, SECIOP, SSLIOP, service context, etc) > should provide > > > (simply) the wherewithall to make an intelligent access and trust > > > decision. So you can use an ORB with a security service, and > use somebody > > > else's AccessDecision logic as a different service. But > that's just my two > > > cents worth. Until ORB's become operating systems, in which > the ORB lies > > > in a separate protected space, and applications are separated > from that > > > space, the point is really moot. > > > > > > Actually, for "general" purpose security, as you put it, I don't see a > > > real need for an AccessDecision interface at all. If anything, for > > > "general" purpose security, the AccessDecision interface should be the > > > request level interceptor itself. There is really no need to expose > > > anything to the application if the decision is going to be > made before the > > > servant gets the dispatch. > > > > If you are talking about making decisions based on interfaces I agree. > > There > > is little benefit to having the application participate in this level of > > decision. > > > > The current AccessDecision is useful when called within a security > > interceptor. To me that's useful because it means that you can replace > > the AccessDecision implementation that the interceptor uses as well as > > replace the AccessDecision function that's visible to the application. > > Typical benefit of having a standardized interface signature > for a service. > > I don't see it, why then just you don't replace the security interceptor? You could, but that replaces all of the security infrastructure just to bring in a different authorization implementation. I think we are probably going to end up with a model where the ORB vendors provide the security interceptor functionality as part of the ORB. There is some value add there today for Security Service vendors as we can provide the secure interoperability that the ORB vendors haven't been able to. This will hopefully change as a result of CSI V2. The value add that Security Service vendors can continue to bring to the table is authorization that is tailored to a specific installation. Why those differ and what's important is what we're all working out as fast as we can. If the security interceptor implementation becomes a commodity part of the ORB and the Security Service vendors concentrate on value add authorization then there needs to be a replaceable interface where the access decision functionalit gets plugged in. > Assuming that the "security" interceptor is the only thing calling the > access decision object, it really needs to understand the semantics behind > the access decision object. Of course, we could get to all kinds of levels > of replaceablity, but let's not go "too" far, and muck up the works. Agreed, this model is most useful if the security interceptor is calling the AccessDecision object that uses the CORBA default protection, i.e., interface based. The ADO at this level makes use of only credential, servant (maybe), interface, and method to make the decision. This is basically keeping the existing Level 1 security model in place. > If you can replace the AccessDecision object, there really isn't a need > for a security interceptor, so to speak, or the interceptor's > implemenation must be the *same* for ALL ORBs. I don't get it. My reasoning is, the security interceptor has the job of integrating the security service with the ORB implementation. In the coming perfect world you would only need one of these, for now you need one for each ORB. Having said that there is still benefit in maintaining the separation. Having the security interceptor call the AccessDecision object also maintains the separation of the access decision policy establishment and enforcement from the underlying security mechanism. The security interceptor takes care of the secure association establishement, data protection, transfer of context information, and transfer of authorization information. The AccessDecision object takes care of authorization policy. These are connected by the current, standard, ADO interface definition. > I think the AccessDecision object is used to "explain" a model of a > service that could be provided/enforced by a security interceptor and what > it would need to do this. I say this because there is also an implication > of AccessDecision implementation (RR/AP), which would proclude it's > replacement in any case. > > I still think Access Control should be a separate service above the > security service. But I think we are stuck in anycase. > > Got any suggestions? I think I'm agreeing with you. The distinction is that there is an ADO that is replaceable, called from within the security interceptor that provides the Sec Level 1 functionality. The ADO-NextGen that is visible to applications provides a standard way to include application specific information in the decision process. RAD starts down this path. They punt a little on how application specific information is brought into the decision process. The spec seems to suggest a pull model, the dynamic attribute interface goes out and retrieve the appropriate information. I favor a push model but aren't strongly wedded to it. The application visible ADO-NG is the callable interface into the separate authorization service. If you assume the RAD model, with behind the scenes extraction of the information the ADO-NG could just be an instance of the current ADO that does "special" things to the application to gather the necessary information. Again, I prefer explicit interfaces but would like to hear the rationale behind the decisions made for RAD first. > > > > > However, my interpretation of what you stipulate above, > is apparently, > > > > > BOA, POA, it just doesn't matter, because all you need is > *an* "Object > > > > > Adaptor" and there is no requirement, or standard requirement > > > for an ORB > > > > > to implement either the POA or BOA. > > > > > > > > > > Is that interpretation really true? > > > > > Or do *all* CORBA 2.3 ORBS require a standard POA implementation? > > > > > > > > A CORBA 2.2 or CORBA 2.3 compliant ORB must implement the > POA. But it > > > > is not prohibited from implementing other object adapters as well. > > > > > > Yeah, okay, an besides my treatise above, we have a problem with the > > > current specification. Why don't/shouldn't we supply > interfaces that ahere > > > to a tight model that provides efficient use of it. This is closely > > > "system" related stuff. > > > > I don't understand the ramifications of Bob's reply. Even if a > compliant > > ORB has implemented the POA does that guarantee that all > objects bound to > > the ORB are accessible through a POA? Is the functionality provided by > > the POA guaranteed to be there for every object invocation? > > Well, only for 2.3 compliant ORBs, which is what this RTF is focused on. > My question is do we really have to provide interfaces that work with > "value-added" orbs (like ones that want to keep the BOA around)? Wow, got much wordier than I intended. =bill Date: Thu, 08 Jul 1999 10:52:01 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en To: Polar Humenn CC: William Z Pope , sec-rev@omg.org Subject: Re: AccessDecision Polar Humenn wrote: [...] > Well, only for 2.3 compliant ORBs, which is what this RTF is focused on. > My question is do we really have to provide interfaces that work with > "value-added" orbs (like ones that want to keep the BOA around)? Its not the RTF's responsibility to explicitly deal with value-add that ORBs might provide. But I think that it is the RTF's responsibility to apply good engineering practices, and to preserve the flexibility to implement ORBs in different ways. Some ORB implementations might tighly integrate the POA with the security service and everything else. Other ORB implementations might try to decouple these things, possibly allowing them to be individually replacable. I think it would be best to avoid requiring this kind of coupling in every ORB implementation if possible. In a different article in this thread, Polar wrote: > Apparently, how can we provide cohabitations with things that aren't > standardized? aka OA's that we don't know about. If we must abstract away > from the fact that there is an object adaptor, what good is the standard? > This security stuff should really be aligned as close to the "system" as > possible. That, I believe, is why there are a lot of locality constrained > interfaces. I'd rather use the type system to enforce certain architecture > issues. > This is assuming that the POA is somehow more "close to the system" than other ORB services (such as security) might be. The value of the POA is that it supports portable object implementations. I'm sure that neither the OMA nor the object model section of CORBA in any way imply that all object implementations are necessarily POA-based. So why should the security service make this assumption if it is not absolutely necessary? Similarly, I'd hate to see the Portable Interceptors specification end up assuming object implementations are POA-based. Parts of Security may be worth specifying in a POA specific way, though. For example, I think it would be reasonable to associate DomainManagers with POAs. But this isn't introducing the kind of coupling that the proposed AccessDecision interface does, if its described something like: "Its the responsibility of the Object Adapter to associate object implementations with DomainManagers. The POA does this by ...". > > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > Principal 2-212 Center for Science & Technology > mailto:polar@adiron.com CASE Center/Syracuse University > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com -Bob Sender: jis@fpk.hp.com Date: Thu, 08 Jul 1999 11:19:56 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Bob Kukura CC: Polar Humenn , sec-rev@omg.org Subject: Re: AccessDecision Bob Kukura wrote: > > Polar Humenn wrote: > > > > Is there any more discussion about bringing the access decision object in > > line with the current credentials model and the POA? Namely: > > > > interface AccessDecision { //locality constrained > > boolean access_allowed( > > ReceivedCredentials creds, > > POA::Servant objimpl, > > CORBA::Identifier operation > > ); > > }; > > > > -Polar > > I'm not at all comfortable with using PortableServer::Servant here. > CORBA 2.3 (and earlier versions) explicitly acknowledge that there might > be multiple object adapters: I generally tend to agree with Bob's position here for various reasons. I think this is easy to address though. All that you are interested in placing in the access decision object is a "cookie" that contains information about what kind of OA it was created by, and info that allows said OA to locate the implementation in it. So conceptually, what you want is something like: typedef short OAType; const OAType BOA = 1; conts OAType POA = 2; // etc. etc. struct ObjectImplInfo { OAType adapter_type; unsigned long long impl_info; // or some such }; interface AccessDecision { // locality constrained boolean access_allowed( ReceivedCredentials creds, ObjectImplInfo objimpl, CORBA::Identifier operation ); }; There perhaps are other more efficient ways of doing this - left as an exercise. The assumption here is that the AccessDecision object needs enough info to be able to invoke an operation of the OA or an agent within it to get some things taken care of - and hence the assumption is that the said agent provides an operation for the AccessDecision object to invoke. > > > > However, there could be a need for "more complex" access decisions, which > > requires more information, particularly based on attributes answered by > > the implementation of the object. Also, namely, this pestky > > "_get_domain_managers" operation. > > If you are talking about having the AccessDecision object invoke > IDL-defined operations/attributes of the Servant, then I don't see how > this possibly could relate to a general-purpose security service. If > its an application specific thing, then we'd still have the problem of > the AccessDecision object having to figure out which type of servant an > invocation is for, and then doing the right thing for that type. I > really doubt the majority of users want/need to get into this kind of > thing. If they really need to, can't they always just implement access > decisions in the methods of their servants? > > Couldn't the DomainManager be provided to the AccessDecision object via > either a parameter or an attribute of SecurityLevel2::Target? I'm not > sure having the Servant helps in (efficiently) getting the > DomainManager, anyway. The ORB could probably do better than to convert > the Servant to a reference and then invoke _get_domain_managers on the > reference. > I have always considered a domain manager to be the same in spirit as an IR. So when get_interface is called the ORB forwards the request to the IR associated with it, similarly, when get_domain_managers is called, the ORB serving the object forwards the request to the domain manager that was associated with the object. To do this the server in POA or the ORB itself (depending on where you want to itnercept the _get_domain_managers call) simply needs to know a single local entery point to the local Domain Manager Manager (DMM for the want of a better name) to invoke, with the object key (which it knows, and presumably the servent has registered with the local DMM), and the POA Id Id. The association between local object keys and associated domain managers has to be managed by this local DMM, which needs to have some persistent data. So, yes, the ORB has no reason to convert the servent to a full-blooded IOR, all that it needs is the object key associated with the object that is invoked. Of course one can come up with all sorts of interesting caching schemes to make this more efficient than requiring an across the network call to a domain manager or to a get_domain_managers each time an access decision is to be made. > Well, only for 2.3 compliant ORBs, which is what this RTF is focused on. > My question is do we really have to provide interfaces that work with > "value-added" orbs (like ones that want to keep the BOA around)? Well, such felxibility will certainly make it easier for me to sell using this standard to potential users of the standard. The lack thereof would be a hinderance. Creating standards is always a balancing act between too tight a set of specs which restricts the usefulness of the standard to a narrower space vs. too broad coverage which introduces inefficiencies. As usual we have to make a judgement call on what is the right balance between the two. I think that providing flexibility in how the implementation is accessed from the AD object would be worthwhile and the obvious cost of it is not that much more. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 8 Jul 1999 11:20:42 -0400 (EDT) From: Polar Humenn To: William Z Pope cc: Bob Kukura , sec-rev@omg.org, Konstantin Beznosov Subject: RE: AccessDecision Bill, On Wed, 7 Jul 1999, William Z Pope wrote: > I expanded on some of the ideas a little more to expose the rationale > behind it. Basically that the ADO that is called from within the > security interceptor is a different beast than the ADO that is called > from an application. The differences may be exposed through formal > interfaces or hidden behind the implementation. Okay, but that's not getting us anywhere on the issue. We all agree that there is a need for access decision, whether it be in the interceptor or the application. The question is, what does it look like and where does it live. We have to agree on several points. First of all, who can see this "AccessDecision" object. I think you basically outlined two (or three?) scenarios. I will try to summarize and bring forth my conclusions to what we really need to figure out. Where does the object implementing the interface live, and what does it look like. The scenarios illustrating the conflicting points are: Say an ORB has the ability to install a security service through an interceptor. Say the Security "Service" supplies automatic access decision in this interceptor. Therefore, there is no need for the Access Decision interface, as it will never be exposed to the application. Whoa! before anybody goes wild. That is not to say that the interface can't exist as a generic specification of an Access Decision object should the application programmer want to build one of his own, its just not part of the security service interfaces that are *exposed* to the application, basically because it serves no purpose. Such a service as the one described above will be supplied by an interceptor. Therefore the access control is buried underneath the interceptor interface. Conclusion on its looks and its abode from *this* scenario: 1. Access Decision object need not be on the Security Manager. 2. Access Decision is not exposed to the Application and need not be specified. Second scenario: Say the ORB supplies SECIOP protocol, SecurityReplaceable, and an automatic call to an Access Decision object. Now I agree, there is a need for an Access Decision object. However, it should be minimal based on CORBA systems and what the "Security Service" can provide it without hampering on the architecture of the ORB, i.e. Credentials, Servant, operation? So, we would have basically, access_allowed(ReceivedCredentials,Servant,Operation). In this case Access Decision should be part of SecurityReplaceable, and not SecurityLevel2. It should be retrievable from a service interface not available to the application. It should be installed the same way you supply a SecurityReplaceable::Vault to a SECIOP based system. Conclusion as for looks and its abode on *this* scenario: 1. Access Decision object need not be on the Security Manager. 2. Access Decision object is part of Security Replaceable. Third scenario: Say the ORB provides interceptors and the installation of a security service providing Credentials and Security Manager. The interceptor writer would like to make use of the security services access decision facility: If the security service "enforces" access control, there is no need for the AccessDecison object or the interceptor calling it, because the call should have not even gotten as far as the interceptor. Any call would be redundant and unecessary. So, only one option exists for this scenario. The security service does not "enforce" the access control, and control passes to the interceptor. This very point means that the "security" service access decision facility is DISCRESIONARY AT BEST, and can hardly be called "enforcement", and therefore I would not call it part of the "security service". Conclusion for looks and abode for *this* scenario: Access Decision object must live on some other interface retrievable for interceptors only (???), and perhaps should exist as a separate service, such as something like RAD. The conglomerate conclusion is that AccessDecision if it exists should be in SecurityReplaceable. It should also state, that if "not" replaced the madatory AccessDecision object works off of the defined "RR/AP" model "out-of-the-box". This should work much like the implication that if the "Vault" is not replaced, "the default implementation" of the Vault must support GSS-Kerberos. How's that for a proposal? The next problem with this "default implemenation" of the Access Decision object, is where does RR and DomainManagers/AccessPolicy live? I would suggest that RR live in SecurityAdmin, and it hang off of a domain. But what do I know? :) I hope you are following my reasoning, and the problems that come about from just having these interfaces "laying around" possibly being misused. BTW, don't worry about being wordy. :) I am going to prune this message and answer specific points made in your message in a subsequent message. -Polar X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 8 Jul 1999 11:41:32 -0400 (EDT) From: Polar Humenn To: William Z Pope cc: Bob Kukura , sec-rev@omg.org, Konstantin Beznosov Subject: RE: AccessDecision On Wed, 7 Jul 1999, William Z Pope wrote: > You could, but that replaces all of the security infrastructure just to > bring in a different authorization implementation. I think we are probably > going to end up with a model where the ORB vendors provide the security > interceptor functionality as part of the ORB. There is some value add > there today for Security Service vendors as we can provide the secure > interoperability that the ORB vendors haven't been able to. This will > hopefully change as a result of CSI V2. The value add that Security > Service vendors can continue to bring to the table is authorization that > is tailored to a specific installation. Why those differ and what's > important is what we're all working out as fast as we can. If the > security interceptor implementation becomes a commodity part of the ORB > and the Security Service vendors concentrate on value add authorization > then there needs to be a replaceable interface where the access decision > functionalit gets plugged in. The above scenario is outlined in my previous message as scenario #2. > > Assuming that the "security" interceptor is the only thing calling the > > access decision object, it really needs to understand the semantics behind > > the access decision object. Of course, we could get to all kinds of levels > > of replaceablity, but let's not go "too" far, and muck up the works. > > Agreed, this model is most useful if the security interceptor is calling > the AccessDecision object that uses the CORBA default protection, i.e., > interface based. The ADO at this level makes use of only credential, > servant (maybe), interface, and method to make the decision. This is > basically keeping the existing Level 1 security model in place. Again, the above in scenario #2. > > If you can replace the AccessDecision object, there really isn't a need > > for a security interceptor, so to speak, or the interceptor's > > implemenation must be the *same* for ALL ORBs. I don't get it. > > My reasoning is, the security interceptor has the job of integrating the > security service with the ORB implementation. In the coming perfect world > you would only need one of these, for now you need one for each ORB. Having > said that there is still benefit in maintaining the separation. > Having the security interceptor call the AccessDecision object also > maintains > the separation of the access decision policy establishment and enforcement > from the underlying security mechanism. The security interceptor takes care > of the secure association establishement, data protection, transfer of > context information, and transfer of authorization information. The > AccessDecision object takes care of authorization policy. These are > connected by the current, standard, ADO interface definition. I guess the above is covered by scenaro #3, but covered by making AccessDecision part of security replaceable. > > I think the AccessDecision object is used to "explain" a model of a > > service that could be provided/enforced by a security interceptor and what > > it would need to do this. I say this because there is also an implication > > of AccessDecision implementation (RR/AP), which would proclude it's > > replacement in any case. > > > > I still think Access Control should be a separate service above the > > security service. But I think we are stuck in anycase. > > > > Got any suggestions? > > I think I'm agreeing with you. The distinction is that there is an ADO > that is replaceable, called from within the security interceptor that > provides the Sec Level 1 functionality. The ADO-NextGen that is visible > to applications provides a standard way to include application specific > information in the decision process. RAD starts down this path. They > punt a little on how application specific information is brought into > the decision process. The spec seems to suggest a pull model, the > dynamic attribute interface goes out and retrieve the appropriate > information. I favor a push model but aren't strongly wedded to it. > > The application visible ADO-NG is the callable interface into the separate > authorization service. If you assume the RAD model, with behind the > scenes extraction of the information the ADO-NG could just be an > instance of the current ADO that does "special" things to the application > to gather the necessary information. Again, I prefer explicit interfaces > but would like to hear the rationale behind the decisions made for RAD > first. Okay, I think RAD is definately a separate service. I don't know what to say at this point. Let's hash out the specifics for AccessDecision as part of Security Replaceable (these things that are visible to interceptors and ORB internals, but not to applications). -Polar X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 8 Jul 1999 12:10:33 -0400 (EDT) From: Polar Humenn To: Bob Kukura cc: William Z Pope , sec-rev@omg.org Subject: Re: AccessDecision On Thu, 8 Jul 1999, Bob Kukura wrote: > > > Polar Humenn wrote: > [...] > > Well, only for 2.3 compliant ORBs, which is what this RTF is focused on. > > My question is do we really have to provide interfaces that work with > > "value-added" orbs (like ones that want to keep the BOA around)? > > Its not the RTF's responsibility to explicitly deal with value-add that > ORBs might provide. But I think that it is the RTF's responsibility to > apply good engineering practices, and to preserve the flexibility to > implement ORBs in different ways. Some ORB implementations might tighly > integrate the POA with the security service and everything else. Other > ORB implementations might try to decouple these things, possibly > allowing them to be individually replacable. I think it would be best > to avoid requiring this kind of coupling in every ORB implementation if > possible. > > In a different article in this thread, Polar wrote: > > > Apparently, how can we provide cohabitations with things that aren't > > standardized? aka OA's that we don't know about. If we must abstract away > > from the fact that there is an object adaptor, what good is the standard? > > This security stuff should really be aligned as close to the "system" as > > possible. That, I believe, is why there are a lot of locality constrained > > interfaces. I'd rather use the type system to enforce certain architecture > > issues. > > > > This is assuming that the POA is somehow more "close to the system" than > other ORB services (such as security) might be. The value of the POA is > that it supports portable object implementations. I'm sure that neither > the OMA nor the object model section of CORBA in any way imply that all > object implementations are necessarily POA-based. So why should the > security service make this assumption if it is not absolutely > necessary? Similarly, I'd hate to see the Portable Interceptors > specification end up assuming object implementations are POA-based. > > Parts of Security may be worth specifying in a POA specific way, > though. For example, I think it would be reasonable to associate > DomainManagers with POAs. But this isn't introducing the kind of > coupling that the proposed AccessDecision interface does, if its > described something like: "Its the responsibility of the Object Adapter > to associate object implementations with DomainManagers. The POA does > this by ...". > Okay, I'll agree with you. So, now the point is what is the information model that we must support to get this down. 1. Server Side. We want to restrict the "replaceable" access decision object to the server side, because that is where it makes sense at a system level. 2. Support for RR/AP. The "default" AccessDecison object must support our CORBA required rights/access policy(RR/AP) model. (Replaceable AccessDecision objects may support other kinds, the interface must be general enough to support, but must be enough to support RR/AP). 3. We have to be careful that "recursive" calls into the security service access decision object implemenations should not happen. Tying the access decision object to an object adaptor (by some way) will give us #1, as I think we all agree that an OA is needed on the server side. #2 requires us to find a place for the RR to live and be associated with the AP somehow. Getting the AP requires getting a DomainManager for the object implemenation in question. We do not want to restrict the interface to be given those objects, as more general notions of access decision based on the object will be needed as well. If the object adaptor can give us the domain manager of the object without making a call on the object, fine. But we also need the object implemenation (without a local stub, because it might get recuursively intercepted, should we make a call on the object implemenation for information, point #3). Can a generic interface within the type system be formulated to handle this? How can we do this? Do it simply, and do it within an RTF? -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: "David M. Chizmadia" To: Subject: Re: AccessDecision Date: Thu, 8 Jul 1999 15:20:25 -0400 X-Mailer: Microsoft Outlook Express 4.71.1712.3 Polar, I ery much like the idea of putting AccessDecision on SecurityReplaceable. See my comments on your scenario questions, inline: -DMC -----Original Message----- From: Polar Humenn To: Bob Kukura Cc: William Z Pope ; sec-rev@omg.org Date: Thursday, July 08, 1999 12:14 PM Subject: Re: AccessDecision > >Okay, I'll agree with you. So, now the point is what is the information >model that we must support to get this down. > >1. Server Side. We want to restrict the "replaceable" access decision >object to the server side, because that is where it makes sense at a >system level. > >2. Support for RR/AP. The "default" AccessDecison object must support our >CORBA required rights/access policy(RR/AP) model. (Replaceable >AccessDecision objects may support other kinds, the interface must be >general enough to support, but must be enough to support RR/AP). > >3. We have to be careful that "recursive" calls into the security service > access decision object implemenations should not happen. > >Tying the access decision object to an object adaptor (by some way) will >give us #1, as I think we all agree that an OA is needed on the server >side. > >#2 requires us to find a place for the RR to live and be associated with >the AP somehow. Getting the AP requires getting a DomainManager for the >object implemenation in question. We do not want to restrict the interface >to be given those objects, as more general notions of access decision >based on the object will be needed as well. > >If the object adaptor can give us the domain manager of the object without >making a call on the object, fine. But we also need the object >implemenation (without a local stub, because it might get recuursively >intercepted, should we make a call on the object implemenation for >information, point #3). Can a generic interface within the type system be >formulated to handle this? > >How can we do this? Do it simply, and do it within an RTF? I've been thinking about this since the initial proposal to remove AccessDecision because of its specialization to RequiredRights - and the only reasonable home that I found for a more general version of RequiredRights is the AccessDecision interface. To generalize the concept, I would suggest that we use "access restriction" rather than "required right" - this opens the way for other models of interface operation grouping and access control. Specifically, this would imply that RequiredRights goes away as a separate object and RequiredRights::get_required_rights becomes AccessDecision:: get_access_restrictions. I think that this satisfies #2, since the mechanism for reading interface operation grouping and restriction information is now bound up in a replaceable unit (AccessDecision) with the logic (access_allowed) that will use the information. This does, of course, beg the question of the mechanism used for writing interface operation grouping and restriction information. > >-Polar -DMC From: "William Z Pope" To: "Polar Humenn" Cc: "Bob Kukura" , , "Konstantin Beznosov" Subject: RE: AccessDecision Date: Thu, 8 Jul 1999 13:37:52 -0700 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal Hi, I seem to make my points obtusely. It is a good idea to put the access decision into security replaceable. I think that there also must be a flavor of access decision that is exposed to applications. This flavor is intended to be called by applications with enough information to identify an access point, rather than an object or servant, and the application information necessary to perform the access decision. =bill > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Thursday, July 08, 1999 8:21 AM > To: William Z Pope > Cc: Bob Kukura; sec-rev@omg.org; Konstantin Beznosov > Subject: RE: AccessDecision > > > > Bill, > > On Wed, 7 Jul 1999, William Z Pope wrote: > > > I expanded on some of the ideas a little more to expose the rationale > > behind it. Basically that the ADO that is called from within the > > security interceptor is a different beast than the ADO that is called > > from an application. The differences may be exposed through formal > > interfaces or hidden behind the implementation. > > Okay, but that's not getting us anywhere on the issue. We all agree that > there is a need for access decision, whether it be in the interceptor or > the application. The question is, what does it look like and where does it > live. > > We have to agree on several points. First of all, who can see this > "AccessDecision" object. I think you basically outlined two (or three?) > scenarios. I will try to summarize and bring forth my conclusions to what > we really need to figure out. Where does the object implementing the > interface live, and what does it look like. > > The scenarios illustrating the conflicting points are: > > Say an ORB has the ability to install a security service through an > interceptor. Say the Security "Service" supplies automatic access decision > in this interceptor. Therefore, there is no need for the Access Decision > interface, as it will never be exposed to the application. > > Whoa! before anybody goes wild. That is not to say that the interface > can't exist as a generic specification of an Access Decision object should > the application programmer want to build one of his own, its just not part > of the security service interfaces that are *exposed* to the application, > basically because it serves no purpose. > > Such a service as the one described above will be supplied by an > interceptor. Therefore the access control is buried underneath the > interceptor interface. > > Conclusion on its looks and its abode from *this* scenario: > 1. Access Decision object need not be on the Security Manager. > 2. Access Decision is not exposed to the Application and need not be > specified. > > Second scenario: > > Say the ORB supplies SECIOP protocol, SecurityReplaceable, and an > automatic call to an Access Decision object. > > Now I agree, there is a need for an Access Decision object. However, it > should be minimal based on CORBA systems and what the "Security > Service" can > provide it without hampering on the architecture of the ORB, i.e. > Credentials, Servant, operation? So, we would have basically, > access_allowed(ReceivedCredentials,Servant,Operation). > > In this case Access Decision should be part of SecurityReplaceable, and > not SecurityLevel2. It should be retrievable from a service interface not > available to the application. It should be installed the same way you > supply a SecurityReplaceable::Vault to a SECIOP based system. > > Conclusion as for looks and its abode on *this* scenario: > 1. Access Decision object need not be on the Security Manager. > 2. Access Decision object is part of Security Replaceable. > > Third scenario: > > Say the ORB provides interceptors and the installation of a security > service providing Credentials and Security Manager. > > The interceptor writer would like to make use of the security services > access decision facility: > > If the security service "enforces" access control, there is no need for > the AccessDecison object or the interceptor calling it, because the call > should have not even gotten as far as the interceptor. Any call would be > redundant and unecessary. So, only one option exists for this scenario. > > The security service does not "enforce" the access control, and control > passes to the interceptor. This very point means that the "security" > service access decision facility is DISCRESIONARY AT BEST, and can hardly > be called "enforcement", and therefore I would not call it part of the > "security service". > > Conclusion for looks and abode for *this* scenario: > > Access Decision object must live on some other interface retrievable for > interceptors only (???), and perhaps should exist as a separate service, > such as something like RAD. > > The conglomerate conclusion is that AccessDecision if it exists should be > in SecurityReplaceable. It should also state, that if "not" replaced the > madatory AccessDecision object works off of the defined "RR/AP" model > "out-of-the-box". This should work much like the implication that if the > "Vault" is not replaced, "the default implementation" of the Vault must > support GSS-Kerberos. > > How's that for a proposal? > > The next problem with this "default implemenation" of the Access Decision > object, is where does RR and DomainManagers/AccessPolicy live? I would > suggest that RR live in SecurityAdmin, and it hang off of a domain. But > what do I know? :) > > I hope you are following my reasoning, and the problems that come about > from just having these interfaces "laying around" possibly being misused. > > BTW, don't worry about being wordy. :) > > I am going to prune this message and answer specific points made in your > message in a subsequent message. > > -Polar > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 8 Jul 1999 16:50:44 -0400 (EDT) From: Polar Humenn To: "David M. Chizmadia" cc: sec-rev@omg.org Subject: Re: AccessDecision On Thu, 8 Jul 1999, David M. Chizmadia wrote: > Polar, > > I ery much like the idea of putting AccessDecision on > SecurityReplaceable. > > Polar writes: > > >How can we do this? Do it simply, and do it within an RTF? > > I've been thinking about this since the initial proposal to remove > AccessDecision because of its specialization to RequiredRights - and > the only reasonable home that I found for a more general version of > RequiredRights is the AccessDecision interface. Remove or move? > To generalize the > concept, I would suggest that we use "access restriction" rather > than "required right" - this opens the way for other models of > interface operation grouping and access control. Specifically, > this would imply that RequiredRights goes away as a separate object > and RequiredRights::get_required_rights becomes AccessDecision:: > get_access_restrictions. What does this operation placed on the same interface have to do with making an access decision behind the "access_allowed" operation? > I think that this satisfies #2, since the mechanism for reading > interface operation grouping and restriction information is now > bound up in a replaceable unit (AccessDecision) with the logic > (access_allowed) that will use the information. This does, of > course, beg the question of the mechanism used for writing > interface operation grouping and restriction information. I don't think that solution gets us #2 in my previous message, which was what information do we give the "access_allowed" operation in order to support RR/AP. "Supporting RR/AP" means that somehow, the "access_allowed" operation must be able to retrieve the "most derived interface name" and the DomainManager(s) of the object in question, hopefully without going through a local stub. I saw using "PortableServer::Servant" gets us all of that capability. However, trying to find away to generalize this is going to be cumbersome and diffcult, that I doubt we will reach a suitable solution, and it just may have to stay somewhat broken. On a slight aside: I don't mind the concept of the "RequiredRights" object (but I do have problems with the crazy semantics of the interface and its combinator, e.g. "only 1 of n required rights is required"). I do think that the Required Rights object should be part of SecurityAdmin, because it *is* security administration, and it should be a non-locality contrained interface, and it should be associated with a domain (of sorts, such like the IR is, through resolve initial references). -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Sender: jis@fpk.hp.com Date: Thu, 08 Jul 1999 17:48:55 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Polar Humenn CC: William Z Pope , Bob Kukura , sec-rev@omg.org, Konstantin Beznosov Subject: Re: AccessDecision Polar Humenn wrote: > The first and second are only guesses. Jishnu points out the domain > managers might be retrieved with out incarnating the object in the POA, > but I'm not sure about most derived interface, which I think is definately > only supplied by Servant::primary_interface. Just like Woodward and Bernstein's dictum of "Follow the Money" in "All the President's Men", the dictum to abide by here is "Follow the Information". Figure out how the said serveant figures out which primary interface one is looking for. What is received over the wire is the info in the object reference for the object being invoked. This includes two critical pieces of information - (1) The POA Id, and (2) the Object Key. That is all that the Servant or anyone else has available to them to resolve the request to the actual object that is to be invoked. A generally usable approach is to have what I called the DMM maintain a map between and Domain Manager. That way you can go directly to the DMM with what comes in over the wire and get the domain manager info. This simply requires that whenever a domain membership is created or changed, the new association between and the new domain manager be recorded in the DMM. All this works in terms of the basic information flow that is involved in resolving an object invocation to a specific hunk of code, so I don't see why this little extra tweak would not work to associate a domain manager with the same hunk of code, albeit a bit indirectly. Afterall, ultimately it is the hunk of code and data that is accessed that is to be protected no? Bottom line is, I believe that trying to manage this association between objects and domain managers without intimate cooperation of an ORB is at least a very inefficient exercise if not a totally futile one. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 8 Jul 1999 18:00:42 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: William Z Pope , Bob Kukura , sec-rev@omg.org, Konstantin Beznosov Subject: Re: AccessDecision On Thu, 8 Jul 1999, Jishnu Mukerji wrote: > Polar Humenn wrote: > > > The first and second are only guesses. Jishnu points out the domain > > managers might be retrieved with out incarnating the object in the POA, > > but I'm not sure about most derived interface, which I think is definately > > only supplied by Servant::primary_interface. > > Just like Woodward and Bernstein's dictum of "Follow the Money" in "All > the President's Men", the dictum to abide by here is "Follow the > Information". Figure out how the said serveant figures out which primary > interface one is looking for. What is received over the wire is the info > in the object reference for the object being invoked. This includes two > critical pieces of information - (1) The POA Id, and (2) the Object Key. I believe "over the wire" is an opaque object key, of which a Portable Server may map to a . The object key over the wire need not be a pair directly. Hence with your point below. Without intimate cooperation from the ORB this excersize should be futile to provide as a general service. The question is then, is the AccessDecision object broken, and what should we do about it? -Polar > That is all that the Servant or anyone else has available to them to > resolve the request to the actual object that is to be invoked. A > generally usable approach is to have what I called the DMM maintain a > map between and Domain Manager. That way you can go > directly to the DMM with what comes in over the wire and get the domain > manager info. This simply requires that whenever a domain membership is > created or changed, the new association between and > the new domain manager be recorded in the DMM. All this works in terms > of the basic information flow that is involved in resolving an object > invocation to a specific hunk of code, so I don't see why this little > extra tweak would not work to associate a domain manager with the same > hunk of code, albeit a bit indirectly. Afterall, ultimately it is the > hunk of code and data that is accessed that is to be protected no? > > Bottom line is, I believe that trying to manage this association between > objects and domain managers without intimate cooperation of an ORB is at > least a very inefficient exercise if not a totally futile one. > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: "David M. Chizmadia" To: Subject: Re: AccessDecision Date: Thu, 8 Jul 1999 18:45:52 -0400 X-Mailer: Microsoft Outlook Express 4.71.1712.3 Polar, Just to float a different perspective... If we start from the premise that we are dealing with a (nominally) security-aware server: what if we levy a requirement that the server register its MDI with the security service during its initialization phase. This way, there is no up-call (and consequently no problem with local stub recursion), and we have a authoritative MDI for the security service to use. As far as getting the DomainManager, I rather like Jishnu's suggestion that it come from a DMM repository call. To make this more concrete, how about: module SecurityLevel2 : SecurityLevel1 { interface SecurityManager : ... { ... // Server sets effective_mdi during its initialization attribute CORBA::RepositoryId effective_mdi; }; }; >> >> I've been thinking about this since the initial proposal to remove >> AccessDecision because of its specialization to RequiredRights - and >> the only reasonable home that I found for a more general version of >> RequiredRights is the AccessDecision interface. > >Remove or move? Remove. I was refering to the elimination of of both RequiredRights and AccessDecision from the CORBAsec IDL prior to determining a final home. > >On a slight aside: I don't mind the concept of the "RequiredRights" >object (but I do have problems with the crazy semantics of the interface >and its combinator, e.g. "only 1 of n required rights is required"). > >I do think that the Required Rights object should be part of >SecurityAdmin, because it *is* security administration, and it should be a >non-locality contrained interface, and it should be associated with a >domain (of sorts, such like the IR is, through resolve initial >references). Agreed. > >-Polar > >------------------------------------------------------------------- >Polar Humenn Adiron, LLC >Principal 2-212 Center for Science & Technology >mailto:polar@adiron.com CASE Center/Syracuse University >Phone: 315-443-3171 Syracuse, NY 13244-4100 >Fax: 315-443-4745 http://www.adiron.com > > Date: Fri, 9 Jul 1999 09:16:13 +1000 (EST) From: Michi Henning To: "David M. Chizmadia" cc: sec-rev@omg.org Subject: Re: AccessDecision Organization: Triodia Technologies On Thu, 8 Jul 1999, David M. Chizmadia wrote: > To make this more concrete, how about: > > module SecurityLevel2 : SecurityLevel1 { > > interface SecurityManager : ... { Hmmm... there is no such thing as module inheritance in IDL... Cheers, Michi. From: "David M. Chizmadia" To: Subject: Re: AccessDecision Date: Fri, 9 Jul 1999 11:33:47 -0400 X-Mailer: Microsoft Outlook Express 4.71.1712.3 Polar and Paul, Your message on this being the wrong box to think out of is received!! :-) I didn't realize that the POA had taken care of the multiple interfaces problem. On the other hand, it brings up (for me) the issue of what all of this stuff fits together. To be more direct: how does a Server fit together with: (possibly multiple) POA(s), the ORB, and the emerging 1.6 Security Service. I'm not trying to be obnoxious or stupid (I do that without trying :-), but I am trying to figure out both whether the other ideas being proposed make sense AND how to explain them to people who didn't follow these discussions (i.e., the world minus 10 people on this list :-). -DMC -----Original Message----- From: Polar Humenn To: David M. Chizmadia Cc: sec-rev@omg.org Date: Thursday, July 08, 1999 7:22 PM Subject: Re: AccessDecision >On Thu, 8 Jul 1999, David M. Chizmadia wrote: > >> Polar, >> >> Just to float a different perspective... >> >> If we start from the premise that we are dealing with a >> (nominally) security-aware server: what if we levy a >> requirement that the server register its MDI with the >> security service during its initialization phase. This >> way, there is no up-call (and consequently no problem >> with local stub recursion), and we have a authoritative >> MDI for the security service to use. >> >> As far as getting the DomainManager, I rather like >> Jishnu's suggestion that it come from a DMM repository >> call. >> >> To make this more concrete, how about: >> >> module SecurityLevel2 : SecurityLevel1 { >> >> interface SecurityManager : ... { >> >> ... >> >> // Server sets effective_mdi during its initialization >> attribute CORBA::RepositoryId effective_mdi; >> >> }; >> }; >> > >This kind of thing will not work as Servers can dispatch requests to many >servants of different types. The question is correlation of MDI with >servant. > >> >> I've been thinking about this since the initial proposal to remove >> >> AccessDecision because of its specialization to RequiredRights - >> and >> >> the only reasonable home that I found for a more general version of >> >> RequiredRights is the AccessDecision interface. >> > >> >Remove or move? >> >> Remove. I was refering to the elimination of of both >> RequiredRights and AccessDecision from the CORBAsec IDL >> prior to determining a final home. > >Well, I think some people would have a kiniption deprecating such a thing. >However, I don't think we must get that drastic. I believe we should move >AccessDecision to Replaceable. But the question is what information needs >to get to it so that it can at least support the default RR/AP model, and >also be able to handle "enchanced" implemenations. > >> >On a slight aside: I don't mind the concept of the "RequiredRights" >> >object (but I do have problems with the crazy semantics of the >> interface >> >and its combinator, e.g. "only 1 of n required rights is required"). >> > >> >I do think that the Required Rights object should be part of >> >SecurityAdmin, because it *is* security administration, and it should >> be a >> >non-locality contrained interface, and it should be associated with a >> >domain (of sorts, such like the IR is, through resolve initial >> >references). >> >> Agreed. > >Glad you're starting to see it. Anybody else have comments and >suggestions? > >-Polar > >------------------------------------------------------------------- >Polar Humenn Adiron, LLC >Principal 2-212 Center for Science & Technology >mailto:polar@adiron.com CASE Center/Syracuse University >Phone: 315-443-3171 Syracuse, NY 13244-4100 >Fax: 315-443-4745 http://www.adiron.com > Sender: jis@fpk.hp.com Date: Fri, 09 Jul 1999 11:48:06 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Polar Humenn CC: William Z Pope , Bob Kukura , sec-rev@omg.org, Konstantin Beznosov Subject: Re: AccessDecision Polar Humenn wrote: > > On Thu, 8 Jul 1999, Jishnu Mukerji wrote: > > > Polar Humenn wrote: > > > > > The first and second are only guesses. Jishnu points out the domain > > > managers might be retrieved with out incarnating the object in the POA, > > > but I'm not sure about most derived interface, which I think is definately > > > only supplied by Servant::primary_interface. > > > > Just like Woodward and Bernstein's dictum of "Follow the Money" in "All > > the President's Men", the dictum to abide by here is "Follow the > > Information". Figure out how the said serveant figures out which primary > > interface one is looking for. What is received over the wire is the info > > in the object reference for the object being invoked. This includes two > > critical pieces of information - (1) The POA Id, and (2) the Object Key. > > I believe "over the wire" is an opaque object key, of which a Portable > Server may map to a . The object key over the wire need > not be a pair directly. > > Hence with your point below. Without intimate cooperation from the ORB > this excersize should be futile to provide as a general service. > > The question is then, is the AccessDecision object broken, and what should > we do about it? It should be noted that I was not talking of the AccessDecision function. I was talking of how to get to domain managers. The AccessDecision function needs to communicate with the appropriate piece of a "Security/AccessDecision compatible" OA to get access to domain manager and whatever else. In order to do so, it needs info similar to what is used for resolving an invocation to a specific object. Consequently, it stands to reason to say that the "Objimpl" thing that we have been talking about is essentially the pair. How does the AccessDecision object get hold of one of these puppies? The only way is for this info to be extracted from the IIOP message header and placed in a cookie and made available to the appropriate interceptors. It is at this point where cooperation of an ORB is required. An operation like "current_objimpl" which returns this cookie to an interceptor would be most useful don't you think? > Well, I think some people would have a kiniption deprecating such a thing. > However, I don't think we must get that drastic. I believe we should move > AccessDecision to Replaceable. But the question is what information needs > to get to it so that it can at least support the default RR/AP model, and > also be able to handle "enchanced" implemenations. In Rev 1.2 I had proposed that it be present both in Replaceable and where it is now based on the belief that there was a need for this sort of facility both at the Replaceable level and at the Application level. Our friends from ICL had me remove it from the Replaceable module.;-( Nobody else at that time cared where it was back then, and I did not have the time and energy to argue endlessly with Belinda about it. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 12 Jul 1999 11:16:16 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: William Z Pope , Bob Kukura , sec-rev@omg.org, Konstantin Beznosov Subject: Re: AccessDecision On Fri, 9 Jul 1999, Jishnu Mukerji wrote: > Polar Humenn wrote: > > > > On Thu, 8 Jul 1999, Jishnu Mukerji wrote: > > > > > Polar Humenn wrote: > > > > > > > The first and second are only guesses. Jishnu points out the domain > > > > managers might be retrieved with out incarnating the object in the POA, > > > > but I'm not sure about most derived interface, which I think is definately > > > > only supplied by Servant::primary_interface. > > > > > > Just like Woodward and Bernstein's dictum of "Follow the Money" in "All > > > the President's Men", the dictum to abide by here is "Follow the > > > Information". Figure out how the said serveant figures out which primary > > > interface one is looking for. What is received over the wire is the info > > > in the object reference for the object being invoked. This includes two > > > critical pieces of information - (1) The POA Id, and (2) the Object Key. > > > > I believe "over the wire" is an opaque object key, of which a Portable > > Server may map to a . The object key over the wire need > > not be a pair directly. > > > > Hence with your point below. Without intimate cooperation from the ORB > > this excersize should be futile to provide as a general service. > > > > The question is then, is the AccessDecision object broken, and what should > > we do about it? > > It should be noted that I was not talking of the AccessDecision > function. I was talking of how to get to domain managers. > > The AccessDecision function needs to communicate with the appropriate > piece of a "Security/AccessDecision compatible" OA to get access to > domain manager and whatever else. In order to do so, it needs info > similar to what is used for resolving an invocation to a specific > object. Consequently, it stands to reason to say that the "Objimpl" > thing that we have been talking about is essentially the Id> pair. How does the AccessDecision object get hold of one of these > puppies? The only way is for this info to be extracted from the IIOP > message header and placed in a cookie and made available to the > appropriate interceptors. It is at this point where cooperation of an > ORB is required. An operation like "current_objimpl" which returns this > cookie to an interceptor would be most useful don't you think? Well, this may be so, but I doubt that can happen here in the RTF. I am begining to think that if there is sufficient opposition to using "Servant" because it happens to be the standarized way of talking to the ORB for this manner and no body wants to conform to it, then "this object implmenation" concept should be removed completely from AccessDecision. This AccessDecision will be in Replaceable and it should support the RR/AP model directly as a base. We can extend AccessDecision later on in an RFP to get it to work with object references, servants, pairs, whathaveyou. I still do not see one damn problem with using CORBA specifications, such as Servant. However, if that's the beef, that's the beef. I suggest then an AccessDecision object that supports only RR/AP, or some other domain manager based scenario. interface AccessDecision { boolean access_allowed( in ReceivedCredentials creds, in CORBA::DomainManagerList domain_managers, in CORBA::RepositoryId interface_name, in CORBA::Identifier operation_name ); }; Here we cannot get the object implemenation, because apparently that is something that simply cannot be agreed on at this time. We can leave it to the ORB specific interceptor to get the domain manager for the object implemenation (however that is done, is still not even known). The implemention of the object will be off limits to this access decision object. How is that? -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 19 Aug 1999 11:21:44 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Paul H Kyzivat , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > Paul H Kyzivat wrote: > > > > Polar Humenn wrote: > > > > > > Lets suppose we actually recognized servers. > > > > > > Each server would have an administrative interface to its > > > AccessDecision object that can be updated with a typed policy > > > description. Much like I illustrated before about 100 messages ago :) > > > > > > Servers during initialization would register with a Policy > > > Administrative service, call it an Enclave, for its security policy > > > (access decision, auditing, whatever, etc.). So, the server can be > > > notified by the Enclave on updates to the policy within the Enclave. > > > > > > And as you pointed out about 150 messages ago, you would like to bring > > > up a single server and write an ACL for the objects it serves. > > > > > > So, this model can also work for standalone servers, which can plop > > > out the object reference to its administrative interface, and dynamic > > > updates can happen to the server with command line tools. > > > > > > During this process, alot of cool nifty things can be done, such as > > > optimization of the AccessDecision. Also not having to keep asing the > > > AP or RR constantly because something might have changed. > > > > > > Yes, it's a push model. But it seems kind of natural, I think. > > > > I like this. It is the first suggestion I have heard for how all this > > can work that actually appears to scale - permitting access decisions to > > be made totally within the server. > > Well, if this is the direction that we want to take, it is time to start > writing an RFP. This change will be way beyond anything that can be > snuck through an RTF. There will be several ways to skin this cat and > definitely the alternatives need to be considered and everyone with an > idea needs to be given a chance to present it. So, who wants to craft > the requirements to put in an RFP? Whoa! do you think and RFP is quite prudent at this time? (am I sounding like an ex-pres?) I mean, let's do a few presentations, see what is out there, find out a few things first, about feasiblity, implementability, scalability, etc. , and then issue an RFP. ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 16 Aug 1999 15:44:59 -0400 (EDT) From: Polar Humenn To: Bob Blakley cc: Paul H Kyzivat , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Bob, et al. I snipped some stuff, but hopefully, not out of context. On Mon, 16 Aug 1999, Bob Blakley wrote: > When I say broken, I mean something quite specific: the user community > explicitly and unequivocally stated that instance and method granularity > of access policy enforcement was a requirement. But without a way to > identify instances, figure out when they were being invoked on, and associate > policy with them, this was not possible. Bob, the user community who wanted CORBA security, was/still is a small, in relative numbers, to the vast amounts of users who don't give a damn about security. That's hard sell in trying to steer masses from doing something you know they shouldn't. yeah, of course, we in the security community know how to do it right, but everybody else gets it wrong, blah, blah. Is that either we aren't forceful enough, not powerful enough, or not good enough in the marketing department, I don't know. However, the fact is, we have a few things to deal with, and we'd better make them work with the whole shabang, or we can throw the spec in the gar-bage. We have alot there to deal with most of what CORBA needs most at an interoperabilty level. The ability to secure communication of the request, and identify the server and client in a standard way. Some of this still needs more work, but we are close, and CSIv2 should take care of most of those problems. SECIOP is probably the first effort that I know of to actually standardize a protocol for using GSS based mechanisms (although some vendors would only like to see SSL). The Vault is a great way to stuff new security mechanisms into SECIOP. It's just that we have some fundemental problems with dealing with the object abstraction and access control and policy based on their instances, implemenations, and interfaces. We just have to deal with them that's all. But I don't want to get into the mode, of saying the Security group is telling you, you have to build it this way. That's going to go no where. > We worked around this as best we could, with a good deal of help from vendors, > several of whose representatives helped in the preparation of the POA > specification. We believed at the time that the solutions we'd come up with > worked, and we got no arguments from the ORB vendors. There were certainly > in retrospect some problems, which we've been fixing steadily. > > The mechanism we designed had the feature that it was possible to > control the otherwise unmanageable scale of policy data by associating > "required rights" with methods to limit the number of permissions > which need to be managed. In order to manage required rights, it was > necessary to figure out which interface an instance was being invoked > through at the time a message was received by the target ORB/OA. On > this point *again* we consulted the ORB vendors -- in fact again some > of the same people who worked on the POA spec. We were told we could > always determine the most derived interface of an invoked object, and > we relied on this. Yes, but did we come up with implemenations that proved it could be done. No. Did we come up with implemenations that showed the problems at the outset. No. The problem is that we only listened to "our" requirements and the nodding heads of individuals who didn't care about security, or who are no longer around to keep flying the flag so to speak. > Subsequently we were told that in a POA environment it was no longer > possible to determine the most derived interface of an object which > was being invoked. > > In my opinion this left us in the following situation: > > There's no such thing as an object instance - there are only > references and > implementations. But references aren't guaranteed always to > refer to the > same bunch of data, especially over time, so they can't be used to > identify "objects". And there's no way to refer to implementations > except > inside an implementation. > > Furthermore, while objects do support various interfaces, there's no way > to > determine exactly *which* interface an object is being invoked through > when a particular message is received. > > This is a bad situation from a security point of view. Basically it > means that you can't tell *either* which object is being called *or* > which method is being invoked. And yet we're supposed to provide > object-and-method-granularity protection. Well, the fact is that you can't do much about it at this point. But we should work on getting the security specification at least working, or pull out the bits that cannot work. > >I must agree with Paul on this point. The POA didn't break anything, in > >fact it fixed alot of things. The security specification was flawed from > >the outset, and still is. (Excuse me for my tone, as I've already have > >been yelled at by some people for not being politically senstive in my > >comments, but you can pass that off as me being an academic :) > > I've already disagreed with this; while there are things wrong with > the CORBAsecurity specification, if it's broken in this particular > respect it's through no fault of CORBAsecurity -- but rather arises > from fundamental flaws in the underlying ORB and OA specs. If it's > not possible to determine which interface is being invoked, then this > is broken. The CORBAsecurity specification, which predates the POA > specification, requires implementation of the RequiredRights > interface, which assumes that it's possible to determine *at least* > the most-derived interface of an object to which a message has been > addressed. We were led to believe that this was possible in pre-POA > implementations. If this wasn't true, then previous implementations > (and the specs. on which they were based) were broken, and if it still > isn't true, then POA-based implementations are still broken. Ok, but let's get rid of finger pointing "it's not our fault", which is going to get us nowhere. > >> There wasn't enough defined on the server side before to show if/how the > >> MDI could be determined for an object reference, or even how an object > >> reference could be obtained for an incoming reference. The fact that the > >> POA work failed to fix this doesn't mean that it broke anything. > > > >Again, I cannot agree more. > > > >> Next, I don't know what you mean by "move the RequiredRights interfaces > >> to the POA". The POA is little more than a container for servants. All > >> it knows about servants is defined by the servant itself. It can know > >> the MDI of a servant to the extent that primary_interface() makes it > >> available. So there seems little point in asking the POA, which has no > >> relevant capabilities, to provide the RequiredRights interfaces. > > > >Yes, I don't understand that either. I went away on the weekend, so I > >didn't get a chance to ask Bob about this. However, even with the POA, it > >is the Servant that must be activated to find out what the MDI is! The > >POA, as a component, really doesn't enter into the question. > > > >> It sounds like you are suggesting that some vendor proprietary means be > >> used. The likely outcome of that will just be to break portability once > >> again. That is not an acceptable solution. > >> > >> In a POA based environment I see little alternative to using > >> primary_interface() to get an MDI to then use to get the required rights > >> for a request. The mechanics can be adjusted in various ways to meet Bob > >> K's concerns. Passing the MDI to the security service rather than having > >> it deal with the servant directly is one way. > > > >It looks more and more like the above should be the case. > > All of these discussions bother me because they all take place at the level > of implementation rather than abstraction. Basically we seem to me to be > discussing various hacks based on existing implementations, and considering > functional limitations based on the deficiencies of those implementations, > rather than focusing on the abstract model we should be supporting and > the customer requirements for functionality. Not so. Any architect worth his salt, knows that he must get some of his constraints down on his wild abstractions based on previous construction, current construction, and reality. The reality is that we have *implementations* to support. We only have *abstractions* to follow. If we find our implementations insufficient to fullfull a certain abstraction, perhaps something is wrong with the abstraction. Basing designs solely on abstraction is a really bad idea, and we must take in experience of developers and designers alike. That is what the RTF is for, to correct our misconceptions with reality. > I believe that if you want to make a modification to the CORBAsecurity > service which degrades the functionality of the service to this extent, you > need to issue a new RFP and define a new service which provides only > the limited functionality described here. I'm not suggesting that we degrade the funcitonality of the security service. I'm suggesting that we support it with the tools and information that is available today. For the access decision object, I believe in order to provide the level of functionality sought by the security specification, namely domain (managers), interface name, operation name, and the client's credentials, we give an interface with those bits of information in it. Fits the scenario well. We move AccessDecision to the SecurityReplaceable model which will allow vendors or third party service vendors, the ability to write the VENDOR specific glue whether that be in an interceptor or in the ORB itself to get the information needed. > If you don't want to fix the problems with POA (and, evidently, with some > other OAs), then you need to withdraw the current CORBAsecurity > specification and notify the user community that instance-granularity > access control will not in the future be available. Well, that's a good way to pout and to get rid of security, but doesn't solve the problems. Let's talk about this in San Jose. > >> In the end we must just make sure that the security service isn't asking > >> to be provided with information that is unobtainable. > > Sorry, I disagree again. We must just make sure that the security service > is meeting the stated requirements of the OMG customer community. > If meeting those requirements means making some more information > available from ORB implementations, then we should make that > information available, or we should advertise that the implementations > which don't provide it are not securable on the terms the customers > are interested in. Where are these requirements? Where are they documented? I just want to make sure that we aren't scratching our own butts. > Personally, I don't think it's unreasonable to ask ORB implementations > to be able to tell which object instance is being invoked, and which > interface that instance is being invoked through. You should have followed the arguments way back on object substituability, and why this is a *fundmental* problem. We can get into all sorts of arguments about it. > >>And if the > >> security service is concerned about denial of service attacks and so > >> wants to stop a request before significant work has been done, then it > >> had better make sure that the information it needs to make the decision > >> doesn't require all the hard work to already have been done. > > Hmmmm.... I'm not worrying about denial of service attacks AT ALL here - > and in fact CORBAsecurity is *specifically* not designed to prevent these. > What I'm worrying about is access control. > > Regarding "all the hard work", what I'm asking for is the ability to > know which object is being invoked and what interface it's being > invoked through. In principle, this information IS in fact available, > since the correct instances do in fact get invoked in CORBA ORBs, and > the correct method code is in fact activated and run. All I'm asking > for is to have this information made available to the security > service. I'm sorry if this is "hard work", but it is IN PRINCIPLE not > possible for the security service to do the job the customers have > demanded it do, unless this information is provided. Bob, the fact is that you know from a client's perspective what interface you *might* be invoking an operation through. But you cannot emphatically know that on the server side. So what good is it? Security would have to be pervasive into the request, and there would be extreme trust issues that it would not matter. The information in the current IIOP/GIOP spec that gets you the object and the operation is the IIOP: host IIOP: port GIOP: object id (specific to the server) GIOP: operation Unfortunately, the interface doesn't enter into the equation. What are you going to do? -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Polar Humenn" Cc: "Paul H Kyzivat" , , "William Pope" Subject: Re: AccessDecision object Date: Mon, 16 Aug 1999 15:11:21 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 Polar, >Bob, the user community who wanted CORBA security, was/still is a small, >in relative numbers, to the vast amounts of users who don't give a damn >about security. That's hard sell in trying to steer masses from doing >something you know they shouldn't. yeah, of course, we in the security >community know how to do it right, but everybody else gets it wrong, blah, >blah. > >Is that either we aren't forceful enough, not powerful enough, or not good >enough in the marketing department, I don't know. However, the fact is, we >have a few things to deal with, and we'd better make them work with the >whole shabang, or we can throw the spec in the gar-bage. I guess my perspective is different. I think about two things: 1) The OMG has a process. It involves issuing an RFP which states requirements, gathering responses, voting on those responses, adopting a chosen response, and then maintaining it. The maintenance phase is supposed to fix bugs, not add signficant functionality and CERTAINLY not remove significant functionality on the basis of which a spec. was adopted. 2) We could remove ALL of the security functionality -- this would make things very easy for both security service implementors and ORB implementors. But it would make things very hard for the customers (however few) who actually need secure implementations. If a vendor thinks the market for security is small (e.g. too small to justify changes to the ORB required to support secure implementations), that vendor should simply build, advertise, and sell an insecure ORB. If a vendor thinks the secure-ORB market is worth the investment, that vendor should build, advertise, and sell a secure ORB. If a vendor thinks that it would be nice to advertise and sell an ORB as if it were secure, but without doing the work to build an ORB which really is secure...... >We have alot there to deal with most of what CORBA needs most at an >interoperabilty level. The ability to secure communication of the request, >and identify the server and client in a standard way. Some of this still >needs more work, but we are close, and CSIv2 should take care of most of >those problems. SECIOP is probably the first effort that I know of to >actually standardize a protocol for using GSS based mechanisms (although >some vendors would only like to see SSL). The Vault is a great way to >stuff new security mechanisms into SECIOP. > >It's just that we have some fundemental problems with dealing with the >object abstraction and access control and policy based on their instances, >implemenations, and interfaces. We just have to deal with them that's all. I don't agree. We have to deal with them in a way which respects *BOTH* the requirements stated by the users in the CORBAsecurity RFP *AND* the abstractions in the existing CORBAsecurity spec. (including their semantics) --- OR ELSE we need to issue a new RFP. Anything else is I think impermissible in an RTF. >But I don't want to get into the mode, of saying the Security group is >telling you, you have to build it this way. That's going to go no where. I'm sorry, but again this is a misrepresentation. The "security group" isn't telling anyone anything. The *OMG* adopted the CORBAsecurity specification. It's a part of the CORBA architecture. It's in the book. The spec. needs to be revised in a way which fixes the bugs and respects the specified functionality, or else a new RFP needs to be issued. >> We worked around this as best we could, with a good deal of help from vendors, >> several of whose representatives helped in the preparation of the POA >> specification. We believed at the time that the solutions we'd come up with >> worked, and we got no arguments from the ORB vendors. There were certainly >> in retrospect some problems, which we've been fixing steadily. >> >> The mechanism we designed had the feature that it was possible to >> control the otherwise unmanageable scale of policy data by associating >> "required rights" with methods to limit the number of permissions >> which need to be managed. In order to manage required rights, it was >> necessary to figure out which interface an instance was being invoked >> through at the time a message was received by the target ORB/OA. On >> this point *again* we consulted the ORB vendors -- in fact again some >> of the same people who worked on the POA spec. We were told we could >> always determine the most derived interface of an invoked object, and >> we relied on this. > >Yes, but did we come up with implemenations that proved it could be done. >No. Did we come up with implemenations that showed the problems at the >outset. No. > >The problem is that we only listened to "our" requirements and the nodding >heads of individuals who didn't care about security, or who are no longer >around to keep flying the flag so to speak. > >> Subsequently we were told that in a POA environment it was no longer >> possible to determine the most derived interface of an object which >> was being invoked. >> >> In my opinion this left us in the following situation: >> >> There's no such thing as an object instance - there are only >> references and >> implementations. But references aren't guaranteed always to >> refer to the >> same bunch of data, especially over time, so they can't be used to >> identify "objects". And there's no way to refer to implementations >> except >> inside an implementation. >> >> Furthermore, while objects do support various interfaces, there's no way >> to >> determine exactly *which* interface an object is being invoked through >> when a particular message is received. >> >> This is a bad situation from a security point of view. Basically it >> means that you can't tell *either* which object is being called *or* >> which method is being invoked. And yet we're supposed to provide >> object-and-method-granularity protection. > >Well, the fact is that you can't do much about it at this point. But we >should work on getting the security specification at least working, or >pull out the bits that cannot work. I don't believe we have the option of "pulling out the bits that cannot work" without another RFP. I believe that the bugs need to be fixed. >> >I must agree with Paul on this point. The POA didn't break anything, in >> >fact it fixed alot of things. The security specification was flawed from >> >the outset, and still is. (Excuse me for my tone, as I've already have >> >been yelled at by some people for not being politically senstive in my >> >comments, but you can pass that off as me being an academic :) >> >> I've already disagreed with this; while there are things wrong with >> the CORBAsecurity specification, if it's broken in this particular >> respect it's through no fault of CORBAsecurity -- but rather arises >> from fundamental flaws in the underlying ORB and OA specs. If it's >> not possible to determine which interface is being invoked, then this >> is broken. The CORBAsecurity specification, which predates the POA >> specification, requires implementation of the RequiredRights >> interface, which assumes that it's possible to determine *at least* >> the most-derived interface of an object to which a message has been >> addressed. We were led to believe that this was possible in pre-POA >> implementations. If this wasn't true, then previous implementations >> (and the specs. on which they were based) were broken, and if it still >> isn't true, then POA-based implementations are still broken. > >Ok, but let's get rid of finger pointing "it's not our fault", which is >going to get us nowhere. Pointing fingers at people isn't helpful. Pointing fingers at *specs* is necessary, because we need to decide what needs to be fixed, and in order to do that, we need to identify what's broken. I'm not trying to deprecate anyone's work. As I said, I entirely agree that the POA fixes a number of real problems that really needed to be fixed. However there's another set of problems, related to security, which it doesn't fix, and those problems need to be fixed in order to get a working CORBAsecurity implementation. >> >> There wasn't enough defined on the server side before to show if/how the >> >> MDI could be determined for an object reference, or even how an object >> >> reference could be obtained for an incoming reference. The fact that the >> >> POA work failed to fix this doesn't mean that it broke anything. >> > >> >Again, I cannot agree more. >> > >> >> Next, I don't know what you mean by "move the RequiredRights interfaces >> >> to the POA". The POA is little more than a container for servants. All >> >> it knows about servants is defined by the servant itself. It can know >> >> the MDI of a servant to the extent that primary_interface() makes it >> >> available. So there seems little point in asking the POA, which has no >> >> relevant capabilities, to provide the RequiredRights interfaces. >> > >> >Yes, I don't understand that either. I went away on the weekend, so I >> >didn't get a chance to ask Bob about this. However, even with the POA, it >> >is the Servant that must be activated to find out what the MDI is! The >> >POA, as a component, really doesn't enter into the question. >> > >> >> It sounds like you are suggesting that some vendor proprietary means be >> >> used. The likely outcome of that will just be to break portability once >> >> again. That is not an acceptable solution. >> >> >> >> In a POA based environment I see little alternative to using >> >> primary_interface() to get an MDI to then use to get the required rights >> >> for a request. The mechanics can be adjusted in various ways to meet Bob >> >> K's concerns. Passing the MDI to the security service rather than having >> >> it deal with the servant directly is one way. >> > >> >It looks more and more like the above should be the case. >> >> All of these discussions bother me because they all take place at the level >> of implementation rather than abstraction. Basically we seem to me to be >> discussing various hacks based on existing implementations, and considering >> functional limitations based on the deficiencies of those implementations, >> rather than focusing on the abstract model we should be supporting and >> the customer requirements for functionality. > >Not so. Any architect worth his salt, knows that he must get some of his >constraints down on his wild abstractions based on previous construction, >current construction, and reality. There are NO "wild abstractions" in CORBAsecurity. Every abstraction (with the possible exception of the NR service, which we're not discussing here) is based on models and implementations which have been around since the time of MULTICS. In particular, the notion of resource-and-operation-granularity access control goes back to about the time I was born, and we did essentially nothing new in the CORBAsecurity design except design object interfaces to support this abstraction. Ditto the interfaces for message protection, which are almost embarrasingly slavish imitations of the GSS-API context establishment and session-protection model. And one could go on. The abstractions we designed were also based on "current construction, and reality" -- at the time they were designed. In fact we suggested changes to base CORBA to remedy some deficiencies of the "current construction" at that time, and those changes were adopted. >The reality is that we have *implementations* to support. We only have >*abstractions* to follow. If we find our implementations insufficient to >fullfull a certain abstraction, perhaps something is wrong with the >abstraction. Basing designs solely on abstraction is a really bad idea, >and we must take in experience of developers and designers alike. That is >what the RTF is for, to correct our misconceptions with reality. I disagree. An RTF is for fixing bugs, not changing abstractions. Otherwise programmers have no firm ground on which to stand. >> I believe that if you want to make a modification to the CORBAsecurity >> service which degrades the functionality of the service to this extent, you >> need to issue a new RFP and define a new service which provides only >> the limited functionality described here. > >I'm not suggesting that we degrade the funcitonality of the security >service. Sorry, I don't think this is the case. You *did* (unless I significantly misunderstand your previous message) suggest that we declare CORBAsecurity access control to be based on interface and operation only. This removes a functionality (ability to control access at an instance level) which was explicitly required by the CORBAsecurity RFP, and has been a required conformance point up to now. >I'm suggesting that we support it with the tools and information that is >available today. > >For the access decision object, I believe in order to provide the level >of functionality sought by the security specification, namely domain >(managers), interface name, operation name, and the client's credentials, >we give an interface with those bits of information in it. This might or might not be OK; the other important requirement which is (in the spec) supported today is application-transparent security. If an ORB can figure out (without the application's help) which domain manager to pass across the interface you propose, this might be OK. But given the discussion above, I don't understand how you propose to have it do this without fixing the problems I've referred to. >Fits the scenario well. We move AccessDecision to the SecurityReplaceable >model which will allow vendors or third party service vendors, the ability >to write the VENDOR specific glue whether that be in an interceptor or in >the ORB itself to get the information needed. > >> If you don't want to fix the problems with POA (and, evidently, with some >> other OAs), then you need to withdraw the current CORBAsecurity >> specification and notify the user community that instance-granularity >> access control will not in the future be available. > >Well, that's a good way to pout and to get rid of security, but doesn't >solve the problems. Let's talk about this in San Jose. I'm not proposing we do this!! I'm just saying that OMG's process doesn't let us revolutionise (especially by deletion) the functionality of an adopted spec. in an RTF. >> >> In the end we must just make sure that the security service isn't asking >> >> to be provided with information that is unobtainable. >> >> Sorry, I disagree again. We must just make sure that the security service >> is meeting the stated requirements of the OMG customer community. >> If meeting those requirements means making some more information >> available from ORB implementations, then we should make that >> information available, or we should advertise that the implementations >> which don't provide it are not securable on the terms the customers >> are interested in. > >Where are these requirements? Where are they documented? I just want to >make sure that we aren't scratching our own butts. They're documented in the OMG security whitepaper and the security service RFP. >> Personally, I don't think it's unreasonable to ask ORB implementations >> to be able to tell which object instance is being invoked, and which >> interface that instance is being invoked through. > >You should have followed the arguments way back on object substituability, >and why this is a *fundmental* problem. We can get into all sorts of >arguments about it. Actually I did follow them, which is why I began my first message by apologizing for not responding to the list earlier on this topic. We could get into all sorts of arguments, and probably will. I agree it's a fundamental problem -- it has been since day one of the CORBAsecurity design effort. Nevertheless, it needs to get fixed. >> >>And if the >> >> security service is concerned about denial of service attacks and so >> >> wants to stop a request before significant work has been done, then it >> >> had better make sure that the information it needs to make the decision >> >> doesn't require all the hard work to already have been done. >> >> Hmmmm.... I'm not worrying about denial of service attacks AT ALL here - >> and in fact CORBAsecurity is *specifically* not designed to prevent these. >> What I'm worrying about is access control. >> >> Regarding "all the hard work", what I'm asking for is the ability to >> know which object is being invoked and what interface it's being >> invoked through. In principle, this information IS in fact available, >> since the correct instances do in fact get invoked in CORBA ORBs, and >> the correct method code is in fact activated and run. All I'm asking >> for is to have this information made available to the security >> service. I'm sorry if this is "hard work", but it is IN PRINCIPLE not >> possible for the security service to do the job the customers have >> demanded it do, unless this information is provided. > >Bob, the fact is that you know from a client's perspective what interface >you *might* be invoking an operation through. But you cannot emphatically >know that on the server side. So what good is it? > >Security would have to be pervasive into the request, and there would be >extreme trust issues that it would not matter. > >The information in the current IIOP/GIOP spec that gets you the object and >the operation is the > >IIOP: host >IIOP: port >GIOP: object id (specific to the server) >GIOP: operation > >Unfortunately, the interface doesn't enter into the equation. What are you >going to do? The problem is certainly not insoluble in principle; in a Smalltalk ORB, for example, you're never in any doubt about the class of the object being invoked. This is simply information which implementations for one reason or another are not keeping around. It was evidently not necessary information for previous services. For the security service, it IS necessary information. This is the EXACT reason for signing applets in a Java environment -- so that you know what the code which implements "foo.bar" is before you run it on your system and/or your data. It's important for an EXTREMELY obvious reason - you care about what code is running and might want to deny some kinds of code (Melissa? WinCIH?) the opportunity to run on your machine or data. --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom Date: Mon, 16 Aug 1999 16:22:51 -0400 From: John Marsh Organization: Concept Five Technologies X-Mailer: Mozilla 4.07 [en] (WinNT; U) To: Polar Humenn CC: Bob Blakley , Paul H Kyzivat , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object I think the following quote from section 3.7.5 of the CORBA 2.3 spec on Interface Inheritance may fix your problem: "References to base interface elements must be unambiguous. A Reference to a base interface element is ambiguous if the name is declared as a constant, type, or exception in more than one base interface. Ambiguities can be resolved by qualifying a name with its interface name (that is, using a ). It is illegal to inherit from two interfaces with the same operation or attribute name, or to redefine an operation or attribute name in the derived interface." (italics mine) That is, given that you can figure out the MDI - which you can from the object reference - and that you know the operation, you should be able to walk back up the inheritance chain (using the IR (assuming it is installed...)) & figure out which interface was called since it is illegal to reuse a name in an inheritance tree. (It's obviously ugly to do it this way, but I believe that what you want to do can, in fact, be done.) Polar Humenn wrote: > > Bob, et al. > > > The information in the current IIOP/GIOP spec that gets you the object and > the operation is the > > IIOP: host > IIOP: port > GIOP: object id (specific to the server) > GIOP: operation > > Unfortunately, the interface doesn't enter into the equation. What are you > going to do? > > > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > Principal 2-212 Center for Science & Technology > mailto:polar@adiron.com CASE Center/Syracuse > University > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Reply-To: "Bob Blakley" From: "Bob Blakley" To: "John Marsh" , "Polar Humenn" Cc: "Paul H Kyzivat" , , "William Pope" Subject: Re: AccessDecision object Date: Mon, 16 Aug 1999 15:39:26 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 John > > I think the following quote from section 3.7.5 of the CORBA 2.3 spec on > Interface Inheritance may fix your problem: > > "References to base interface elements must be unambiguous. A Reference to a > base > interface element is ambiguous if the name is declared as a constant, type, > or exception > in more than one base interface. Ambiguities can be resolved by qualifying a > name > with its interface name (that is, using a ). It is illegal to > inherit from > two interfaces with the same operation or attribute name, or to redefine an > operation or > attribute name in the derived interface." (italics mine) > > That is, given that you can figure out the MDI - which you can from the > object reference - and that you know the operation, you should be able to > walk back up the inheritance chain (using the IR (assuming it is > installed...)) & figure out which interface was called since it is illegal > to reuse a name in an inheritance tree. (It's obviously ugly to do it this > way, but I believe that what you want to do can, in fact, be done.) My recollection is that this procedure is exactly what we were assuming ORBs would do when we wrote the CORBAsecurity spec., based on advice from ORB vendors that both walking back up the inheritance chain and getting the MDI were possible. --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom Sender: jis@fpk.hp.com Date: Mon, 16 Aug 1999 16:39:28 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Bob Blakley CC: Polar Humenn , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Bob Blakley says: > Here's my first cut at the requirements; > requirements in () are not strictly relevant to this > discussion but are included for completeness. > Requirements with a "*" are derived from the non-*'d > requirements: > 1. It must be possible to control access to individual > methods of individual object instances. In particular, > it must be possible to apply different access control > policies to different instances of the same interface. 2. It must be possible to group instances into domains, > and to assign the same access policy to each member > of a domain. In particular, this must be possible > even if the members of the domain do not all implement > the same interface (or interfaces). 2a. (It must be possible at administration time to change > the domain membership of each object instance.) 2b. (It must be possible at administration time to change > the policy associated with each domain.) 3.* It must be possible at access decision time for the > security service to determine which object instance is > the target of an invocation which has been received by > the ORB instance which the security service protects. 4.* It must be possible at access decision time for the > security service to determine which domain an object > instance belongs to. 5.*It must be possible to associate a (set of) required > right(s) with each of an interface's methods. 5a. (It must be possible at administration time to set > and/or change the required right(s) assigned to each > method of an interface.) 6.*It must be possible at access decision time for the > security service to determine what rights are required > to invoke the method which the caller has asked to > invoke. 7.* It must be possible at access decision time for the > security service to determine which interface of an > invoked object instance is being used. 8.* It must be possible at access decision time for > the security service to determine which rights are > required to invoke a particular method of a particular > interface. An excellent list to use as the basis for this discussion. I took the liberty of assigning numbers to the requirements enumerated in the list. I would submit that 2, 2a and 2b fall within the purview of the Domain Management RFP. 1 and 4 depend on the availability of 2. As for 1, the ORB on which the target object is hosted does have the necessary info in it to make this possible, provided the Domain Management service is able to provide the binding into separate policy domains for separate object references. The information needed for providing 3 has got to be already available within an ORB on which the target object is hosted, in some way shape or form, because without it, the ORB could not route the invocation to the right object and the right method. In POA parlance the triplet uniquely identify an object instance of a specific type. The issue there is how is this to be made visible/accessible to the programmers of security service. How 5 and 5a and hence 6 are currently achieved is unclear to me. Any Security Service implementers with any view on this? Is there any specific support needed from the ORB/POA to effect this? If so, I'd like to understand what that is. The information that can be constructed and made available in the ORB on which the target object is hosted, relative to 7 is the RepId of the most derived interface supported by the target object. This interface contains *all* the operations that the target object claims to support. The specific invocation from the client may however have used a version of the reference through which all the operations were not visible to the client. As for 8, I need clarification about what you mean by a particular method of a particular interface. The interface using which an invocation is done contains an object key identifying the exact object on which the method is to be invoked. Do you in addition need to know which particular narrowed form of interface was used to do this particular invocation? My understanding is that that info may not always be available, and even if it was it wouldn't be particularly trustworthy absent a whole additional layer of mechanism to integrity protect it, and that too, only to the extent that you trust the ORB that hosts the client and everything else on the way from there to here. Of course, all my comments above are relative to the server end. At the client end it is a very different story. All that you have is an object reference that the ORB at the client end is able to extract only the following info, the host, the port, the object key, and in addition a type id, and any of the security profiles that it happens to understand, that's it. What is worse is that if the IOR has been transformed through a few Firewalls and such, then even those pieces of info may have very little to do with the corresponding info in the original IOR. So doing any client side access control is a different kettle of fish, and I'd suggest that we place that on the back burner for now until we get the critical server side all straightened out. In working out the solutions one thing that I would like to see us abide by is that we do not specify interfaces that force early binding of data thus removing all opportunities for late binding optimizations from the ORB implementors. That is my fervent plea. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 16 Aug 1999 16:46:38 -0400 From: John Marsh Organization: Concept Five Technologies X-Mailer: Mozilla 4.07 [en] (WinNT; U) To: Bob Blakley CC: Polar Humenn , Paul H Kyzivat , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object There is no requirement on the ORB today to actually keep this information around in the impl, the requirement is to keep the information around in the IR. (There is, unfortunately, no requirement that the IR actually always be turned on in the ORB spec, but if you insist that CORBAsec needs the information, you can simply require the IR be turned on on any CORBAsec compliant ORB.). If you assume the IR is around, based on the below, and the IR interfaces, you can figure it out the actual interface the operation was invoked on if you must have it. John Bob Blakley wrote: > > John >> >> I think the following quote from section 3.7.5 of the CORBA 2.3 spec on >> Interface Inheritance may fix your problem: >> >> "References to base interface elements must be unambiguous. A Reference to >> a base >> interface element is ambiguous if the name is declared as a constant, type, >> or exception >> in more than one base interface. Ambiguities can be resolved by qualifying >> a name >> with its interface name (that is, using a ). It is illegal to >> inherit from >> two interfaces with the same operation or attribute name, or to redefine an >> operation or >> attribute name in the derived interface." (italics mine) >> >> That is, given that you can figure out the MDI - which you can from the >> object reference - and that you know the operation, you should be able to >> walk back up the inheritance chain (using the IR (assuming it is >> installed...)) & figure out which interface was called since it is illegal >> to reuse a name in an inheritance tree. (It's obviously ugly to do it this >> way, but I believe that what you want to do can, in fact, be done.) > > My recollection is that this procedure is exactly what we were assuming ORBs > would do when we wrotethe CORBAsecurity spec., based on advice from ORB > vendors that both walking back upthe inheritance chain and getting the MDI > were possible. > --bob Bob Blakley (blakley@dascom.com) > Chief Scientist, Dascom Sender: jis@fpk.hp.com Date: Mon, 16 Aug 1999 17:18:36 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Bob Blakley CC: Polar Humenn , Paul H Kyzivat , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Bob Blakley wrote: > > All > > This whole thread touches one of my hot buttons, so > I'll apologize in advance > if my tone is less restrained than usual here. > > >> Bob Blakley wrote: > >> > > >> > I don't know if I ever posted it to the list, but my feeling about how > >> > to solve this > >> > problem was that we should simply move the RequiredRights interfaces > >> > to the POA and require implementors to provide this functionality. > >> > This "you broke it, you bought it" approach would have a couple of > >> > advantages: > >> > > >> > 1. It would make it clear to the POA designers and implementors > >> > exactly what the problems are > >> > 2. It would leave POA vendors free to compete on the basis of what > >> > granularity of policy protection could be provided in their > >> > environments and would thus refer the question of "the right > >> > mechanism" to the market. > >> > >> First, even though I wasn't part of the effort to design the POA > >> interface, I still object to the characterization of "you broke it". > >> The POA work was to fix a portability problem that was clearly broken. > >> In the process it at worst "broke" a security feature that never did > >> work and so was already broken. > > I didn't make any claims that POA didn't fix portability and other problems. > Clearly, it did. However, it's not possible in POA environments to do > something (discover the most-derived interface of an invoked implementation) > which we were told by ORB vendors (and was true apparently in some > implementations) WAS possible in previous CORBA environments. This discovery of MDI was possible only at the server end in pre-POA days, and it continues to be possible at the server end in post-POA days. The only bickering that has gone on in this regard is figuring out whether you can do this in all cases on the server side without involving the target object or the servant hosting the target object, and it is true that for certain combination of POA policies they have to be involved in order to determine what their most derived interfaces are. This feature of the POA exists not because it was just fun to do it, but because there were serious requirements from the database types, for example to provide this flexibility. Of course the addition of a less obscure API for extracting this info from the ORB/POA in a portable way would help a lot too. > The original CORBA specification was badly broken with respect to > security in that there was no portable way to determine on the server side > which object instance was the target of a particular method invocation, in > a way which allowed policy information to be retrieved based on which > object was being invoked. Correct, although one thing that's worth noting is that even then the necessary information was there in the GIOP message, and that information content in the GIOP message has not changed between then and now. It was just not available at an API. Think about it, without that info, the ORB couldn't dispatch any invocation to the correct instance.:-) > When I say broken, I mean something quite specific: the user community > explicitly and unequivocally stated that instance and method granularity > of access policy enforcement was a requirement. But without a way to > identify instances, figure out when they were being invoked on, > and associate policy with them, this was not possible. > > We worked around this as best we could, with a good deal of help > from vendors, several of whose representatives helped in the > preparation of the POA > specification. We believed at the time that the solutions we'd come up with > worked, and we got no arguments from the ORB vendors. There were certainly > in retrospect some problems, which we've been fixing steadily. > > The mechanism we designed had the feature that it was > possible to control the otherwise unmanageable scale of policy data by > associating "required rights" with methods to limit the number of permissions > which need to be managed. In order to manage required rights, it was > necessary > to figure out which interface an instance was being invoked through at the > time > a message was received by the target ORB/OA. On this point *again* we > consulted > the ORB vendors -- in fact again some of the same people who worked on the > POA spec. We were told we could always determine the most derived interface > of an invoked object, and we relied on this. I believe that this is still true (i.e determine the MDI), provided you allow the ORB to construct this information for you from info available to it. You run into specific problems when you demand that this information must be derived from a RepId carried in the invocation. BTW, even in the pre-POA days there was no guarantee that you could get the exact interface from the received GIOP message. > Subsequently we were told that in a POA environment it was no longer possible > to determine the most derived interface of an object which was being invoked. Again, at the server end, with a little cooperation from the target object/servant for certain POA policy combinations, this information can be constructed. On the client end it's a different story. > In my opinion this left us in the following situation: > > There's no such thing as an object instance - there are only references > and > implementations. But references aren't guaranteed always to refer to > the > same bunch of data, especially over time, so they can't be used to > identify "objects". And there's no way to refer to implementations > except > inside an implementation. > > Furthermore, while objects do support various interfaces, there's no way > to > determine exactly *which* interface an object is being invoked through > when a particular message is received. > > This is a bad situation from a security point of view. Basically it means > that > you can't tell *either* which object is being called *or* which method is > being > invoked. And yet we're supposed to provide object-and-method-granularity > protection. I don't believe the situation is this bad. I believe all that is missing is a well designed interface to make some of this info available to the right folks at the right time. I am trying to facilitate the creation and standardization of these necessary itnerfaces. > >I must agree with Paul on this point. The POA didn't break anything, in > >fact it fixed alot of things. The security specification was flawed from > >the outset, and still is. (Excuse me for my tone, as I've already have > >been yelled at by some people for not being politically senstive in my > >comments, but you can pass that off as me being an academic :) > > I've already disagreed with this; while there are things wrong with > the CORBAsecurity specification, if it's broken in this particular respect > it's through no fault of CORBAsecurity -- but rather arises from fundamental > flaws in the underlying ORB and OA specs. If it's not possible to determine > which > interface is being invoked, then this is broken. The CORBAsecurity > specification, which predates the POA specification, requires implementation > of the RequiredRights interface, which assumes that it's possible to > determine *at least* the most-derived interface of an object to which a > message has been addressed. We were led to believe that this was > possible in pre-POA implementations. If this wasn't true, then previous > implementations (and the specs. on which they were based) were broken, > and if it still isn't true, then POA-based implementations are still broken. Now you have hit my hot button so with some regeret I ascend my soapbox:-): Well, the fact that nobody ever really built the previous non-POA based implementation that was remotely similar to what was specified, notwithstanding some protestations to the contrary, did not help matters any. I remember pleading with Security vendors of those days to please run the danged IDL through their compiler, much less to actually verify that it was implementable, and was much less than successful in that. Then when the spec came out for the first time, an upstanding representative of one of those upstanding vendors who had failed to run the IDL through their excellent IDL compiler raked me over red hot coal publicly bacause the IDL was broken. Anyway, that is much water over the dam. Jishnu descends from his soapbox.:-) > >> There wasn't enough defined on the server side before to show if/how the > >> MDI could be determined for an object reference, or even how an object > >> reference could be obtained for an incoming reference. The fact that the > >> POA work failed to fix this doesn't mean that it broke anything. > > > >Again, I cannot agree more. > > > >> Next, I don't know what you mean by "move the RequiredRights interfaces > >> to the POA". The POA is little more than a container for servants. All > >> it knows about servants is defined by the servant itself. It can know > >> the MDI of a servant to the extent that primary_interface() makes it > >> available. So there seems little point in asking the POA, which has no > >> relevant capabilities, to provide the RequiredRights interfaces. > > > >Yes, I don't understand that either. I went away on the weekend, so I > >didn't get a chance to ask Bob about this. However, even with the POA, it > >is the Servant that must be activated to find out what the MDI is! The > >POA, as a component, really doesn't enter into the question. > > > >> It sounds like you are suggesting that some vendor proprietary means be > >> used. The likely outcome of that will just be to break portability once > >> again. That is not an acceptable solution. > >> > >> In a POA based environment I see little alternative to using > >> primary_interface() to get an MDI to then use to get the required rights > >> for a request. The mechanics can be adjusted in various ways to meet Bob > >> K's concerns. Passing the MDI to the security service rather than having > >> it deal with the servant directly is one way. > > > >It looks more and more like the above should be the case. > > All of these discussions bother me because they all take place at the level > of implementation rather than abstraction. Basically we seem to me to be > discussing various hacks based on existing implementations, and considering > functional limitations based on the deficiencies of those implementations, > rather than focusing on the abstract model we should be supporting and > the customer requirements for functionality. As long as none of thse requirements try to violate basic things like E=mc**2, or fundamental limitations imposed by theory of computability, we should try to see what can be done.:-) > >If the Security Service basically stated emphatically (or just suggested) > >that "security" bases itself on CORBA "interface" and "operation", then > >the object reference shouldn't even enter into it. I'm leaning more to an > >AccessDecision object that the interface for "access_allowed" only gets > >those points of interest, such as DomainManagers, primary interface name, > >operation name, and of course the complimenting component, the credentials > >object of the client. Arrrrghhhhhh! > This simply isn't acceptable. The CORBAsecurity designers > were responding to a very explicit and strongly stated requirement for > INSTANCE-granularity protection. It's ludicrous on the face of it to suggest > that this requirement isn't valid and shouldn't be supported. If you revert > to interface-and-operation granularity, then you have only two choices, both > completely impractical in real deployments: > > (1) All instances of an interface have exactly the same policy. > Imagine applying this constraint to filesystems, databases, or > application servers. It clearly doesn't work. > > (2) To give instances of an interface different policies, you have to > put them on different servers, or in different OAs. Furthermore, > you have to be aware of which server an object lives in in order > to manage its policy. > > I believe that if you want to make a modification to the CORBAsecurity > service which degrades the functionality of the service to this extent, you > need to issue a new RFP and define a new service which provides only > the limited functionality described here. I sure hope that no one is suggesting that we give up on security based on object instance and revert back to object type based security. That would be less than useful approach. The little toy security service that I built just to entertain myself on a BOA based system once upon a time could pretty well do instance based access control. I don't see any reason why a POA based system would not be able to do that. I think the real issue is whether it can do that in a portable way, i.e., is the right info available at APIs at the right places or not. Also the API has to be at the right level of abstraction so as to not prematurely preclude the possibility of doing late binding optimizations. For example, if the RepId needs to be cosntructed, the ORB should not be forced to construct it a-priori due to bad design of the API. It should be allowed to postpone the construction ot the point a twhich it is actually required, and it should not be precluded from caching thus constructed APIs to enhance performance using favorable access patterns to the extent possible. > If you don't want to fix the problems with POA (and, evidently, with some > other OAs), then you need to withdraw the current CORBAsecurity > specification and notify the user community that instance-granularity > access control will not in the future be available. Sigh, the only thing that needs fixing is the portability aspect of it, IMHO. > >> In the end we must just make sure that the security service isn't asking > >> to be provided with information that is unobtainable. > > Sorry, I disagree again. We must just make sure that the security service > is meeting the stated requirements of the OMG customer community. > If meeting those requirements means making some more information > available from ORB implementations, then we should make that > information available, or we should advertise that the implementations > which don't provide it are not securable on the terms the customers > are interested in. > > Personally, I don't think it's unreasonable to ask ORB implementations > to be able to tell which object instance is being invoked, and which > interface that instance is being invoked through. I agree with you as long as by "which interface" you mean the MDI of the target object. Any other interface that can be used to invoke an operation of the target object is merely a restriction of the MDI. Of course once you have the MDI, given the name of an operation you can always use the "tedious enumeration and string matching" algorithm to discover which actual interface it came from, provided the IR is available to you. Cheers, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: Jeffrey Mischkinsky Subject: Re: AccessDecision object To: jmarsh@concept5.com (John Marsh) Date: Mon, 16 Aug 1999 14:50:38 -0700 (PDT) Cc: blakley@dascom.com, polar@adiron.com, paulk@roguewave.com, sec-rev@omg.org, zpope@dascom.com X-Mailer: ELM [version 2.4 PL25] 'John Marsh' writes: > > There is no requirement on the ORB today to actually keep this > information around in the impl, the requirement is to keep the > information around in the IR. (There is, unfortunately, no requirement > that the IR actually always be turned on in the ORB spec, but if you > insist that CORBAsec needs the information, you can simply require the > IR be turned on on any CORBAsec compliant ORB.). I don't recall reading in the specs that get_interface() is an optional operation. (Regardless of whether all products actually implement it, or require that someone do something special, such as "starting up" the IR.) jeff > If you assume the IR is around, based on the below, and the IR > interfaces, you can figure it out the actual interface the operation was > invoked on if you must have it. > > John > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Mon, 16 Aug 1999 18:36:33 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Bob Blakley CC: Polar Humenn , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object I have read thru several messages on this subject. For my own convenience I am going to reply to them one at a time, but my comments may imply knowledge from later messages. I have heavily abstracted down to just the points I intend to reply to. Paul Bob Blakley wrote: > > All > > This whole thread touches one of my hot buttons, so I'll apologize in > advance if my tone is less restrained than usual here. No problem. I think I understand your point of view. Mostly I don't fundamentally disagree with you, though our priorities are probably different. > I didn't make any claims that POA didn't fix portability and other > problems. Clearly, it did. However, it's not possible in POA > environments to do something (discover the most-derived interface > of an invoked implementation) which we were told by ORB vendors > (and was true apparently in some implementations) WAS possible > in previous CORBA environments. This is possible for DSI servants. There is no formal way to request it of skeleton based servants, but the code generator that creates the skeleton has access to this information, so in principle it should be easy to make it available. Our orb makes this available from skeleton based servants. Jishnu offered to have orb-revision address needs of the sec-rev if they are clearly identified and justified. I think this is one that can easily be addressed, hopefully with little pain to vendors. (My thought is to make primary_interace be available on all servants, rather than just on DSI servants.) > > The original CORBA specification was badly broken with respect to > security in that there was no portable way to determine on the server > side which object instance was the target of a particular method > invocation, in a way which allowed policy information to be > retrieved based on which object was being invoked. > > When I say broken, I mean something quite specific: the user community > explicitly and unequivocally stated that instance and method > granularity of access policy enforcement was a requirement. But > without a way to identify instances, figure out when they were > being invoked on, and associate policy with them, this was not > possible. This user community (like all user communities) wants everything. They are perfectly happy in asking for mutually exclusive things. Somebody has to point out when this happens. Maybe it happened in this case and nobody noticed, or maybe it didn't happen. The problem with instance level granularity is that it is tightly coupled with object identity. The OMA fails to deal with object identity, because it is practially speaking an unsolvable problem in distributed systems. The OMA doesn't preclude individual implementations from defining object identity among the objects they implement, but it has to be done at that level. When applied to the security service, I think this means that the implementation must be involved in authorization process in some way. I don't know for sure, but I have the impression that this is considered a no-no. Something has to give here. > The mechanism we designed had the feature that it was > possible to control the otherwise unmanageable scale of policy data by > associating "required rights" with methods to limit the number of > permissions which need to be managed. I think this was an excellent invention. > In order to manage required > rights, it was necessary to figure out which interface an instance > was being invoked through at the time a message was received by the > target ORB/OA. On this point *again* we consulted > the ORB vendors -- in fact again some of the same people who worked > on the POA spec. We were told we could always determine the most > derived interface of an invoked object, and we relied on this. > > Subsequently we were told that in a POA environment it was no longer > possible to determine the most derived interface of an object which > was being invoked. The inability to get the MDI *from a servant* is, as I mentioned above, easily fixable. (It may not even need fixing formally. If the security interceptor is responsible for providing the MDI, then it is the vendor's job to figure out how.) The problem that has existed for quite some time has been the perception that it must be possible to get the MDI from an *object reference*, together with the assumption that an object reference is even available for the target on the server side. I sense that we are close to a common understanding that this is neither possible nor necessary. > > In my opinion this left us in the following situation: > > There's no such thing as an object instance - there are only > references and implementations. But references aren't guaranteed > always to refer to the same bunch of data, especially over time, > so they can't be used to identify "objects". And there's no way > to refer to implementations except inside an implementation. The above in my mind is a correct statement. And while at times inconvenient, it is a fact of life in distributed systems. I think the closest you are going to come to a way to reference an implementation without going into it is Jishnu's suggestion to use [POA_Id, Object_Id] as a handle for an implementation. But I am inclined to think that this has some difficulties: - This really has to be [Server_Id, POA_Id, Object_Id]. And then there is a problem assigning ids to servers. They may be reached via multiple profiles, and within profiles there may be multiple representations for the same endpoint. There is *nothing* in the current POA spec that causes a server to state a unique identity for itself or for any implementation that it contains. - Even if server identity was solved, managing access control to objects via [Server_Id, POA_Id, Object_Id] independently from the management of the implementation instances themselves will be impractical (and I think often undesireable) much of the time. Servers use their own, often complex, algorithms for representing objects via Object_Ids. Often this will involve persistent DBs keyed in some way from the Object_Id. Keeping a separate mapping of security info keyed by Object_Id will be essentially impossible to synchronize if it isn't done by the same developer(s). What I think would be practical, would be to find a way to allow the implementation developer to provide a mapping from incoming request keys [POA_Id, Object_Id] to an object domain identifier of some sort. Then, let the security service to the rest of the authorization decision. This forces the implementor to manage domain membership, but nothing more. > > Furthermore, while objects do support various interfaces, there's > no way to determine exactly *which* interface an object is being > invoked through when a particular message is received. Somebody else posted the solution to this. If you know the MDI and you know the operation name then you know what interface the operation came from. However required rights are associated with interfaces (I wish I knew this), it should only be possible to assign required rights for an operation within the interface where it is explicitly declared, and these should be inherited along with the operation itself. > > This is a bad situation from a security point of view. Basically it > means that you can't tell *either* which object is being called *or* > which method is being invoked. And yet we're supposed to provide > object-and-method-granularity protection. Based on comments above, you should be able (on the server side) to decide what domain a target object resides in, and the interface within which a particular operation is declared. On the client side you are in much more trouble. At best you can determine the interface carried in the object reference, and from that you can often determine the interface in which a particular target operation is defined. (In static stub invocations the code generator at least knows what was intended at compile time, which is the answer you want anyway. But with DII it is possible to invoke an arbitrary operation even though the target IOR carries no repository_id for the target.) And you can tell almost nothing about the domain the object belongs to on the client side. If you are to do anything here then I agree with a suggestion Polar made - that this decision should be about trust of the server by the client. This would only have to do with the target address and possibly required rights. (But I have the feeling required rights are intended for the protection of the server, not the client.) > This simply isn't acceptable. The CORBAsecurity designers > were responding to a very explicit and strongly stated requirement for > INSTANCE-granularity protection. It's ludicrous on the face of it to > suggest that this requirement isn't valid and shouldn't be supported. > If you revert to interface-and-operation granularity, then you have > only two choices, both completely impractical in real deployments: > > (1) All instances of an interface have exactly the same policy. > Imagine applying this constraint to filesystems, databases, or > application servers. It clearly doesn't work. > > (2) To give instances of an interface different policies, you have to > put them on different servers, or in different OAs. > Furthermore, you have to be aware of which server an object > lives in in order to manage its policy. I agree with you here. I presume whenever you talk about instance level granularity you really mean domain level, together with the option of controlling (somehow) what objects go in a domain. My simple way of testing adequacy is: Corba security must be sufficient so that I can implement something like a unix file system, with the same degrees of freedom those provide over access control. > I believe that if you want to make a modification to the CORBAsecurity > service which degrades the functionality of the service to this > extent, you need to issue a new RFP and define a new service which > provides only the limited functionality described here. > > If you don't want to fix the problems with POA (and, evidently, with > some other OAs), then you need to withdraw the current CORBAsecurity > specification and notify the user community that instance-granularity > access control will not in the future be available. Who do you mean by "you"? I think Polar is speaking for the sec-rev. It has no authority to fix anything in the POA. For that, you need to ask for the help of orb-revision. If there used to be some feature in the core spec that the security service depended on, and that feature was removed or changed in a way that broke the security service, then you should submit an issue against the orb-revision RTF. If that was not the case, but the security spec is still broken due to lacking functionality in the core, you might be able to handle it via an issue to orb-revision, or you might need to use an RFP process to deal with it. Either way, until a suitable change is made to the core, you are either going to have to change the security stuff to work around the problem (possibly with limitations), or else you are just going to leave your outstanding issue open as a known bug. > >> In the end we must just make sure that the security service isn't > >> asking to be provided with information that is unobtainable. > > Sorry, I disagree again. We must just make sure that the security > service is meeting the stated requirements of the OMG customer > community. If meeting those requirements means making some more > information available from ORB implementations, then we should make > that information available, or we should advertise that the > implementations which don't provide it are not securable on the > terms the customers are interested in. > > Personally, I don't think it's unreasonable to ask ORB implementations > to be able to tell which object instance is being invoked, and which > interface that instance is being invoked through. I already covered this above. Just because somebody wants something doesn't mean they can have it. And even if it is theoretically possible to give them what they ask, they may not want it once they know what it is going to cost. Implementing object identity - especially of a sort that clients can discern - would impose massive usability and performance issues globally across all corba implementations. In addition, it would invalidate all existing implementations. I doubt most users are willing to pay this. At best you might be able to get it accepted as a new conformance level. But I think you had best think of some other way to meet security needs. Date: Mon, 16 Aug 1999 18:38:41 -0400 From: John Marsh Organization: Concept Five Technologies X-Mailer: Mozilla 4.07 [en] (WinNT; U) To: Jeffrey Mischkinsky CC: blakley@dascom.com, polar@adiron.com, paulk@roguewave.com, sec-rev@omg.org, zpope@dascom.com Subject: Re: AccessDecision object Jeff - I reread that portion of the spec after your response - thanks, you're correct the IR doesn't appear to be optional. Unfortunately some vendors a) don't require that the IR be turned on & even default it to being off when you install their products. (That is, default to being non-compliant...) In addition on this topic: The IR & the get_interface() call are explicitly dropped for minimumCORBA so there are issues for CORBAsec access to any of this information in lighterweight implementations (if anyone cares). John Jeffrey Mischkinsky wrote: > 'John Marsh' writes: > > > > There is no requirement on the ORB today to actually keep this > > information around in the impl, the requirement is to keep the > > information around in the IR. (There is, unfortunately, no requirement > > that the IR actually always be turned on in the ORB spec, but if you > > insist that CORBAsec needs the information, you can simply require the > > IR be turned on on any CORBAsec compliant ORB.). > > I don't recall reading in the specs that get_interface() is an optional > operation. (Regardless of whether all products actually implement it, > or require that someone do something special, such as "starting up" the > IR.) > > jeff > > > If you assume the IR is around, based on the below, and the IR > > interfaces, you can figure it out the actual interface the operation was > > invoked on if you must have it. > > > > John > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 From: "Shutters, Chris" To: sec-rev@omg.org Subject: RE: AccessDecision object Date: Mon, 16 Aug 1999 16:50:35 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Bob Blakley wrote: > 1) The OMG has a process. It involves issuing an RFP which states > requirements, gathering responses, voting on those responses, > adopting a chosen response, and then maintaining it. [snip] > They're documented in the OMG security whitepaper and the > security service > RFP. Since I wasn't around when the original white paper and RFP were issued, and I was curious about what was actually requested, I went hunting and found them. I am posting the links here in case someone else is interested. Security Service RFP (aka Object Services RFP 3): http://www.omg.org/docs/1994/94-07-01.pdf Security White Paper: http://www.omg.org/docs/1994/94-04-16.pdf NOTE: As far as I can tell, these are the correct documents. If, however, someone has more accurate information (later versions, etc), please let us all know :-). Cheers, Chris Shutters DMW Worldwide cshutters@dmwworldwide.com chris_shutters@omg.org X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 16 Aug 1999 19:07:18 -0400 (EDT) From: Polar Humenn To: John Marsh cc: Jeffrey Mischkinsky , blakley@dascom.com, paulk@roguewave.com, sec-rev@omg.org, zpope@dascom.com Subject: Re: AccessDecision object John Marsh wrote: > Unfortunately some vendors a) don't require that the IR be turned on & even > default it to being off when you install their products. It is not an implemenation requirement that an special IR service be "turned-on". Although this is what some vendors have. In the case that an IR is not "turned-on" the implemenation should raise an INTF_REPOS exception, which I believe is compliant. Take in most cases, say in the static case, where the skeleton code is acutally generated by an IDL to code generator. Although I don't know of a vendor that does this, the code generator completely generate objects that describe the object's interface and put them behind the "get_interface" call. So there is no specific fully functioned IR involved (i.e. with "lookup_id", "create....", etc.). This can bring up interesting points involving security. The most favored implementation of get_interface is just for the application to forward the call to the Repository::lookup_id() call and return that object reference. If the IR is in a different server with a different principal name, what kind of trust do you lay in that? Has anybody got any examples of the trust models on this stuff? If you go with the code generated IR, you can 1. save on secure association set up, because, you always deal with the same server, and can possibly use the same connection and secure association. Plus, you can make a simpler argument for trusting the same principal for the interface definition. What if the principal of the interface defintion is different than the object itself? What kind of policies have people worked out on this? What if you lay automatic access control on the IR itself, and if you must query "get_interface" before you can access "get_interface"? Later, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 16 Aug 1999 19:20:45 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Bob Blakley CC: Polar Humenn , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Bob Blakley wrote: > > >> I know, all this sounds very heretical, but I > >> would really like to understand what the architectural and > >> information flow model that we are looking for is before jumping > >> into solution proposals. > > I think this is the right approach. Here's my first cut at the > requirements; requirements in () are not strictly relevant to this > discussion but are included for completeness. Requirements with > a "*" are derived from the non-*'d requirements: > > It must be possible to control access to individual methods of > individual object instances. In particular, it must be possible > to apply different access control policies to different instances > of the same interface. I agree. > > It must be possible to group instances into domains, and to assign the > same access policy to each member of a domain. In particular, this > must be possible even if the members of the domain do not all > implement the same interface (or interfaces). I agree. > > (It must be possible at administration time to change the domain > membership of each object instance.) As I stated in an earlier message, I think only the object implementation is in a position to manage domain membership. This implies (to me) that ability to administer this membership is at least going to require the cooperation of the implementation. Exactly how this might work needs a lot of work. It also implies that the ability to change membership administratively will most certainly vary from object to object or server to server. > > (It must be possible at administration time to change the policy > associated with each domain.) This seems more practical. I can at least imagine managing the existence of domains separately from the implementations that inhabit them. I say this because probably most servers won't have a lot of need to create lots of new domains. Even so, for those that need to create/destroy domains, this is going to be a difficult requirement to meet. It means that either they must implement the administrative interface and persist domain/policy information themselves, or else they must employ a separate (remote) service to do this *and* handshake with it whenever updates are required. I would like to see some scenarios of how this can be done. (I would especially like to see how it might work with the Corba FileSystem benchmark.) > > * It must be possible at access decision time for the security service > to determine which object instance is the target of an invocation > which has been received by the ORB instance which the security > service protects. I disagree. Since control is really at the domain rather than instance level it should be sufficient for the security service to obtain the domain membership information. > > * It must be possible at access decision time for the security service > to determine which domain an object instance belongs to. I disagree, though perhaps only with the language rather than the intent. I agree it must be possible to get domain membership information for the instance as understood by the implementation. > > *It must be possible to associate a (set of) required right(s) with > each of an interface's methods. Yes. But I wish someone could explain to me the scope of definition, and how it gets defined, stored, and accessed. Somehow this should transcend both ORBs and Security Service implementations. My impression is that logically it is analogous to (in 1:1 correspondence to) interface repository information. But as long as it isn't part of the interface repository, and as long as there is no standard way of defining it, this isn't going to work. In a world where there are multiple clients, servers, and orbs all interoperating, there are typically going to be multiple interface repositories: - If I, as a client, call resolve_initial_reference ("InterfaceRepository") I will probably get one specified as part of the administration of the orb I am using on the node I am using. - If I call get_interface on an object reference, I will probably get one specified as part of the administration of the orb used by the server of that object on the node that server runs on. In general this won't matter, because hopefully they will have been populated with identical IDL, at least for the interfaces that both of us care about. How do we reach a similar state of affairs w/r/t required rights? > > *It must be possible at access decision time for the security service > to determine what rights are required to invoke the method which the > caller has asked to invoke. Partially agree. As noted elsewhere, the ability to make this decision on the client side is extremely limited and of questionable value given the limitations. > > (It must be possible at administration time to set and/or change the > required right(s) assigned to each method of an interface.) I'm not sure about this one. Partially this depends on my getting some explanation of how the required rights database could / is expected to work. But also, I see great parallels here between static skeleton approaches and DSI approaches to server implementation. Static skeletons compile interface information into the server. They make it a easier and more efficient to implement a server, with some tradeoffs regarding runtime configuration. I expect that in many cases it will be desireable to similarly "compile-in" the required-rights information, rather than having to depend on (and wait for) something like the InterfaceRepository (RequiredRightsRepository?). In this case it might not be possible to make a change to the required rights mapping without recompiling the affected servers. I think it is unacceptable to prohibit this sort of optimization. > > * It must be possible at access decision time for the security > service to determine which interface of an invoked object instance is > being used. I have covered this elsewhere. > > * It must be possible at access decision time for the security service > to determine which rights are required to invoke a particular method > of a particular interface. Agree, with limitations noted above. Date: Mon, 16 Aug 1999 19:33:36 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Bob Blakley CC: Polar Humenn , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Bob Blakley wrote: > > There are NO "wild abstractions" in CORBAsecurity. Every abstraction > (with the possible exception of the NR service, which we're not > discussing here) is based on models and implementations which have > been around since the time of MULTICS. Can anybody else here claim to have done development on MULTICS? (I had my very own MULTICS system in 1974.) > I'm not proposing we do this!! I'm just saying that OMG's process > doesn't let us revolutionise (especially by deletion) the > functionality of an adopted spec. in an RTF. Technically you may be correct, but practically speaking anything that can't be implemented can be deleted. This would be moreso in a FTF, which unfortunately was not in place when the security service was released. I suspect that there is still much of the security service that has never been implemented (couldn't be), and that with an FTF process would eventually have had to be withdrawn from the spec. X-Sender: soley@emerald.omg.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 16 Aug 1999 21:31:02 -0400 To: Paul H Kyzivat From: Richard Mark Soley Subject: Re: AccessDecision object Cc: Bob Blakley , Polar Humenn , sec-rev@omg.org, William Pope At 07:33 PM 8/16/99 -0400, Paul H Kyzivat wrote: >Can anybody else here claim to have done development on MULTICS? Yup. -- Soley.ARCS, Soley.Multics (I see your phcs_ and raise you one hphcs_) [& I suspect there are a few others on this list -- see http://www.multicians.org/multicians.html] X-Sender: soley@emerald.omg.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 16 Aug 1999 21:37:36 -0400 To: Paul H Kyzivat From: Richard Mark Soley Subject: Re: AccessDecision object Cc: Bob Blakley , Polar Humenn , sec-rev@omg.org, andrew@omg.org, William Pope At 07:33 PM 8/16/99 -0400, Paul H Kyzivat wrote: >> I'm not proposing we do this!! I'm just saying that OMG's process >> doesn't let us revolutionise (especially by deletion) the >> functionality of an adopted spec. in an RTF. > >Technically you may be correct, but practically speaking anything that >can't be implemented can be deleted. > >This would be moreso in a FTF, which unfortunately was not in place when >the security service was released. I suspect that there is still much of >the security service that has never been implemented (couldn't be), and >that with an FTF process would eventually have had to be withdrawn from >the spec. Now on this more important bit.... This is an important point, folks. As far as the rules go, RTF's (and FTF's, which aren't that different) cannot make major changes to the specification. What is a major change? According to the rules, whatever the Technical Director *says* is a major change. Certainly, a large change in semantics (say, for example, the sudden introduction of a strong notion of object identity :-) is out of the question for an RTF or FTF, regardless of whether - it's a good or bad idea - it's an addition or deletion - the original spec was implementable. That's the job of a new RFP, which allows "new blood" into the process more readily than RTF/FTF's (which are for completion, bug correction, and clarification, and whose *membership is closed* for the life of the RTF or FTF). If a major change in semantics is countenanced, *especially* because there might be a big hole in the current spec, that's a reason for a new RFP process to include that issue. -- Richard Date: Mon, 16 Aug 1999 19:04:33 PDT Sender: Bill Janssen From: Bill Janssen To: Paul H Kyzivat , Richard Mark Soley Subject: Re: AccessDecision object CC: Bob Blakley , Polar Humenn , sec-rev@omg.org, andrew@omg.org, William Pope Excerpts from local.omg: 16-Aug-99 Re: AccessDecision object Richard Mark Soley@omg.o (1659*) > Certainly, a large change in semantics (say, for example, the sudden > introduction of a strong notion of object identity :-) is out of the > question for an RTF or FTF Damn! Bill X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 17 Aug 1999 08:54:25 -0400 (EDT) From: Polar Humenn To: Paul H Kyzivat cc: Bob Blakley , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Mon, 16 Aug 1999, Paul H Kyzivat wrote: > Bob Blakley wrote: > > > * It must be possible at access decision time for the security service > > to determine which object instance is the target of an invocation > > which has been received by the ORB instance which the security > > service protects. > > I disagree. Since control is really at the domain rather than instance > level it should be sufficient for the security service to obtain the > domain membership information. I'll agree with Paul on this. However, having the Security Service determine the domain membership information can be problematic. It would probably be better off letting the ORB determine the domain membership information (since it is in the CORE) and give it to the Security Service. There is a subtle difference. The call to "get_domain_managers()" requires an object reference. This is a problem on the server side, since you don't have one. It is a problem on the client side, since it may cause an interception and a remote call. Every ORB may handle this activating the implemenation or service a bit differently to get this information, such as activating a servant. It has been noted that if the Security Service is given a servant pointer in a system interceptor, this might cause threading maintainance and integrity problems if the inteceptor is allowed to start invoking on the servant. > > * It must be possible at access decision time for the security service > > to determine which domain an object instance belongs to. > > I disagree, though perhaps only with the language rather than the > intent. I agree it must be possible to get domain membership information > for the instance as understood by the implementation. Well, I believe what you are saying is that the POA will not be coerced into managing domain membership information for its servants. Correct? ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 17 Aug 1999 09:05:13 -0400 (EDT) From: Polar Humenn To: Paul H Kyzivat cc: Bob Blakley , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Mon, 16 Aug 1999, Paul H Kyzivat wrote: > Bob Blakely wrote: > > > *It must be possible to associate a (set of) required right(s) with > > each of an interface's methods. > > Yes. But I wish someone could explain to me the scope of definition, and > how it gets defined, stored, and accessed. Somehow this should transcend > both ORBs and Security Service implementations. My impression is that > logically it is analogous to (in 1:1 correspondence to) interface > repository information. > > But as long as it isn't part of the interface repository, and as long as > there is no standard way of defining it, this isn't going to work. Agreed. > In a world where there are multiple clients, servers, and orbs all > interoperating, there are typically going to be multiple interface > repositories: > > - If I, as a client, call > resolve_initial_reference ("InterfaceRepository") I will probably get > one specified as part of the administration of the orb I am using on the > node I am using. > > - If I call get_interface on an object reference, I will probably get > one specified as part of the administration of the orb used by the > server of that object on the node that server runs on. > > In general this won't matter, because hopefully they will have been > populated with identical IDL, at least for the interfaces that both of > us care about. In general this won't matter. But in reality, for (non-standard) interfaces, (hell, even for standard ones!), the only definitive source for an object's interface is "get_interface" using the object's IR. > How do we reach a similar state of affairs w/r/t required rights? Well, that is easy, install a "get_required_rights" operation on the object reference. Then the same scenario as the IR can ensue. However, this makes the object "security aware" which in some circles, people think this is a bad idea. (why, I don't know, but there seems to be a push to keep an object interface security unaware, but then I say what did "get_domain_managers" do??). So, given that, would this kind of thing would require the RequiredRights Repository to be a service separate from the Security Service, i.e. by using "resovle_initial_references"? I'm not proposing moving RR to that status. It's just hypothetical question. (I don't like RequiredRights the way it is now anyway). Cheers, -Polar --------------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Shutters, Chris" , Subject: Re: AccessDecision object Date: Tue, 17 Aug 1999 10:34:20 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 All, These are the right references. >Security Service RFP (aka Object Services RFP 3): > http://www.omg.org/docs/1994/94-07-01.pdf This document refers to the following document for guidance, though in terms less prescriptive than I'd remembered. >Security White Paper: > http://www.omg.org/docs/1994/94-04-16.pdf Section 3.2.2 calls out the requirement for instance granularity of ACL-based access control. >Cheers, > >Chris Shutters Thanks very much for digging up these references, Chris! --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Polar Humenn" , "Paul H Kyzivat" Cc: "Jishnu Mukerji" , , "William Pope" Subject: Re: AccessDecision object Date: Tue, 17 Aug 1999 10:42:10 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 >> > * It must be possible at access decision time for the security service >> > to determine which object instance is the target of an invocation >> > which has been received by the ORB instance which the security >> > service protects. >> >> I disagree. Since control is really at the domain rather than instance >> level it should be sufficient for the security service to obtain the >> domain membership information. > >I'll agree with Paul on this. However, having the Security Service >determine the domain membership information can be problematic. It would >probably be better off letting the ORB determine the domain membership >information (since it is in the CORE) and give it to the Security Service. I agree with both of you here; the best solution is for the ORB (which knows about objects) do the mapping from whatever it gets in the message to the appropriate domain manager. My original statement was wrong. >There is a subtle difference. The call to "get_domain_managers()" requires >an object reference. This is a problem on the server side, since you don't >have one. It is a problem on the client side, since it may cause an >interception and a remote call. Every ORB may handle this activating the >implemenation or service a bit differently to get this information, such >as activating a servant. Yes; this was one of the problems we struggled with constantly. I agree again. >It has been noted that if the Security Service is given a servant pointer >in a system interceptor, this might cause threading maintainance and >integrity problems if the inteceptor is allowed to start invoking on the >servant. Again, no argument. >> > * It must be possible at access decision time for the security service >> > to determine which domain an object instance belongs to. >> >> I disagree, though perhaps only with the language rather than the >> intent. I agree it must be possible to get domain membership information >> for the instance as understood by the implementation. Hmmm... at this point the language has taken over & I'm not sure what I'm agreeing or disagreeing with. The security service needs to know which domain's policy it needs to use to make the access decision, AND it needs to know what interface's required rights it needs to use. The only thing which is definitely associated with BOTH the domain manager AND the interface is the object itself. However this doesn't mean that passing the object reference is the only way to make things work out right. >Well, I believe what you are saying is that the POA will not be coerced >into managing domain membership information for its servants. Correct? ??? Who's this question being asked of? Me? If so, I don't care whether we coerce POAs :-) --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom Date: Tue, 17 Aug 1999 11:48:45 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Polar Humenn CC: Bob Blakley , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > On Mon, 16 Aug 1999, Paul H Kyzivat wrote: > > > > I disagree. Since control is really at the domain rather than > > instance level it should be sufficient for the security service to > > obtain the domain membership information. > > I'll agree with Paul on this. However, having the Security Service > determine the domain membership information can be problematic. It > would probably be better off letting the ORB determine the domain > membership information (since it is in the CORE) and give it to the > Security Service. > > There is a subtle difference. The call to "get_domain_managers()" > requires an object reference. This is a problem on the server side, > since you don't have one. It is a problem on the client side, since > it may cause an interception and a remote call. Every ORB may handle > this activating the implemenation or service a bit differently to > get this information, such as activating a servant. > > It has been noted that if the Security Service is given a servant > pointer in a system interceptor, this might cause threading > maintainance and integrity problems if the inteceptor is allowed > to start invoking on the servant. [snip] > > I agree it must be possible to get domain membership > > information for the instance as understood by the implementation. > > Well, I believe what you are saying is that the POA will not be > coerced into managing domain membership information for its > servants. Correct? I have no problem with the ORB being the intermediary between the security service and the implementation (servant) regarding domain membership. But it can be no more than that - ultimately the implementation must be responsible for maintaining the mapping between invocation targets and domains. In simple cases this could be simply a single domain for all objects in the same server, so the mapping could be very easy to manage. Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Polar Humenn" , "Paul H Kyzivat" Cc: "Jishnu Mukerji" , , "William Pope" Subject: Re: AccessDecision object Date: Tue, 17 Aug 1999 10:49:14 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 >> Bob Blakely wrote: >> >> > *It must be possible to associate a (set of) required right(s) with >> > each of an interface's methods. >> >> Yes. But I wish someone could explain to me the scope of definition, and >> how it gets defined, stored, and accessed. Somehow this should transcend >> both ORBs and Security Service implementations. My impression is that >> logically it is analogous to (in 1:1 correspondence to) interface >> repository information. >> >> But as long as it isn't part of the interface repository, and as long as >> there is no standard way of defining it, this isn't going to work. > >Agreed. Yes, almost by definition. The requiredRights object is supposed to be the standard way of defining it. If you have, on the server side, a way to determine which interface is being invoked, then you can retrieve the requiredRights object, pass in the interface and method, and get back the required rights. This *could* be made independent of both ORBs and security service implementations, if ORBs all made the interface information available. It would also be possible to store the information directly in the IR, but we were told at the time the spec. was written that it would be bad form to require that this be done (as it would be an unacceptable imposition on implementors' freedom). >> In a world where there are multiple clients, servers, and orbs all >> interoperating, there are typically going to be multiple interface >> repositories: >> >> - If I, as a client, call >> resolve_initial_reference ("InterfaceRepository") I will probably get >> one specified as part of the administration of the orb I am using on the >> node I am using. >> >> - If I call get_interface on an object reference, I will probably get >> one specified as part of the administration of the orb used by the >> server of that object on the node that server runs on. >> >> In general this won't matter, because hopefully they will have been >> populated with identical IDL, at least for the interfaces that both of >> us care about. > >In general this won't matter. But in reality, for (non-standard) >interfaces, (hell, even for standard ones!), the only definitive source >for an object's interface is "get_interface" using the object's IR. > >> How do we reach a similar state of affairs w/r/t required rights? > >Well, that is easy, install a "get_required_rights" operation >on the object reference. Then the same scenario as the IR can ensue. > >However, this makes the object "security aware" which in some circles, >people think this is a bad idea. (why, I don't know, but there seems to be >a push to keep an object interface security unaware, but then I say what >did "get_domain_managers" do??). This *doesn't* make the object security-aware, because it isn't the object which is making calls to this method. It's still possible to invoke the object just as you did before, and the object's own methods (except the new one) don't change. What it DOES do is create a distinction between "new", securable objects, and "old", unsecurable objects. This was viewed as very undesirable by the OMG community at the time the security spec was adopted -- for obvious reasons. Would you like to re-compile all your objects in order to put ACLs on them? I think not.... >So, given that, would this kind of thing would require the RequiredRights >Repository to be a service separate from the Security Service, i.e. by >using "resovle_initial_references"? I don't have any objection to making requiredRights an entity separate from the Security service (or I wouldn't have suggested moving it to the POA!) --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom Sender: jis@fpk.hp.com Date: Tue, 17 Aug 1999 11:52:25 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Polar Humenn CC: Paul H Kyzivat , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > On Mon, 16 Aug 1999, Paul H Kyzivat wrote: > > > Bob Blakely wrote: > > > > > *It must be possible to associate a (set of) required right(s) with > > > each of an interface's methods. > > > > Yes. But I wish someone could explain to me the scope of definition, and > > how it gets defined, stored, and accessed. Somehow this should transcend > > both ORBs and Security Service implementations. My impression is that > > logically it is analogous to (in 1:1 correspondence to) interface > > repository information. > > > > But as long as it isn't part of the interface repository, and as long as > > there is no standard way of defining it, this isn't going to work. > > Agreed. Time for issuing a Required Rights Manager RFP? > > In a world where there are multiple clients, servers, and orbs all > > interoperating, there are typically going to be multiple interface > > repositories: > > > > - If I, as a client, call > > resolve_initial_reference ("InterfaceRepository") I will probably get > > one specified as part of the administration of the orb I am using on the > > node I am using. > > > > - If I call get_interface on an object reference, I will probably get > > one specified as part of the administration of the orb used by the > > server of that object on the node that server runs on. > > > > In general this won't matter, because hopefully they will have been > > populated with identical IDL, at least for the interfaces that both of > > us care about. > > In general this won't matter. But in reality, for (non-standard) > interfaces, (hell, even for standard ones!), the only definitive source > for an object's interface is "get_interface" using the object's IR. > > > How do we reach a similar state of affairs w/r/t required rights? > > Well, that is easy, install a "get_required_rights" operation > on the object reference. Then the same scenario as the IR can ensue. I should warn you that there is a very strict embargo evolving in the minds of at least more than a few AB members on adding new operations to the Object interface. Frankly, adding a get_required_rights operation as an implicit operation is not a good idea I think, because it burdens all non-security conscious OBRs, and there are going to be many such, in spite of all the protestations to the contrary by the security zealots, to support an operation that they don't care about. I will be strongly opposed to adding this operation to Object. A better way is to think in terms of defining a RequiredRightsManager and adding an operation to it that returns the RequiredRights given an Object ref or a RepId or some such. This also aids in better separation of concerns and makes it easier for Security vendors to build products without having to deal with ORB vendors:-). > However, this makes the object "security aware" which in some circles, > people think this is a bad idea. (why, I don't know, but there seems to be > a push to keep an object interface security unaware, but then I say what > did "get_domain_managers" do??). get_domain_managers iwas thought to be potentially a more general purpose facility than one that is security specific. There can be very useful use of domains for purposes other than security. At least that was the thinking then. Notwithstanding that, in retrospect - with 20/20 hindsight:-), I think it was a mistake to have added get_domain_managers as an implicit operation of an Object. The other pattern of defining a DomainManagerManager and providing an operation in it that returns a domain manager given an object reference would have been a better pattern to follow because that allows better architectural partitioning of the system. I am hoping that the Domain Management RFP submitters would bite the bullet and propose this sort of a thing in their final submission. > So, given that, would this kind of thing would require the RequiredRights > Repository to be a service separate from the Security Service, i.e. by > using "resovle_initial_references"? Clearly a better approach since that will save the independant Security vendors from having to deal with the inards of an ORB at least for the purposes of managing required rights.:-) Cheers, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Date: Tue, 17 Aug 1999 12:02:49 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Polar Humenn CC: John Marsh , Jeffrey Mischkinsky , blakley@dascom.com, paulk@roguewave.com, sec-rev@omg.org, zpope@dascom.com Subject: Re: AccessDecision object > John Marsh wrote: > > > Unfortunately some vendors a) don't require that the IR be turned on & even > > default it to being off when you install their products. > > It is not an implemenation requirement that an special IR service be > "turned-on". Although this is what some vendors have. In the case that an > IR is not "turned-on" the implemenation should raise an INTF_REPOS > exception, which I believe is compliant. Could you point me to any statement of conformance from OMG that says that IR is optional? I am not talking of what individual vendors think or say about what is conformant with their belief systems. I am looking for something that is written down somewhere in an OMG standard. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Tue, 17 Aug 1999 12:19:40 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Polar Humenn CC: Bob Blakley , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > In general this won't matter. But in reality, for (non-standard) > interfaces, (hell, even for standard ones!), the only definitive > source for an object's interface is "get_interface" using the > object's IR. This is true. But for practical use it is necessary to sync multiple IRs or their functional equivalent in the form of idl include files. When I generate a static client from IDL, the IDL I use had better be equivalent to that used to build the server, even though the server might have been built as shrink-wrap software in some distant place with a different orb. Similarly, when I build a server, I may have some expectation about the required rights for the operations I implement and for those I am client to. Having that change out from under me could lead to surprises. Having different required rights for the same operations in different servers or in different orbs will also lead to surprises. > > > How do we reach a similar state of affairs w/r/t required rights? > > Well, that is easy, install a "get_required_rights" operation > on the object reference. Then the same scenario as the IR can ensue. Yes, this might help. It would place the responsibility on the server's orb to provide clients with access to the same set of answers as used to make security decisions on the server side. But this isn't sufficient to ensure that required rights are consistent for all implementations of the same interface. Is that important? > So, given that, would this kind of thing would require the > RequiredRights Repository to be a service separate from the Security > Service, i.e. by using "resovle_initial_references"? > > I'm not proposing moving RR to that status. It's just hypothetical > question. (I don't like RequiredRights the way it is now anyway). I don't know the answer to this. But the IR has enough problems of its own, so modeling something else on it isn't likely to be a great solution unless work is done to address those problems. Both the IR and the hypothetical RR need to be distributed databases & servers. To be practical they need to be replicated/cached as well as federated with distributed management. In particular, it must be possible to cache this information in individual clients and servers (perhaps via codegen) so that they are not dependent on the presence of a separate server at runtime. Of course some dynamic features may be lost in this case, but that needs to be a developer's (or perhaps administrator's) choice. Sender: jis@fpk.hp.com Date: Tue, 17 Aug 1999 12:38:34 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Bob Blakley CC: Polar Humenn , Paul H Kyzivat , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Gosh these messages are flowing so fast and furious I can hardly keep up with them. Bob Blakley wrote: > > >> Bob Blakely wrote: > >> > >> > *It must be possible to associate a (set of) required right(s) with > >> > each of an interface's methods. > >> > >> Yes. But I wish someone could explain to me the scope of definition, and > >> how it gets defined, stored, and accessed. Somehow this should transcend > >> both ORBs and Security Service implementations. My impression is that > >> logically it is analogous to (in 1:1 correspondence to) interface > >> repository information. > >> > >> But as long as it isn't part of the interface repository, and as long as > >> there is no standard way of defining it, this isn't going to work. > > > >Agreed. > > Yes, almost by definition. The requiredRights object is supposed to be the > standard way of defining it. If you have, on the server side, a way to > determine > which interface is being invoked, then you can retrieve the requiredRights > object, > pass in the interface and method, and get back the required rights. This > *could* > be made independent of both ORBs and security service implementations, if > ORBs all made the interface information available. It would also be possible > to > store the information directly in the IR, but we were told at the time the > spec. was > written that it would be bad form to require that this be done (as it would be > an unacceptable imposition on implementors' freedom). No no no.... The IR contains only those things that are defined in IDL. Required Rights are not declared in IDL, ergo, they are not in IR. This could be changed by issuing an RFP:-). In the past I have built systems where I used a "#pragma RequiredRights" in the IDL file to actually declare these required rights and capture them in a slightly enhanced IDL compiler. > >> In a world where there are multiple clients, servers, and orbs all > >> interoperating, there are typically going to be multiple interface > >> repositories: > >> > >> - If I, as a client, call > >> resolve_initial_reference ("InterfaceRepository") I will probably get > >> one specified as part of the administration of the orb I am using on the > >> node I am using. > >> > >> - If I call get_interface on an object reference, I will probably get > >> one specified as part of the administration of the orb used by the > >> server of that object on the node that server runs on. > >> > >> In general this won't matter, because hopefully they will have been > >> populated with identical IDL, at least for the interfaces that both of > >> us care about. > > > >In general this won't matter. But in reality, for (non-standard) > >interfaces, (hell, even for standard ones!), the only definitive source > >for an object's interface is "get_interface" using the object's IR. > > > >> How do we reach a similar state of affairs w/r/t required rights? > > > >Well, that is easy, install a "get_required_rights" operation > >on the object reference. Then the same scenario as the IR can ensue. > > > >However, this makes the object "security aware" which in some circles, > >people think this is a bad idea. (why, I don't know, but there seems to be > >a push to keep an object interface security unaware, but then I say what > >did "get_domain_managers" do??). > > This *doesn't* make the object security-aware, because it isn't the object > which is making calls to this method. It's still possible to invoke the > object > just as you did before, and the object's own methods (except the new one) > don't change. > What it DOES do is create a distinction between "new", securable objects, > and "old", unsecurable objects. This was viewed as very undesirable by the > OMG community at the time the security spec was adopted -- for obvious > reasons. > Would you like to re-compile all your objects in order to put ACLs on them? > I think not.... See my diatribe on this matter in a response to Polar's message. In general, adding an operation to the implicit Object interface is an extremely painful thing, and no sooner than this one is added, the Security crew will immediately ask for an interceptor associated with that particular operation so that they can have the ORB delegate the execution to a security or required rights manager bolt on to the side of the ORB. My contention is we might as well recognize this eventuality at the outset and partition the interface design appropriately to make this easier. My proposed solution completely avoids this problem. An ORB that has security service and has a required rights/granted rights based access control system, will naturally have the RequiredRightsManager and it can be queried to get the RR info for a given interface using its RepId to identify it. The whole problem of whether an object reference is or is not available at the server end at least for getting RR info just disappears. Indeed, even if the RR object remains on the Current interface as in the original Security spec, all that Security service has to do is get the RepId of the target object from POA (which is something that is doable, perhaps with the help of the servant in some cases), and then use that to get the RR for that Repid, thus making the RR of the current target object available. Additionally, an ORB that has an access control system based on the Polar Newfangled Access Control Thingy [PNACT], will simply not have the RequiredRightsManager, and the SecurityService installed on such an ORB will simply fail to provide the RR info if someone asks for it. Instead it will be able to provide the PNACT object from the PNACTManager or whatever. > >So, given that, would this kind of thing would require the RequiredRights > >Repository to be a service separate from the Security Service, i.e. by > >using "resovle_initial_references"? > > I don't have any objection to making requiredRights an entity separate from > the Security service (or I wouldn't have suggested moving it to the POA!) However, given that RequiredRights was part of a conformance point in the original Security spec, this might take the act of an RFP to achieve.:-) Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Date: Tue, 17 Aug 1999 12:49:08 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Bob Blakley , Polar Humenn , Paul H Kyzivat , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object > The requiredRights object is supposed to be the > > standard way of defining it. If you have, on the server side, a way to > > determine > > which interface is being invoked, then you can retrieve the requiredRights > > object, > > pass in the interface and method, and get back the required rights. This > > *could* > > be made independent of both ORBs and security service implementations, if > > ORBs all made the interface information available. It would also be possible > > to > > store the information directly in the IR, but we were told at the time the > > spec. was > > written that it would be bad form to require that this be done (as it would be > > an unacceptable imposition on implementors' freedom). > > No no no.... The IR contains only those things that are defined in IDL. > Required Rights are not declared in IDL, ergo, they are not in IR. This > could be changed by issuing an RFP:-). In the past I have built systems > where I used a "#pragma RequiredRights" in the IDL file to actually > declare these required rights and capture them in a slightly enhanced > IDL compiler. At the risk of committing the cardinal sin of responding to my own message, let me point out that it is more fashionable these days to use XML based configuration descriptors to do these sorts of things.:-) Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Date: Tue, 17 Aug 1999 12:55:57 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Polar Humenn CC: Paul H Kyzivat , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > On Mon, 16 Aug 1999, Paul H Kyzivat wrote: > > Bob Blakley wrote: > > > > > * It must be possible at access decision time for the security service > > > to determine which object instance is the target of an invocation > > > which has been received by the ORB instance which the security > > > service protects. > > > > I disagree. Since control is really at the domain rather than instance > > level it should be sufficient for the security service to obtain the > > domain membership information. > > I'll agree with Paul on this. However, having the Security Service > determine the domain membership information can be problematic. It would > probably be better off letting the ORB determine the domain membership > information (since it is in the CORE) and give it to the Security Service. Seems to me that this implies that the servant interface must then have a get_domain_manager operation? > It has been noted that if the Security Service is given a servant pointer > in a system interceptor, this might cause threading maintainance and > integrity problems if the inteceptor is allowed to start invoking on the > servant. This is an important observation and it should cause us to think hard before we pass out Servant pointers all around. That is why I am in favor of providing an interface perhaps in POA, perhaps in POA current for access to these sorts of information. Just as a strawman I have been thinking interms of defining it as follows: 1. Define a local interface TargetObject as follows: local interface TargetObject { readonly attribute RepId rep_id; readonly attribute ObjectId object_id; readonly attribute POAId poa_id; readonly attribute IR::InterfaceDef interface_def; // attributes representing whatever else is // interesting about a target object // heck we could even cons up an object reference // to self with all the good info in it if // that is what you want, or even perhaps // domain manager info passed through from // servant etc. }; 2. Add an operation in POA Current that looks something like: TargetObject get_target_object(); Doing it this way does not force the ORB to actually cons up the RepId or any of the other stuff, until an actual request is made for it by invoking the _get_* method, and once the info has been consed up it can be cached. Then one can hide all the sins of the ORB and servants underneath this and give the users of this information a stable interface to work with while we carry on arguing endlessly about what is the best way to get hold of this info. > > > * It must be possible at access decision time for the security service > > > to determine which domain an object instance belongs to. > > > > I disagree, though perhaps only with the language rather than the > > intent. I agree it must be possible to get domain membership information > > for the instance as understood by the implementation. > > Well, I believe what you are saying is that the POA will not be coerced > into managing domain membership information for its servants. Correct? Ideally it should not be, except as probably a pass through of info for those cases where the Servant needs to be involved as per Paul's contention. It seems to me that there is a Domain Management RFP in process, and as far as I can tell the single submission does not say anything specific about the POA, and that is the right approach. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 17 Aug 1999 13:01:11 -0400 (EDT) From: Polar Humenn To: Paul H Kyzivat cc: Bob Blakley , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Tue, 17 Aug 1999, Paul H Kyzivat wrote: > Polar Humenn wrote: > > > > In general this won't matter. But in reality, for (non-standard) > > interfaces, (hell, even for standard ones!), the only definitive > > source for an object's interface is "get_interface" using the > > object's IR. > > This is true. But for practical use it is necessary to sync multiple IRs > or their functional equivalent in the form of idl include files. When I > generate a static client from IDL, the IDL I use had better be > equivalent to that used to build the server, even though the server > might have been built as shrink-wrap software in some distant place with > a different orb. > > Similarly, when I build a server, I may have some expectation about the > required rights for the operations I implement and for those I am client > to. Having that change out from under me could lead to surprises. Having > different required rights for the same operations in different servers > or in different orbs will also lead to surprises. This depends on the philosophy of the RR model. It would be favorable that a given operation carries with it a "rights list or expression". However, where those rights are defined seems to lie in a different place than the IDL definintions. By separating them from the IDL definition, seems to make the entire problem more of an Administrative issue, since a map must be maintained and there is no standard language to associated rights with IDL defniitions. > > > How do we reach a similar state of affairs w/r/t required rights? > > > > Well, that is easy, install a "get_required_rights" operation > > on the object reference. Then the same scenario as the IR can ensue. > > Yes, this might help. It would place the responsibility on the server's > orb to provide clients with access to the same set of answers as used to > make security decisions on the server side. > > But this isn't sufficient to ensure that required rights are consistent > for all implementations of the same interface. Is that important? I'm not sure that it is. Hmmmm, if it was, then the security spec might have defined the rights required for each of its interfaces and operations. Instead, all we did is define the small set of standard rights, but I think all we stated with is that all security interfaces can be managed by required rights, and stopped there. To me that implies an adminsitrative model. But the interfaces and the way they are now, seem to state that the administration covers all ORBs everywhere, and there is this huge, perhaps, federated database, with rights defined for all interfaces. Might be nice, but certainly not implementable, practical, or even desirable. So there is no definition of required rights, other than adminsitrative interfaces to add to the map. And the get operations are not an easy thing to export and read. I've started the beginings of a language to define required rights and in conjunction with access policy (better than) definitions. Maybe we can use something along those lines. (I can hear the Howitzers lining up). > > So, given that, would this kind of thing would require the > > RequiredRights Repository to be a service separate from the Security > > Service, i.e. by using "resovle_initial_references"? > > > > I'm not proposing moving RR to that status. It's just hypothetical > > question. (I don't like RequiredRights the way it is now anyway). > > I don't know the answer to this. > > But the IR has enough problems of its own, so modeling something else on > it isn't likely to be a great solution unless work is done to address > those problems. > > Both the IR and the hypothetical RR need to be distributed databases & > servers. To be practical they need to be replicated/cached as well as > federated with distributed management. Is this what you state is wrong with the IR model? I can see why the IR needs to be distributed for an efficency point of view and it can easily be done without changes to its interface, can it not? The interfaceDefs can even "deep" copied and cached. So, the only thing missing is, in this scenaro, is to provide "handshake" operations or notifications of when the IR is changed, or when a particular InterfaceDef has changed. Is this scenario the problem that you are getting at? However, given an object reference, over time, I would hope that the object reference is suppose to support the same interface. However, in any case, if there is a chance that it doesn't you can always call "get_interface" and find out, may not be the most effcient way. I would say then RR would suffer by the same problem. However, if we just keep RR/AP relagated to the server side access decision (for now), then I don't thing we have a real problem. But in any case, it would be nice to know from a client's view what rights you need for a particular object. > In particular, it must be possible to cache this information in > individual clients and servers (perhaps via codegen) so that they are > not dependent on the presence of a separate server at runtime. Of course > some dynamic features may be lost in this case, but that needs to be a > developer's (or perhaps administrator's) choice. Like I said, I'm working on this language, where at least on the server side the whole RR/AP access decision can be calculated, and reduced to a simple efficient evaluation function. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: "William Z Pope" To: "Richard Mark Soley" , "Paul H Kyzivat" Cc: "Bob Blakley" , "Polar Humenn" , Subject: RE: AccessDecision object Date: Tue, 17 Aug 1999 10:19:57 -0700 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal You can count me in that group too. > -----Original Message----- > From: Richard Mark Soley [mailto:soley@omg.org] > Sent: Monday, August 16, 1999 6:31 PM > To: Paul H Kyzivat > Cc: Bob Blakley; Polar Humenn; sec-rev@omg.org; William Pope > Subject: Re: AccessDecision object > > > At 07:33 PM 8/16/99 -0400, Paul H Kyzivat wrote: > >Can anybody else here claim to have done development on MULTICS? > > Yup. > > -- Soley.ARCS, Soley.Multics (I see your phcs_ and raise > you one hphcs_) > > [& I suspect there are a few others on this list -- see > http://www.multicians.org/multicians.html] > Date: Tue, 17 Aug 1999 13:36:41 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Bob Blakley CC: Polar Humenn , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Bob Blakley wrote: > > Yes, almost by definition. The requiredRights object is supposed to > be the standard way of defining it. If you have, on the server side, > a way to determine which interface is being invoked, then you can > retrieve the requiredRights object, > pass in the interface and method, and get back the required rights. I have a few problems with this: - There is a problem talking about *the* requiredRights object. Do you require all callers in the universe to see a single consistent one? If so, do you have a clue how to build such a thing so it is practical to use? (I don't!) If not, what is the scope of a particular requiredRights object, and what happens if a server and a client of that server use different ones? - does the requiredRights object have a way to define required rights? I thought it was only a way to retrieve them. Without a way to set them, I have no way to configure different requiredRights objects with consistent values. - If the results of querying this are to be used for making access decisions for each and every invocation on secured objects, and if the requiredRights object is itself a remote object, then it must be explicitly permissible to cache the results of queries, or else security will be rediculously expensive. Unless it is specified to what extent this caching is permitted and when/if/how the cache is invalidated, it will not be possible to make any meaningful assertions about security. Date: Tue, 17 Aug 1999 15:51:54 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jishnu Mukerji CC: Bob Blakley , Polar Humenn , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Jishnu Mukerji wrote: > > No no no.... The IR contains only those things that are defined in > IDL. Required Rights are not declared in IDL, ergo, they are not in > IR. This could be changed by issuing an RFP:-). In the past I have > built systems where I used a "#pragma RequiredRights" in the IDL > file to actually declare these required rights and capture them in > a slightly enhanced IDL compiler. What a great idea Jishnu! Why don't we just standardize #pragma RequiredRights as part of IDL. :-) Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Polar Humenn" , "Paul H Kyzivat" Cc: "Jishnu Mukerji" , , "William Pope" Subject: Re: AccessDecision object Date: Tue, 17 Aug 1999 14:55:51 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 >This depends on the philosophy of the RR model. It would be favorable that >a given operation carries with it a "rights list or expression". However, >where those rights are defined seems to lie in a different place than the >IDL definintions. By separating them from the IDL definition, seems to >make the entire problem more of an Administrative issue, since a map must >be maintained and there is no standard language to associated rights with >IDL defniitions. We didn't try to define a language, standard or otherwise. We assumed and intended that the mapping of methods to required rights was an administered one. Specifically, we assumed that a mapping would be defined by the developer of a class, but that it might be modified by a site security administrator or application installer. >> > > How do we reach a similar state of affairs w/r/t required rights? >> > >> > Well, that is easy, install a "get_required_rights" operation >> > on the object reference. Then the same scenario as the IR can ensue. >> >> Yes, this might help. It would place the responsibility on the server's >> orb to provide clients with access to the same set of answers as used to >> make security decisions on the server side. >> >> But this isn't sufficient to ensure that required rights are consistent >> for all implementations of the same interface. Is that important? > >I'm not sure that it is. Hmmmm, if it was, then the security spec might >have defined the rights required for each of its interfaces and >operations. Instead, all we did is define the small set of standard >rights, but I think all we stated with is that all security interfaces can >be managed by required rights, and stopped there. To me that implies an >adminsitrative model. But the interfaces and the way they are now, seem to >state that the administration covers all ORBs everywhere, and there is >this huge, perhaps, federated database, with rights defined for all >interfaces. Might be nice, but certainly not implementable, practical, or >even desirable. It wasn't intended that objects with the same interface should be able to be assigned different required rights mappings, but there's no reason in principle not to do this. To do it in a way which makes sense to administrators, however, would require the introduction of a new kind of domain, which would contain policy domains. >So there is no definition of required rights, other than adminsitrative >interfaces to add to the map. And the get operations are not an easy thing >to export and read. > >I've started the beginings of a language to define required rights and in >conjunction with access policy (better than) definitions. Maybe we can use >something along those lines. (I can hear the Howitzers lining up). No howitzers unless the semantics you define in the language are different from the ones currently specified. --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom Date: Tue, 17 Aug 1999 15:59:18 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jishnu Mukerji CC: Polar Humenn , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Jishnu Mukerji wrote: > > Seems to me that this implies that the servant interface must then > have a get_domain_manager operation? There may be other ways to skin the cat, but yes, some means like this for delegating the domain mapping to the implementation does seem to be needed. > This is an important observation and it should cause us to think hard > before we pass out Servant pointers all around. That is why I am in > favor of providing an interface perhaps in POA, perhaps in POA current > for access to these sorts of information. Just as a strawman I have > been thinking interms of defining it as follows: > > 1. Define a local interface TargetObject as follows: > > local interface TargetObject { > readonly attribute RepId rep_id; > readonly attribute ObjectId object_id; > readonly attribute POAId poa_id; > readonly attribute IR::InterfaceDef interface_def; > > // attributes representing whatever else is > // interesting about a target object > // heck we could even cons up an object reference > // to self with all the good info in it if > // that is what you want, or even perhaps > // domain manager info passed through from > // servant etc. > }; > > 2. Add an operation in POA Current that looks something like: > > TargetObject get_target_object(); > > > Doing it this way does not force the ORB to actually cons up the RepId > or any of the other stuff, until an actual request is made for it by > invoking the _get_* method, and once the info has been consed up it > can be cached. Then one can hide all the sins of the ORB and servants > underneath this and give the users of this information a stable > interface to work with while we carry on arguing endlessly about what > is the best way to get hold of this info. This looks reasonable to me. We already provide some of this information via extensions to POA Current. I would be happy to have a standard way to do it. Sender: jis@fpk.hp.com Date: Tue, 17 Aug 1999 16:32:06 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Paul H Kyzivat CC: Bob Blakley , Polar Humenn , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Paul H Kyzivat wrote: > > Jishnu Mukerji wrote: > > > > No no no.... The IR contains only those things that are defined in > > IDL. Required Rights are not declared in IDL, ergo, they are not in > > IR. This could be changed by issuing an RFP:-). In the past I have > > built systems where I used a "#pragma RequiredRights" in the IDL > > file to actually declare these required rights and capture them in > > a slightly enhanced IDL compiler. > > What a great idea Jishnu! Why don't we just standardize > #pragma RequiredRights > as part of IDL. :-) Aaaarrrrghhh! How about a new keyword "typerequiredrights".:-) Better still, a keyword identifier!:-) Afterall, you would not want to cause pain to anyone who might have used the word typerequiredrights as a variable or typename in the past.:-) Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Tue, 17 Aug 1999 16:58:06 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Polar Humenn CC: Bob Blakley , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > This depends on the philosophy of the RR model. It would be favorable > that a given operation carries with it a "rights list or expression". > However, where those rights are defined seems to lie in a different > place than the IDL definintions. By separating them from the IDL > definition, seems to make the entire problem more of an Administrative > issue, since a map must be maintained and there is no standard > language to associated rights with IDL defniitions. Defining something as an administrative issue is often merely a way to ensure that it will not be solved. Yes, it could meaningfully be an administrative issue, but only if there is sufficient standardization of the administrative interfaces so that appropriate synchronization of security is possible on multiple nodes, orbs, and security service implementations. Even before that there is need for discussion of what required rights ought to be, at least for standardized IDL. And this requires some notation to document proposed and agreed rights assignments. For example, take any arbitrary piece of IDL that has been standardized by the OMG - say the Notification service just to pick something at random. Would two reasonable people consistently assign required rights to this IDL? If there is ever to be interoperability, shouldn't something be done to ensure this? If there was a way to do this (RDL - Rights Definition Language?), then perhaps you could hand wave around interfaces and tools for mapping from the notation to the actual RequiredRights object just as we hand wave about the tools for mapping from IDL to the IR. > > But this isn't sufficient to ensure that required rights are > > consistent for all implementations of the same interface. > > Is that important? > > I'm not sure that it is. Hmmmm, if it was, then the security spec > might have defined the rights required for each of its interfaces > and operations. I rest my case. > Instead, all we did is define the small set of > standard rights, but I think all we stated with is that all security > interfaces can be managed by required rights, and stopped there. > To me that implies an adminsitrative model. But the interfaces and > the way they are now, seem to state that the administration covers > all ORBs everywhere, and there is this huge, perhaps, federated > database, with rights defined for all interfaces. Might be nice, > but certainly not implementable, practical, or even desirable. This is my main point. Until this is fixed the whole thing is broken except in toy closed environments. > I've started the beginings of a language to define required rights and > in conjunction with access policy (better than) definitions. > Maybe we can use something along those lines. > (I can hear the Howitzers lining up). This sounds like what I suggested above. Why should this be so controversial? > > Both the IR and the hypothetical RR need to be distributed databases > > & servers. To be practical they need to be replicated/cached as well > > as federated with distributed management. > > Is this what you state is wrong with the IR model? That is part of it. It is also necessary to tolerate a degree of inconsistency. Suppose two independent companies A and B begin to develop their own accounting systems. They independently define IDL with a module Accounting containing an interface Invoice, and production systems that depend on their particular definition. I don't think you will find anyone that believes these companies would be willing to accept a single IR (or RR) that would prevent them from independently developing interfaces of the same name (or expose what interfaces they were defining.) There must be some notion of scope for an IR or RR, but none is currently specified. Now suppose A & B merge. Eventually one or both of the systems are going to have to change. But before they do, both had better continue to work. As new systems are deployed, perhaps tying together nodes from both A & B, it is going to be necessary to federate the IRs (and RRs) of A and B. But there is no notion of federation for these things, nor any capability for conflicting definitions to exist in such a federation. > I can see why the > IR needs to be distributed for an efficency point of view and it can > easily be done without changes to its interface, can it not? Presumably it could be replicated without change to existing interfaces. But distributing and federating it in a way that doesn't require all pieces to be supplied by a single vendor does at least require adding more standardized interfaces. It also requires orb vendors to either participate in a federation or else populate a repository supplied by someone else. It also probably requires the repository to be secured by some sort of interoperable security mechanism, since I don't want just anybody changing the descriptions of my production system interfaces. > > The interfaceDefs can even "deep" copied and cached. So, the only > thing missing is, in this scenaro, is to provide "handshake" > operations or notifications of when the IR is changed, or when a > particular InterfaceDef has changed. Is this scenario the problem > that you are getting at? More or less. This isn't a small change. > I would say then RR would suffer by the same problem. However, if we > just keep RR/AP relagated to the server side access decision (for > now), then I don't thing we have a real problem. But in any case, > it would be nice to know from a client's view what rights you need > for a particular object. As long as everybody agrees that inconsistency of RR data from server to server is ok, then this solves much of the problem. For the time being I think this would be a good solution. If this can be used at the time code is generated for servers, then it should be possible to get the required rights for free as part of the code that looks up an operation for dispatch. Combine that with a capability to obtain the domain from the servant, and with a server local cache of granted rights per [domain,client credentials] (or better yet, per connection in simple cases), and you might have authorization that is usable. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 17 Aug 1999 17:54:51 -0400 (EDT) From: Polar Humenn To: Paul H Kyzivat cc: Bob Blakley , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Tue, 17 Aug 1999, Paul H Kyzivat wrote: > Polar Humenn wrote: > > > > This depends on the philosophy of the RR model. It would be favorable > > that a given operation carries with it a "rights list or expression". > > However, where those rights are defined seems to lie in a different > > place than the IDL definintions. By separating them from the IDL > > definition, seems to make the entire problem more of an Administrative > > issue, since a map must be maintained and there is no standard > > language to associated rights with IDL defniitions. > > Defining something as an administrative issue is often merely a way to > ensure that it will not be solved. Yep, it usually is a cop out. > Yes, it could meaningfully be an administrative issue, but only if there > is sufficient standardization of the administrative interfaces so that > appropriate synchronization of security is possible on multiple nodes, > orbs, and security service implementations. > > Even before that there is need for discussion of what required rights > ought to be, at least for standardized IDL. And this requires some > notation to document proposed and agreed rights assignments. > > For example, take any arbitrary piece of IDL that has been standardized > by the OMG - say the Notification service just to pick something at > random. Would two reasonable people consistently assign required rights > to this IDL? If there is ever to be interoperability, shouldn't > something be done to ensure this? > > If there was a way to do this (RDL - Rights Definition Language?), then > perhaps you could hand wave around interfaces and tools for mapping from > the notation to the actual RequiredRights object just as we hand wave > about the tools for mapping from IDL to the IR. That would be the result yes. > > > But this isn't sufficient to ensure that required rights are > > > consistent for all implementations of the same interface. > > > Is that important? > > > > I'm not sure that it is. Hmmmm, if it was, then the security spec > > might have defined the rights required for each of its interfaces > > and operations. > > I rest my case. > > > Instead, all we did is define the small set of > > standard rights, but I think all we stated with is that all security > > interfaces can be managed by required rights, and stopped there. > > To me that implies an adminsitrative model. But the interfaces and > > the way they are now, seem to state that the administration covers > > all ORBs everywhere, and there is this huge, perhaps, federated > > database, with rights defined for all interfaces. Might be nice, > > but certainly not implementable, practical, or even desirable. > > This is my main point. Until this is fixed the whole thing is broken > except in toy closed environments. > > > I've started the beginings of a language to define required rights and > > in conjunction with access policy (better than) definitions. > > Maybe we can use something along those lines. > > (I can hear the Howitzers lining up). > > This sounds like what I suggested above. > Why should this be so controversial? I don't know. Some people say that since Policy languages cannot cover everything and express everything, why bother. But then I say, IDL isn't a great policy language. I'd like to see some administrative interfaces that can take various sorts of descriptions and may or may not be able to process them. Such as something on the order of: struct AccessDecisionPolicyDescription { string type; any description; }; typdef sequence DescriptionTypeList; interface ServerAdminAccessControlPolicy { readonly attribute DescriptionTypeList supported_descriptions; AccessPolicyDescription get_policy_description( in string type ); void update_policy( in AccessPolicyDescription ); }; Specific query functions can inherit this interface. However, this leaves the door open for current and future descriptions, as they come available. Update_policy can do all sorts of things depending on the types it supports, such as modifying the policy, replacing the policy, etc. > > > Both the IR and the hypothetical RR need to be distributed databases > > > & servers. To be practical they need to be replicated/cached as well > > > as federated with distributed management. > > > > Is this what you state is wrong with the IR model? > > That is part of it. > It is also necessary to tolerate a degree of inconsistency. > > Suppose two independent companies A and B begin to develop their own > accounting systems. They independently define IDL with a module > Accounting containing an interface Invoice, and production systems that > depend on their particular definition. I don't think you will find > anyone that believes these companies would be willing to accept a single > IR (or RR) that would prevent them from independently developing > interfaces of the same name (or expose what interfaces they were > defining.) There must be some notion of scope for an IR or RR, but none > is currently specified. Yeah, I suggested this before, if we had to have this RR object it should be supported by a standard RequireRightsRepository that should hang off of a domain (or be a domain!) that would give it scope. Objects would belong to some RR domain, and that object would define it. > Now suppose A & B merge. Eventually one or both of the systems are going > to have to change. But before they do, both had better continue to work. > As new systems are deployed, perhaps tying together nodes from both A & > B, it is going to be necessary to federate the IRs (and RRs) of A and B. > But there is no notion of federation for these things, nor any > capability for conflicting definitions to exist in such a federation. Then the problem would be solved by some sort of domain federation. (It's a hard problem I know, but if domain managment is done right, we can even piggy back the IR problem off of it.) > As long as everybody agrees that inconsistency of RR data from server to > server is ok, then this solves much of the problem. For the time being I > think this would be a good solution. Yes, I believe this should primarily be the case. Solve the access decision at the server first. Client's do not know about RR. > If this can be used at the time code is generated for servers, then it > should be possible to get the required rights for free as part of the > code that looks up an operation for dispatch. Combine that with a > capability to obtain the domain from the servant, and with a server > local cache of granted rights per [domain,client credentials] (or better > yet, per connection in simple cases), and you might have authorization > that is usable. Right. ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Tue, 17 Aug 1999 18:19:40 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Polar Humenn CC: Bob Blakley , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > Some people say that since Policy languages cannot cover > everything and express everything, why bother. But then I say, IDL > isn't a great policy language. > > I'd like to see some administrative interfaces that can take various > sorts of descriptions and may or may not be able to process them. > Such as something on the order of: [snip] I wasn't looking for so much - just trying to solve a smaller problem, the required rights data. It should be simple to come up with a language that first imports definitions from IDL (see the CCM proposal for a way to denote this). Then it only needs some simple statements to reference or define new rights families, and to associate required rights with interfaces. E.g. import CosNaming; require CosNaming::NamingContext::bind write; require CosNaming::NamingContext::resolve read; require CosNaming::NamingContext::bind_new_context write; require CosNaming::NamingContext::new_context admin; ... This is ugly and verbose, so some fancier syntax could make it more concise and readable, but you get the idea. As long as there is agreement that there is such a thing as required rights, and that they should be as global as idl, it should not be hard to get agreement on some syntax like this. It would then permit discussion of required rights for standardized interfaces, and possibly even standardization of these assignments. (Though the latter might be more controversial.) It would also permit some portability between admininstration tools. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 17 Aug 1999 18:34:05 -0400 (EDT) From: Polar Humenn To: Paul H Kyzivat cc: Bob Blakley , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Tue, 17 Aug 1999, Paul H Kyzivat wrote: > Polar Humenn wrote: > > > > Some people say that since Policy languages cannot cover > > everything and express everything, why bother. But then I say, IDL > > isn't a great policy language. > > > > I'd like to see some administrative interfaces that can take various > > sorts of descriptions and may or may not be able to process them. > > Such as something on the order of: > [snip] > > I wasn't looking for so much - just trying to solve a smaller problem, > the required rights data. It should be simple to come up with a language > that first imports definitions from IDL (see the CCM proposal for a way > to denote this). Then it only needs some simple statements to reference > or define new rights families, and to associate required rights with > interfaces. E.g. > > import CosNaming; > > require CosNaming::NamingContext::bind write; > require CosNaming::NamingContext::resolve read; > require CosNaming::NamingContext::bind_new_context write; > require CosNaming::NamingContext::new_context admin; > ... > > This is ugly and verbose, so some fancier syntax could make it more > concise and readable, but you get the idea. Yes, but through the interface I proposed it would be able to accept a lanaguage such as this or a fancyier one. I'd give a presentation on my "very" simple langauge, but I don't think we have space in the adgenda. Aside from it using the incrediably ugly RepositoryId values, I can write "right predicates", since the spec trys something along these lines with the rights combinator All and Any. (This I believe was a mistake, since it complicates things and it could be better expressed if it went that far). So, the rights predicate no longer consider rights as strickly "required" (the ANY combinator strangely says "only one of the following required rights is required"). A rights predicate gives a description of what must be present. So, expressions can be formed with And, Or, Any, and All. Not really sure if NOT is needed, but it isn't hard to add in this context. The language as I present it is simply paranthesized structures, which makes it a nice candidate for XML type type tools as well. What's nice about it, is that you can take the language used for AccessPolicy which maps security attributes to rights, merge them before hand, reduce the expressions to a nifty efficient evaluator for AccessDecision expression. > As long as there is agreement that there is such a thing as required > rights, and that they should be as global as idl, it should not be hard > to get agreement on some syntax like this. It would then permit > discussion of required rights for standardized interfaces, and possibly > even standardization of these assignments. (Though the latter might be > more controversial.) > > It would also permit some portability between admininstration tools. Agreed. ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Jishnu Mukerji" Cc: "Polar Humenn" , , "William Pope" Subject: Re: AccessDecision object Date: Tue, 17 Aug 1999 17:43:37 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 >1. It must be possible to control access to individual >> methods of individual object instances. In particular, >> it must be possible to apply different access control >> policies to different instances of the same interface. > >2. It must be possible to group instances into domains, >> and to assign the same access policy to each member >> of a domain. In particular, this must be possible >> even if the members of the domain do not all implement >> the same interface (or interfaces). > >2a. (It must be possible at administration time to change >> the domain membership of each object instance.) > >2b. (It must be possible at administration time to change >> the policy associated with each domain.) > >3.* It must be possible at access decision time for the >> security service to determine which object instance is >> the target of an invocation which has been received by >> the ORB instance which the security service protects. > >4.* It must be possible at access decision time for the >> security service to determine which domain an object >> instance belongs to. > >5.*It must be possible to associate a (set of) required >> right(s) with each of an interface's methods. > >5a. (It must be possible at administration time to set >> and/or change the required right(s) assigned to each >> method of an interface.) > >6.*It must be possible at access decision time for the >> security service to determine what rights are required >> to invoke the method which the caller has asked to >> invoke. > >7.* It must be possible at access decision time for the >> security service to determine which interface of an >> invoked object instance is being used. > >8.* It must be possible at access decision time for >> the security service to determine which rights are >> required to invoke a particular method of a particular >> interface. > >An excellent list to use as the basis for this discussion. Why thank you. >I took the liberty of assigning numbers to the requirements enumerated in the list. >I would submit that 2, 2a and 2b fall within the purview of the Domain >Management RFP. I agree. >1 and 4 depend on the availability of 2. I don't strictly agree that 1 depends on 2, but I think the CORBAsecurity implementation *intends* it to depend on 2 (i.e. we did not have or invent a requirement to be able to apply policies to individual instances without putting them in domains, but we did have and recognize a requirement to assign different instances of the same interface to different domains with different policies). I'm also not sure that 4 depends on 2. It may be more like the other way around - 2 is useless without 4 but in an implementation sense doesn't strictly depend on it. >As for 1, the ORB on which the target object is hosted does have the necessary info in >it to make this possible, provided the Domain Management service is able >to provide the binding into separate policy domains for separate object >references. It dang well better! >The information needed for providing 3 has got to be already available >within an ORB on which the target object is hosted, in some way shape or >form, because without it, the ORB could not route the invocation to the >right object and the right method. In POA parlance the triplet object_id, Rep_id> uniquely identify an object instance of a specific >type. The issue there is how is this to be made visible/accessible to >the programmers of security service. Exactly. In particular, what piece of IDL-specifiable and ORB-application-accessible information represents the target object instance? >How 5 and 5a and hence 6 are currently achieved is unclear to me. Any >Security Service implementers with any view on this? Is there any >specific support needed from the ORB/POA to effect this? If so, I'd like >to understand what that is. Right, and this is to a large extent what we've been discussing. My intuition is the information needed to support 5 and 5a is accessible to POA implementors, because they need to be able to figure out which method's code to invoke and where to get that code. Given this, it seems reasonable to me to ask the POA implementation to implement the "requiredRights" interface, because it's the only thing which should be guaranteed to have this information. Hence I've suggested that requirement 6 be met by requiring POAs to implement requiredRights. >The information that can be constructed and made available in the ORB on >which the target object is hosted, relative to 7 is the RepId of the >most derived interface supported by the target object. This interface >contains *all* the operations that the target object claims to support. >The specific invocation from the client may however have used a version >of the reference through which all the operations were not visible to >the client. Yes. But it won't have invoked an operation which wasn't visible to it, of course. >As for 8, I need clarification about what you mean by a particular >method of a particular interface. The interface using which an >invocation is done contains an object key identifying the exact object >on which the method is to be invoked. Do you in addition need to know >which particular narrowed form of interface was used to do this >particular invocation? My understanding is that that info may not always >be available, and even if it was it wouldn't be particularly trustworthy >absent a whole additional layer of mechanism to integrity protect it, >and that too, only to the extent that you trust the ORB that hosts the >client and everything else on the way from there to here. Well, remember we had the discussion of figuring out which interface's required rights we needed to look at back during the spec. authoring phase. This is why we propose using the MDI - because it gives us a closed-form algorithm for figuring out which interface's RRs to use in making a policy decision. >Of course, all my comments above are relative to the server end. At the >client end it is a very different story. All that you have is an object >reference that the ORB at the client end is able to extract only the >following info, the host, the port, the object key, and in addition a >type id, and any of the security profiles that it happens to understand, >that's it. What is worse is that if the IOR has been transformed through >a few Firewalls and such, then even those pieces of info may have very >little to do with the corresponding info in the original IOR. So doing >any client side access control is a different kettle of fish, and I'd >suggest that we place that on the back burner for now until we get the >critical server side all straightened out. I agree >In working out the solutions one thing that I would like to see us abide >by is that we do not specify interfaces that force early binding of data >thus removing all opportunities for late binding optimizations from the >ORB implementors. That is my fervent plea. No objections. --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom From: "Martin Chapman" To: "Bob Blakley" , "Jishnu Mukerji" Cc: "Polar Humenn" , , "William Pope" , "Steve Vinoski" , "Bob Kukura" Subject: RE: AccessDecision object Date: Wed, 18 Aug 1999 10:33:46 +0100 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal Guys, I'm really confused by this thread. I'm not disagreeing with the requirments, and some of the proposals may make sense, but imho it is way out of scope for this RTF to be doing this. Issue a new RFP (if not already covered by the extant ones) to solve this. Martin. > -----Original Message----- > From: Bob Blakley [mailto:blakley@dascom.com] > Sent: 17 August 1999 23:44 > To: Jishnu Mukerji > Cc: Polar Humenn; sec-rev@omg.org; William Pope > Subject: Re: AccessDecision object > > > >1. It must be possible to control access to individual > >> methods of individual object instances. In particular, > >> it must be possible to apply different access control > >> policies to different instances of the same interface. > > > >2. It must be possible to group instances into domains, > >> and to assign the same access policy to each member > >> of a domain. In particular, this must be possible > >> even if the members of the domain do not all implement > >> the same interface (or interfaces). > > > >2a. (It must be possible at administration time to change > >> the domain membership of each object instance.) > > > >2b. (It must be possible at administration time to change > >> the policy associated with each domain.) > > > >3.* It must be possible at access decision time for the > >> security service to determine which object instance is > >> the target of an invocation which has been received by > >> the ORB instance which the security service protects. > > > >4.* It must be possible at access decision time for the > >> security service to determine which domain an object > >> instance belongs to. > > > >5.*It must be possible to associate a (set of) required > >> right(s) with each of an interface's methods. > > > >5a. (It must be possible at administration time to set > >> and/or change the required right(s) assigned to each > >> method of an interface.) > > > >6.*It must be possible at access decision time for the > >> security service to determine what rights are required > >> to invoke the method which the caller has asked to > >> invoke. > > > >7.* It must be possible at access decision time for the > >> security service to determine which interface of an > >> invoked object instance is being used. > > > >8.* It must be possible at access decision time for > >> the security service to determine which rights are > >> required to invoke a particular method of a particular > >> interface. > > > >An excellent list to use as the basis for this discussion. > > Why thank you. > > >I took the liberty of assigning numbers to the requirements > enumerated in the > list. > >I would submit that 2, 2a and 2b fall within the purview of the Domain > >Management RFP. > > I agree. > > >1 and 4 depend on the availability of 2. > > I don't strictly agree that 1 depends on 2, but I think the CORBAsecurity > implementation *intends* it to depend on 2 (i.e. we did not have or invent > a requirement to be able to apply policies to individual instances without > putting them in domains, but we did have and recognize a requirement to > assign different instances of the same interface to different domains with > different policies). > > I'm also not sure that 4 depends on 2. It may be more like the other way > around - 2 is useless without 4 but in an implementation sense doesn't > strictly depend on it. > > >As for 1, the ORB on which the target object is hosted does have the > necessary info in > >it to make this possible, provided the Domain Management service is able > >to provide the binding into separate policy domains for separate object > >references. > > It dang well better! > > >The information needed for providing 3 has got to be already available > >within an ORB on which the target object is hosted, in some way shape or > >form, because without it, the ORB could not route the invocation to the > >right object and the right method. In POA parlance the triplet >object_id, Rep_id> uniquely identify an object instance of a specific > >type. The issue there is how is this to be made visible/accessible to > >the programmers of security service. > > Exactly. In particular, what piece of IDL-specifiable and > ORB-application-accessible > information represents the target object instance? > > >How 5 and 5a and hence 6 are currently achieved is unclear to me. Any > >Security Service implementers with any view on this? Is there any > >specific support needed from the ORB/POA to effect this? If so, I'd like > >to understand what that is. > > Right, and this is to a large extent what we've been discussing. My > intuition is the information needed to support 5 and 5a is accessible to > POA implementors, because they need to be able to figure out which > method's code to invoke and where to get that code. Given this, it > seems reasonable to me to ask the POA implementation to implement > the "requiredRights" interface, because it's the only thing which > should be > guaranteed to have this information. Hence I've suggested that > requirement > 6 be met by requiring POAs to implement requiredRights. > > >The information that can be constructed and made available in the ORB on > >which the target object is hosted, relative to 7 is the RepId of the > >most derived interface supported by the target object. This interface > >contains *all* the operations that the target object claims to support. > >The specific invocation from the client may however have used a version > >of the reference through which all the operations were not visible to > >the client. > > Yes. But it won't have invoked an operation which wasn't visible to > it, of course. > > >As for 8, I need clarification about what you mean by a particular > >method of a particular interface. The interface using which an > >invocation is done contains an object key identifying the exact object > >on which the method is to be invoked. Do you in addition need to know > >which particular narrowed form of interface was used to do this > >particular invocation? My understanding is that that info may not always > >be available, and even if it was it wouldn't be particularly trustworthy > >absent a whole additional layer of mechanism to integrity protect it, > >and that too, only to the extent that you trust the ORB that hosts the > >client and everything else on the way from there to here. > > Well, remember we had the discussion of figuring out which interface's > required rights we needed to look at back during the spec. authoring > phase. This is why we propose using the MDI - because it gives us > a closed-form algorithm for figuring out which interface's RRs to use > in making a policy decision. > > >Of course, all my comments above are relative to the server end. At the > >client end it is a very different story. All that you have is an object > >reference that the ORB at the client end is able to extract only the > >following info, the host, the port, the object key, and in addition a > >type id, and any of the security profiles that it happens to understand, > >that's it. What is worse is that if the IOR has been transformed through > >a few Firewalls and such, then even those pieces of info may have very > >little to do with the corresponding info in the original IOR. So doing > >any client side access control is a different kettle of fish, and I'd > >suggest that we place that on the back burner for now until we get the > >critical server side all straightened out. > > > I agree > > >In working out the solutions one thing that I would like to see us abide > >by is that we do not specify interfaces that force early binding of data > >thus removing all opportunities for late binding optimizations from the > >ORB implementors. That is my fervent plea. > > No objections. > > --bob > > Bob Blakley (blakley@dascom.com) > Chief Scientist, Dascom > > Date: Wed, 18 Aug 1999 08:52:57 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Martin Chapman CC: Bob Blakley , Jishnu Mukerji , Polar Humenn , sec-rev@omg.org, William Pope , Steve Vinoski , Bob Kukura Subject: Re: AccessDecision object Martin Chapman wrote: > > Guys, > > I'm really confused by this thread. > I'm not disagreeing with the requirments, and some of the proposals > may make sense, but imho it is way out of scope for this RTF to be > doing this. > Issue a new RFP (if not already covered by the extant ones) to solve > this. At the moment this is just a far ranging discussion. It doesn't seem to me that it is out of scope to have the discussion. I agree it is likely that many possible resolutions will be out of scope for an RTF and will indeed require an RFP, but we won't know that for sure until we reach some conclusion in these discussions. (Maybe the conclusion will be that we need to issue an RFP.) But until then, this seems like a forum involving people with the right set of interests. Of course, if enough people object, the discussion could become a private one. Date: Wed, 18 Aug 1999 09:07:49 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jishnu Mukerji CC: Polar Humenn , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Jishnu Mukerji wrote: > > Time for issuing a Required Rights Manager RFP? I suppose this doesn't fit into Domain Membership, so maybe. > > Well, that is easy, install a "get_required_rights" operation > > on the object reference. Then the same scenario as the IR can ensue. > > I should warn you that there is a very strict embargo evolving in the > minds of at least more than a few AB members on adding new operations > to the Object interface. Frankly, adding a get_required_rights > operation as an implicit operation is not a good idea I think, > because it burdens all non-security conscious OBRs, and there are > going to be many such, in spite of all the protestations to the > contrary by the security zealots, to support an operation that they > don't care about. I will be strongly opposed to adding this operation > to Object. I share your concern. > A better way is to think in terms of defining a > RequiredRightsManager and adding an operation to it > that returns the RequiredRights given an Object ref or a RepId or some > such. This also aids in better separation of concerns and makes it > easier for Security vendors to build products without having to deal > with ORB vendors:-). Perhaps something can be done this way, but there are some problems to deal with. The good thing about get_interface is that, because it is an operation on the object, it is serviced by the object or more likely by the orb hosting the object's implementation. Therefore there is reason to expect the result to be consistent with the object's implementation. It also doesn't require the existence of a grand and glorious single universal interface repository. With a RequiredRightsManager I don't *currently* see how to get the same benefits. How would a client and server agree on a common RequiredRightsManager? (Since a client may be talking to several servers, it is quite possible that there is no one manager that will be shared in common with all the servers.) This wouldn't be such a problem if confined to the server side. But on the server side it isn't clear that the RequiredRightsManager is needed at all - it is probably better to find a way for the orb to directly provide the security service with the required rights of the operation being authenticated. Date: Wed, 18 Aug 1999 09:36:50 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Bob Blakley CC: Jishnu Mukerji , Polar Humenn , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Bob Blakley wrote: > > >In POA parlance the triplet uniquely > >identify an object instance of a specific > >type. The issue there is how is this to be made visible/accessible to > >the programmers of security service. Just to clarify - Rep_id does not enter into this. It can be *derived* from the servant selected with , so it is a dependent variable, not an independent one. - only uniquely identifies the servant/object instance in the context of a particular server. > Exactly. In particular, what piece of IDL-specifiable and > ORB-application-accessible > information represents the target object instance? All the orb/poa can do is select a servant based on . >From the orb's point of view, identify the target object instance. (Servant alone isn't sufficient, because the same servant can simultaneously service many pairs.) > My intuition is the information needed to support 5 and 5a is > accessible to > POA implementors, because they need to be able to figure out which > method's code to invoke and where to get that code. Given this, it > seems reasonable to me to ask the POA implementation to implement > the "requiredRights" interface, because it's the only thing which > should be guaranteed to have this information. Hence I've suggested > that requirement 6 be met by requiring POAs to implement > requiredRights. Be careful talking about the POA as an identifiable entity distinct from the ORB implementation, and from the orb specific generated code. There are probably many ways to partition responsibility. The POA can find the servant, but it is the servant that knows what interface(s) it implements, so it is the one that might be expected to know the required rights for a particular operation. Perhaps the POA (or some part of the ORB) could serve as an intermediary by obtaining this information from the servant and passing it to the security service. In the case of DSI, the only currently available hook in the servant is provided_interface. This would then require some sort of lookup to get required_rights. With static skeletons it would be nice to be able to compile the required rights in and avoid the lookup. Supporting 5a implies that the required rights *cannot* be compiled in, but rather must be dynamically looked up in some changeable database. Depending on how quickly such changes must be visible, this can impose a huge cost. It needs to be carefully investigated. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 18 Aug 1999 10:53:50 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Paul H Kyzivat , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Tue, 17 Aug 1999, Jishnu Mukerji wrote: > Polar Humenn wrote: > > > > On Mon, 16 Aug 1999, Paul H Kyzivat wrote: > > > > > Bob Blakely wrote: > > > > > > > *It must be possible to associate a (set of) required right(s) with > > > > each of an interface's methods. > > > > > > Yes. But I wish someone could explain to me the scope of definition, and > > > how it gets defined, stored, and accessed. Somehow this should transcend > > > both ORBs and Security Service implementations. My impression is that > > > logically it is analogous to (in 1:1 correspondence to) interface > > > repository information. > > > > > > But as long as it isn't part of the interface repository, and as long as > > > there is no standard way of defining it, this isn't going to work. > > > > Agreed. > > Time for issuing a Required Rights Manager RFP? Well, actually, I would rather see an "system" access decision RFP, instead of a RequiredRights RFP. I don't really think you should handle one separately from the other parts of the equation. > > > In a world where there are multiple clients, servers, and orbs all > > > interoperating, there are typically going to be multiple interface > > > repositories: > > > > > > - If I, as a client, call > > > resolve_initial_reference ("InterfaceRepository") I will probably get > > > one specified as part of the administration of the orb I am using on the > > > node I am using. > > > > > > - If I call get_interface on an object reference, I will probably get > > > one specified as part of the administration of the orb used by the > > > server of that object on the node that server runs on. > > > > > > In general this won't matter, because hopefully they will have been > > > populated with identical IDL, at least for the interfaces that both of > > > us care about. > > > > In general this won't matter. But in reality, for (non-standard) > > interfaces, (hell, even for standard ones!), the only definitive source > > for an object's interface is "get_interface" using the object's IR. > > > > > How do we reach a similar state of affairs w/r/t required rights? > > > > Well, that is easy, install a "get_required_rights" operation > > on the object reference. Then the same scenario as the IR can ensue. > > I should warn you that there is a very strict embargo evolving in the > minds of at least more than a few AB members on adding new operations to > the Object interface. Yes, I know. I was being fecicious, in knowing that was next to impossible. > Frankly, adding a get_required_rights operation as > an implicit operation is not a good idea I think, because it burdens all > non-security conscious OBRs, and there are going to be many such, in > spite of all the protestations to the contrary by the security zealots, > to support an operation that they don't care about. My point exactly. > I will be strongly > opposed to adding this operation to Object. A better way is to think in > terms of defining a RequiredRightsManager and adding an operation to it > that returns the RequiredRights given an Object ref or a RepId or some > such. This also aids in better separation of concerns and makes it > easier for Security vendors to build products without having to deal > with ORB vendors:-). Well, that is provided that the OMA can get the information it needs to perform such tasks. However, there are serious recursive problems involved. And I don't like the fact that the interface is locality constrained so you can PUNT on the distributed issues and go behind and underneath CORBA to support CORBA security. > > However, this makes the object "security aware" which in some circles, > > people think this is a bad idea. (why, I don't know, but there seems to be > > a push to keep an object interface security unaware, but then I say what > > did "get_domain_managers" do??). > > get_domain_managers iwas thought to be potentially a more general > purpose facility than one that is security specific. There can be very > useful use of domains for purposes other than security. At least that > was the thinking then. Notwithstanding that, in retrospect - with 20/20 > hindsight:-), I think it was a mistake to have added get_domain_managers > as an implicit operation of an Object. The other pattern of defining a > DomainManagerManager and providing an operation in it that returns a > domain manager given an object reference would have been a better > pattern to follow because that allows better architectural partitioning > of the system. I am hoping that the Domain Management RFP submitters > would bite the bullet and propose this sort of a thing in their final > submission. I believe the problem there was making something standard without much research and implemenation experience to warrant its specification. It was a hopeful gamble. > > So, given that, would this kind of thing would require the RequiredRights > > Repository to be a service separate from the Security Service, i.e. by > > using "resovle_initial_references"? > > Clearly a better approach since that will save the independant Security > vendors from having to deal with the inards of an ORB at least for the > purposes of managing required rights.:-) Agreed. ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 18 Aug 1999 11:00:25 -0400 (EDT) From: Polar Humenn To: Paul H Kyzivat cc: Jishnu Mukerji , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Wed, 18 Aug 1999, Paul H Kyzivat wrote: > Jishnu Mukerji wrote: > > > > Time for issuing a Required Rights Manager RFP? > > I suppose this doesn't fit into Domain Membership, so maybe. > > > > Well, that is easy, install a "get_required_rights" operation > > > on the object reference. Then the same scenario as the IR can ensue. > > > > I should warn you that there is a very strict embargo evolving in the > > minds of at least more than a few AB members on adding new operations > > to the Object interface. Frankly, adding a get_required_rights > > operation as an implicit operation is not a good idea I think, > > because it burdens all non-security conscious OBRs, and there are > > going to be many such, in spite of all the protestations to the > > contrary by the security zealots, to support an operation that they > > don't care about. I will be strongly opposed to adding this operation > > to Object. > > I share your concern. > > > A better way is to think in terms of defining a > > RequiredRightsManager and adding an operation to it > > that returns the RequiredRights given an Object ref or a RepId or some > > such. This also aids in better separation of concerns and makes it > > easier for Security vendors to build products without having to deal > > with ORB vendors:-). > > Perhaps something can be done this way, but there are some problems to > deal with. The good thing about get_interface is that, because it is an > operation on the object, it is serviced by the object or more likely by > the orb hosting the object's implementation. Therefore there is reason > to expect the result to be consistent with the object's implementation. > It also doesn't require the existence of a grand and glorious single > universal interface repository. > > With a RequiredRightsManager I don't *currently* see how to get the same > benefits. How would a client and server agree on a common > RequiredRightsManager? (Since a client may be talking to several > servers, it is quite possible that there is no one manager that will be > shared in common with all the servers.) > > This wouldn't be such a problem if confined to the server side. But on > the server side it isn't clear that the RequiredRightsManager is needed > at all - it is probably better to find a way for the orb to directly > provide the security service with the required rights of the operation > being authenticated. > I see this RequiredRights (Repository??) as tacked onto a Domain. So then objects are in a required rights domain. The RR can be gotten off of the get_domain_managers call. ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Paul H Kyzivat" , "Martin Chapman" Cc: "Jishnu Mukerji" , "Polar Humenn" , , "William Pope" , "Steve Vinoski" , "Bob Kukura" Subject: Re: AccessDecision object Date: Wed, 18 Aug 1999 10:34:08 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 I agree with Paul here. We certainly need to have discussions about these issues somewhere; as long as we don't actually *propose* any far-reaching changes, we're on semi-solid ground. --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom -----Original Message----- From: Paul H Kyzivat To: Martin Chapman Cc: Bob Blakley ; Jishnu Mukerji ; Polar Humenn ; sec-rev@omg.org ; William Pope ; Steve Vinoski ; Bob Kukura Date: Wednesday, August 18, 1999 8:04 AM Subject: Re: AccessDecision object >Martin Chapman wrote: >> >> Guys, >> >> I'm really confused by this thread. >> I'm not disagreeing with the requirments, and some of the proposals >> may make sense, but imho it is way out of scope for this RTF to be >> doing this. >> Issue a new RFP (if not already covered by the extant ones) to solve >> this. > >At the moment this is just a far ranging discussion. >It doesn't seem to me that it is out of scope to have the discussion. >I agree it is likely that many possible resolutions will be out of scope >for an RTF and will indeed require an RFP, but we won't know that for >sure until we reach some conclusion in these discussions. (Maybe the >conclusion will be that we need to issue an RFP.) > >But until then, this seems like a forum involving people with the right >set of interests. Of course, if enough people object, the discussion >could become a private one. > Sender: jis@fpk.hp.com Date: Wed, 18 Aug 1999 12:40:32 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Paul H Kyzivat CC: Polar Humenn , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Paul H Kyzivat wrote: > > Jishnu Mukerji wrote: > > > A better way is to think in terms of defining a > > RequiredRightsManager and adding an operation to it > > that returns the RequiredRights given an Object ref or a RepId or some > > such. This also aids in better separation of concerns and makes it > > easier for Security vendors to build products without having to deal > > with ORB vendors:-). > > Perhaps something can be done this way, but there are some problems to > deal with. The good thing about get_interface is that, because it is an > operation on the object, it is serviced by the object or more likely by > the orb hosting the object's implementation. Therefore there is reason > to expect the result to be consistent with the object's implementation. > It also doesn't require the existence of a grand and glorious single > universal interface repository. I would like to point out that there are operations on Object that are not serviced by the object implementation or the orb hosting the object, so merely putting an operation on Object doesn't mean a hill of beans. Indeed implementation of Object::get_policy for one of the Security administrative policy types may require considerable jumping through hoops in the client ORB and depending on the design of the Domain Management infrastructure, may not involve the ORB hosting the target object at all. The fact that get_interface is served by the ORB hosting the target object is true after we completed bickering about which of the implicit operations are actually carried as implicit operations on the GIOP wire. It turns out that people made the right decision regarding get_interface, but it could equally have gone the other way. It is because people wanted to get the right answer that it was prudently decided to carry _interface on the wire. Similarly one could specify that get_required_rights shall go to the RequiredRights manager on the ORB whence the object reference came from to get the RR object. Not always very efficient but hay semantically that is what we need. Now if there were a RequriedRights manager interface behind which one could do some clever caching and stuff, then that'd be cool too. So at least in spirit you essentially have what someone suggested Object::required_rights, but the interface is designed in such a way that the provider of the RR stuff is relatively decoupled from the provider of the abse ORB. This of course does not preclude an ORB vendor from doing their own RR manager. Please not that I am using RR manager almost as a place holder to talk about a particular design pattern here. > With a RequiredRightsManager I don't *currently* see how to get the same > benefits. How would a client and server agree on a common > RequiredRightsManager? (Since a client may be talking to several > servers, it is quite possible that there is no one manager that will be > shared in common with all the servers.) See above. > This wouldn't be such a problem if confined to the server side. But on > the server side it isn't clear that the RequiredRightsManager is needed > at all - it is probably better to find a way for the orb to directly > provide the security service with the required rights of the operation > being authenticated. That would be cool as far as I am concerned, but the vendors who want to provide a RequiredRights management service on several ORBs might be a bit miffed if a replaceability interface between the ORB and the RequiredRights manager were not specified.:-) Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Date: Wed, 18 Aug 1999 12:52:01 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Paul H Kyzivat CC: Bob Blakley , Polar Humenn , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Paul H Kyzivat wrote: > > Bob Blakley wrote: > > > > >In POA parlance the triplet uniquely > > >identify an object instance of a specific > > >type. The issue there is how is this to be made visible/accessible to > > >the programmers of security service. > > Just to clarify > > - Rep_id does not enter into this. It can be *derived* from the > servant selected with , so it is a dependent > variable, not an independent one. > - only uniquely identifies > the servant/object instance in the context of a particular server. You're of course right. That was my dyslexia. > > Exactly. In particular, what piece of IDL-specifiable and > > ORB-application-accessible > > information represents the target object instance? > > All the orb/poa can do is select a servant based on . > >From the orb's point of view, identify the > target object instance. (Servant alone isn't sufficient, because the > same servant can simultaneously service many pairs.) Paul, maybe you can help a lot here. I get this feeling that many of us do not have a clear understanding of the different possible configurations/realtionships among POA, Servant, Target Object etc. that can exist. my understanding is that the nature of the relationship is determined by certain set of POA policies. Would it be possible to enumerate all possibilities, and first of all convince ourselves that all combinations are actually ma=eaningfully securable? Then we can use the same enumeration to figure out what would be the meaning of "instance" and where would be the right place to do the "domain manager association". It seems to me that for certain POA policy combinations the POA may be able to do it while for others we will have to go deep into the target object. Am I simply competely wet behind my ears in believing this? > > My intuition is the information needed to support 5 and 5a is > > accessible to > > POA implementors, because they need to be able to figure out which > > method's code to invoke and where to get that code. Given this, it > > seems reasonable to me to ask the POA implementation to implement > > the "requiredRights" interface, because it's the only thing which > > should be guaranteed to have this information. Hence I've suggested > > that requirement 6 be met by requiring POAs to implement > > requiredRights. > > Be careful talking about the POA as an identifiable entity distinct from > the ORB implementation, and from the orb specific generated code. There > are probably many ways to partition responsibility. > > The POA can find the servant, but it is the servant that knows what > interface(s) it implements, so it is the one that might be expected to > know the required rights for a particular operation. Perhaps the POA (or > some part of the ORB) could serve as an intermediary by obtaining this > information from the servant and passing it to the security service. > > In the case of DSI, the only currently available hook in the servant is > provided_interface. This would then require some sort of lookup to get > required_rights. With static skeletons it would be nice to be able to > compile the required rights in and avoid the lookup. > > Supporting 5a implies that the required rights *cannot* be compiled in, > but rather must be dynamically looked up in some changeable database. > Depending on how quickly such changes must be visible, this can impose a > huge cost. It needs to be carefully investigated. Given the enromous amount of info that a Servent houses, it appears to me that the currently specified Servent interface in the C++ and Java language mapping is woefully inadequate to do many of these things without using under the hood extensions. Am I way off base in thinking this way? Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Wed, 18 Aug 1999 16:50:25 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Polar Humenn CC: Jishnu Mukerji , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > I see this RequiredRights (Repository??) as tacked onto a Domain. > So then objects are in a required rights domain. The RR can be gotten > off of the get_domain_managers call. Onto (one of) the same domain(s) that the objects being secured belong to? Or in some other kind of domain altogether? (Actually, I am not even sure we actually have domains; maybe we only have domain managers. So maybe there is no such thing as domain identity.) Anyway, how would tacking a RR (RRR?) onto a domain help me to choose the right one to use in any given situation. Can you explain your idea further? Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Paul H Kyzivat" , "Polar Humenn" Cc: "Jishnu Mukerji" , , "William Pope" Subject: Re: AccessDecision object Date: Wed, 18 Aug 1999 16:06:17 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 Paul >> I see this RequiredRights (Repository??) as tacked onto a Domain. >> So then objects are in a required rights domain. The RR can be gotten >> off of the get_domain_managers call. > >Onto (one of) the same domain(s) that the objects being secured belong >to? Or in some other kind of domain altogether? Some other kind of domain; otherwise you'll run into problems with self-reference. >(Actually, I am not even sure we actually have domains; maybe we only >have domain managers. So maybe there is no such thing as domain >identity.) I guess I'd claim that we have domains in exactly the same sense that we have objects. >Anyway, how would tacking a RR (RRR?) onto a domain help me to choose >the right one to use in any given situation. Can you explain your idea >further? --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom Date: Wed, 18 Aug 1999 17:09:45 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jishnu Mukerji CC: Polar Humenn , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Jishnu Mukerji wrote: > > I would like to point out that there are operations on Object that are > not serviced by the object implementation or the orb hosting the > object, so merely putting an operation on Object doesn't mean a hill > of beans. I agree that putting the operation on Object doesn't guarantee it will be served by the object's implementation. But *not* putting it on Object comes close to guaranteeing that it *won't* be served by the object's implementation. > Indeed implementation of Object::get_policy for one of the > Security administrative policy types may require considerable jumping > through hoops in the client ORB and depending on the design of the > Domain Management infrastructure, may not involve the ORB hosting > the target object at all. > > The fact that get_interface is served by the ORB hosting the target > object is true after we completed bickering about which of the > implicit operations are actually carried as implicit operations on > the GIOP wire. > It turns out that people made the right decision regarding > get_interface, but it could equally have gone the other way. It is > because people wanted to get the right answer that it was prudently > decided to carry _interface on the wire. People can always do the wrong thing. Hopefully we are trying to do the right thing with required rights. > Similarly one could specify > that get_required_rights shall go to the RequiredRights manager on the > ORB whence the object reference came from to get the RR object. I suppose we could specify this, but without *some* new (on the wire) operation on Object, how can I find "the XXX on the ORB whence the object reference came"? > Not always very efficient but hay semantically that is what we need. > Now if there were a RequriedRights manager interface behind which one > could do some clever caching and stuff, then that'd be cool too. Some care is needed or else the option of caching will be legislated away. > So at least in spirit you essentially have what someone suggested > Object::required_rights, but the interface is designed in such a way > that the provider of the RR stuff is relatively decoupled from the > provider of the abse ORB. This of course does not preclude an ORB > vendor from doing their own RR manager. I can see some merit in devising a way to find "the XXX on the ORB whence the object reference came", and then using it as an extensibility mechanism for all sorts of things. It is somewhat similar to the (now rejected) resolve_initial_references_remote function. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 18 Aug 1999 17:16:02 -0400 (EDT) From: Polar Humenn To: Paul H Kyzivat cc: Jishnu Mukerji , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Wed, 18 Aug 1999, Paul H Kyzivat wrote: > Polar Humenn wrote: > > > > I see this RequiredRights (Repository??) as tacked onto a Domain. > > So then objects are in a required rights domain. The RR can be gotten > > off of the get_domain_managers call. > > Onto (one of) the same domain(s) that the objects being secured belong > to? Or in some other kind of domain altogether? > > (Actually, I am not even sure we actually have domains; maybe we only > have domain managers. So maybe there is no such thing as domain > identity.) > > Anyway, how would tacking a RR (RRR?) onto a domain help me to choose > the right one to use in any given situation. Can you explain your idea > further? The domain (or domain manager) gives an object scope, does it not? (I would hope so). So, if an object belongs to a particular "access" domain. (Please, let's leave out the dicussion about multiple domain managers, and multiple policies of the same type for now). Currently, I think this means it has a domain manager that points to an AccessPolicy. Any object that has this domain manager (or a different domain manager with the same AccessPolicy object) is effectively governed by the same scope for AccessPolicy. Why should this not be the case with RR? The RRRepository can be a "Policy" object that is associated with a domain manager. The RRR can have a much wider scope than the particular access policy, but the domain manager (which is handled by get_domain_managers) yields a handle on which to provide the scope of RR for objects. That is all. Now, how an object becomes a member of a domain, what the definition of a domain actually is, is up to the Domain Mgmt RFP submission, of which I have not had time to look at in detail. I might on the plane. ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 18 Aug 1999 17:34:58 -0400 (EDT) From: Polar Humenn To: Bob Blakley cc: Paul H Kyzivat , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Wed, 18 Aug 1999, Bob Blakley wrote: > Paul > > >> I see this RequiredRights (Repository??) as tacked onto a Domain. > >> So then objects are in a required rights domain. The RR can be gotten > >> off of the get_domain_managers call. > > > >Onto (one of) the same domain(s) that the objects being secured belong > >to? Or in some other kind of domain altogether? > > Some other kind of domain; otherwise you'll run into problems with > self-reference. > > >(Actually, I am not even sure we actually have domains; maybe we only > >have domain managers. So maybe there is no such thing as domain > >identity.) > > I guess I'd claim that we have domains in exactly the same sense that we have > objects. Oh no we won't! :) I sincerely hope that we can get a handle of identity on domains. Domain Managers can be objects, but the domains they manage, better have names (identities). Otherwise management of them would be futile. I still have a problem figuring out this concept of multiple domain managers. I believe the fact, if I can remember why, we chose multiple domain managers. First we chose Domain "Manager" because "Domain" was too overloaded. Also, for the multiple part it is because we wanted the possibility of an object residing in multiple domains. So, we just made it plural. I still have a problem with this. Say we have two objects O1 with DomainManager DM1 and O2 with DomainManager DM2. Say both DM1 and DM2 have AP1 for an AccessPolicy. O1, O2, DM1, DM2, and AP1 are all different object implemenations/instances. My ultimate question is, since DM1 and DM1 point to AP1 for and AccessPolicy, are the objects, O1 and O2 in the same "access" domain. Mathematically speaking I would say emphatically, YES. And the DomainManager doesn't represent a domain at all. Now, if a "DomainManager" implies a certain empoweredness over a collection of objects, then I have a problem with this model. The "admin" of DM1 can certainly switch the AccessPolicy. But the AccessPolicy has an "admin" component to it as well. Take DomainAccessPolicy, in which an interface exists to change the policy. Now, who is in charge of the "domain"? This diatribe is, just food for thought. ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 18 Aug 1999 17:43:30 -0400 (EDT) From: Polar Humenn To: Paul H Kyzivat cc: Jishnu Mukerji , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Wed, 18 Aug 1999, Paul H Kyzivat wrote: > Jishnu Mukerji wrote: > > > > I would like to point out that there are operations on Object that are > > not serviced by the object implementation or the orb hosting the > > object, so merely putting an operation on Object doesn't mean a hill > > of beans. > > I agree that putting the operation on Object doesn't guarantee it will > be served by the object's implementation. But *not* putting it on Object > comes close to guaranteeing that it *won't* be served by the object's > implementation. > > > Indeed implementation of Object::get_policy for one of the > > Security administrative policy types may require considerable jumping > > through hoops in the client ORB and depending on the design of the > > Domain Management infrastructure, may not involve the ORB hosting > > the target object at all. > > > > The fact that get_interface is served by the ORB hosting the target > > object is true after we completed bickering about which of the > > implicit operations are actually carried as implicit operations on > > the GIOP wire. > > It turns out that people made the right decision regarding > > get_interface, but it could equally have gone the other way. It is > > because people wanted to get the right answer that it was prudently > > decided to carry _interface on the wire. > > People can always do the wrong thing. Hopefully we are trying to do the > right thing with required rights. Jishnu, is this "on the wire" a part of GIOP as well for "get_domain_managers")? Is it decided on? BTW, is it "_domain_managers" on the wire? (Sorry in advance, I haven't pulled up that part of the spec in a while). > > Similarly one could specify > > that get_required_rights shall go to the RequiredRights manager on the > > ORB whence the object reference came from to get the RR object. > > I suppose we could specify this, but without *some* new (on the wire) > operation on Object, how can I find "the XXX on the ORB whence the > object reference came"? That's why I suggest tacking in on a DomainManager. > > Not always very efficient but hay semantically that is what we need. > > Now if there were a RequriedRights manager interface behind which one > > could do some clever caching and stuff, then that'd be cool too. > > Some care is needed or else the option of caching will be legislated > away. I'd rather see some kind of frame work in which notification and/or policy description updating can be worked the access decision mechanism of the particular server (since we actually have that distinction so far). > > So at least in spirit you essentially have what someone suggested > > Object::required_rights, but the interface is designed in such a way > > that the provider of the RR stuff is relatively decoupled from the > > provider of the abse ORB. This of course does not preclude an ORB > > vendor from doing their own RR manager. > > I can see some merit in devising a way to find "the XXX on the ORB > whence the object reference came", and then using it as an extensibility > mechanism for all sorts of things. It is somewhat similar to the (now > rejected) resolve_initial_references_remote function. Lost me there. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Polar Humenn" Cc: "Paul H Kyzivat" , "Jishnu Mukerji" , , "William Pope" Subject: Re: AccessDecision object Date: Wed, 18 Aug 1999 16:46:04 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 >> I guess I'd claim that we have domains in exactly the same sense that we have >> objects. > >Oh no we won't! :) I was using present tense, and I think it's clear that we *do*, because while you can "refer" to domains (by naming a domain manager), there's not really a domain object which would be the result of dereferencing. >I sincerely hope that we can get a handle of identity on domains. Domain >Managers can be objects, but the domains they manage, better have names >(identities). Otherwise management of them would be futile. > >I still have a problem figuring out this concept of multiple domain >managers. > >I believe the fact, if I can remember why, we chose multiple domain >managers. First we chose Domain "Manager" because "Domain" was too >overloaded. Nope. We chose to define domain managers but not domains because while it was clearly necessary to figure out, given an object, which domain it was in (because you've got to be able to retrieve the policy and to manage it), it was NOT clearly necessary, given a domain, to be able to enumerate its members. Hence we avoided putting something in the spec. which would require implementation of a domain as a collection (because this might have caused performance or scale problems), or in fact which would require implementation of domains at all. >Also, for the multiple part it is because we wanted the >possibility of an object residing in multiple domains. So, we just made it >plural. This is correct. We >I still have a problem with this. Say we have two objects O1 with >DomainManager DM1 and O2 with DomainManager DM2. Say both DM1 and DM2 have >AP1 for an AccessPolicy. O1, O2, DM1, DM2, and AP1 are all different >object implemenations/instances. > >My ultimate question is, since DM1 and DM1 point to AP1 for and >AccessPolicy, are the objects, O1 and O2 in the same "access" domain. Nope. They're in different domains with the same policy. Why is this difficult? Directories do it all the time. I put an ACL on the directory root. Now I have a bunch of objects (files, for example) which are in a bunch of subdirectories -- all different -- but all of which have the same policy. Now (later) I put an ACL on a subdirectory. I now have a bunch of objects which are in a different domain (but the same domain they were in before) and which have a *different* policy. >Mathematically speaking I would say emphatically, YES. And the >DomainManager doesn't represent a domain at all. Nope. The domain manager represents a domain. It is just a domain which is *at the present time* policy-equivalent to another domain. >Now, if a "DomainManager" implies a certain empoweredness over a >collection of objects, then I have a problem with this model. > >The "admin" of DM1 can certainly switch the AccessPolicy. > >But the AccessPolicy has an "admin" component to it as well. Take >DomainAccessPolicy, in which an interface exists to change the policy. > >Now, who is in charge of the "domain"? This is something I was supposed to raise an issue about: domain managers are supposed to have owners; ownership of a domain determines who can change the domain's policy. >This diatribe is, just food for thought. --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom Sender: jis@fpk.hp.com Date: Wed, 18 Aug 1999 18:01:06 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Polar Humenn CC: Paul H Kyzivat , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > On Wed, 18 Aug 1999, Paul H Kyzivat wrote: > > > Jishnu Mukerji wrote: > > > > > > I would like to point out that there are operations on Object that are > > > not serviced by the object implementation or the orb hosting the > > > object, so merely putting an operation on Object doesn't mean a hill > > > of beans. > > > > I agree that putting the operation on Object doesn't guarantee it will > > be served by the object's implementation. But *not* putting it on Object > > comes close to guaranteeing that it *won't* be served by the object's > > implementation. > > > > > Indeed implementation of Object::get_policy for one of the > > > Security administrative policy types may require considerable jumping > > > through hoops in the client ORB and depending on the design of the > > > Domain Management infrastructure, may not involve the ORB hosting > > > the target object at all. > > > > > > The fact that get_interface is served by the ORB hosting the target > > > object is true after we completed bickering about which of the > > > implicit operations are actually carried as implicit operations on > > > the GIOP wire. > > > It turns out that people made the right decision regarding > > > get_interface, but it could equally have gone the other way. It is > > > because people wanted to get the right answer that it was prudently > > > decided to carry _interface on the wire. > > > > People can always do the wrong thing. Hopefully we are trying to do the > > right thing with required rights. > > Jishnu, is this "on the wire" a part of GIOP as well for > "get_domain_managers")? Is it decided on? BTW, is it "_domain_managers" on > the wire? (Sorry in advance, I haven't pulled up that part of the spec in > a while). Yes, _get_domain_managers is a special GIOP thingy, like _interface and _is_a, and the infamous _non_exixtent. > > > Similarly one could specify > > > that get_required_rights shall go to the RequiredRights manager on the > > > ORB whence the object reference came from to get the RR object. > > > > I suppose we could specify this, but without *some* new (on the wire) > > operation on Object, how can I find "the XXX on the ORB whence the > > object reference came"? Indeed there is a bit of an outage there isn't it? > That's why I suggest tacking in on a DomainManager. > > > > Not always very efficient but hay semantically that is what we need. > > > Now if there were a RequriedRights manager interface behind which one > > > could do some clever caching and stuff, then that'd be cool too. > > > > Some care is needed or else the option of caching will be legislated > > away. > > I'd rather see some kind of frame work in which notification and/or policy > description updating can be worked the access decision mechanism of the > particular server (since we actually have that distinction so far). ?????? > > > So at least in spirit you essentially have what someone suggested > > > Object::required_rights, but the interface is designed in such a way > > > that the provider of the RR stuff is relatively decoupled from the > > > provider of the abse ORB. This of course does not preclude an ORB > > > vendor from doing their own RR manager. > > > > I can see some merit in devising a way to find "the XXX on the ORB > > whence the object reference came", and then using it as an extensibility > > mechanism for all sorts of things. It is somewhat similar to the (now > > rejected) resolve_initial_references_remote function. Coming to think of it, I think so too. Hmmmm need to think a bit more about this one. > > Lost me there. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Date: Wed, 18 Aug 1999 18:18:41 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Polar Humenn CC: Bob Blakley , Paul H Kyzivat , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > On Wed, 18 Aug 1999, Bob Blakley wrote: > > > Paul > > > > >> I see this RequiredRights (Repository??) as tacked onto a Domain. > > >> So then objects are in a required rights domain. The RR can be gotten > > >> off of the get_domain_managers call. > > > > > >Onto (one of) the same domain(s) that the objects being secured belong > > >to? Or in some other kind of domain altogether? > > > > Some other kind of domain; otherwise you'll run into problems with > > self-reference. > > > > >(Actually, I am not even sure we actually have domains; maybe we only > > >have domain managers. So maybe there is no such thing as domain > > >identity.) > > > > I guess I'd claim that we have domains in exactly the same sense that we have > > objects. > > Oh no we won't! :) Maybe, but right now we do.:-) There are references to things called domain managers which are the only worldly representatives of these etherial things called domains.:-) > I sincerely hope that we can get a handle of identity on domains. Domain > Managers can be objects, but the domains they manage, better have names > (identities). Otherwise management of them would be futile. Just because something is given an identity doesn't necessarily mean that anything other than the identity is there:-). For example, the identity of a domain could just be associated with the domain manager that associates members of the domain with the policy associated with the domain, and that's it ... just an additional identity attribute added to a domain manager. > I still have a problem figuring out this concept of multiple domain > managers. > > I believe the fact, if I can remember why, we chose multiple domain > managers. First we chose Domain "Manager" because "Domain" was too > overloaded. Also, for the multiple part it is because we wanted the > possibility of an object residing in multiple domains. So, we just made it > plural. But if there are different domains of different extent associating different classes of policies with different sets of object references, wouldn't you require different domain managers, one for each domain? At least given the way domain managers are defined today I believe that would be the case. > I still have a problem with this. Say we have two objects O1 with > DomainManager DM1 and O2 with DomainManager DM2. Say both DM1 and DM2 have > AP1 for an AccessPolicy. O1, O2, DM1, DM2, and AP1 are all different > object implemenations/instances. > > My ultimate question is, since DM1 and DM1 point to AP1 for and > AccessPolicy, are the objects, O1 and O2 in the same "access" domain. If you placed them in different domains for whatever reason they are in different domains. By placing them in different domains, I strictly mean associating different domain managers with them. It is a separate matter that you happened to associate the same access policy with both domain managers. > Mathematically speaking I would say emphatically, YES. And the > DomainManager doesn't represent a domain at all. After you have done some number crunching or logic crunching based on your understanding of what the policies mean etc, you could come to a conclusion like that, but the use of the word "domain" is different in your conclusion from its use in the premise of the discussion. The use of the word "domain" in the premise is to refer to the purely mechanistic concept as defined by a domain manager in CORBA. The use of the same word in the conclusion appears to have more to do with an abstract mathametical concept. As we all know mixing metaphors can be entertaining. > Now, if a "DomainManager" implies a certain empoweredness over a > collection of objects, then I have a problem with this model. > > The "admin" of DM1 can certainly switch the AccessPolicy. > > But the AccessPolicy has an "admin" component to it as well. Take > DomainAccessPolicy, in which an interface exists to change the policy. > > Now, who is in charge of the "domain"? That is a legitimate missing part and that should legitimately be fixed. This is something that should be pointed out to the Domain Manager RFP submitters. > This diatribe is, just food for thought. Fed it to thoughts:-). Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Wed, 18 Aug 1999 18:33:22 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jishnu Mukerji CC: Bob Blakley , Polar Humenn , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Jishnu Mukerji wrote: > > Paul, maybe you can help a lot here. I get this feeling that many of > us do not have a clear understanding of the different possible > configurations/realtionships among POA, Servant, Target Object etc. > that can exist. my understanding is that the nature of the > relationship is determined by certain set of POA policies. > Would it be possible to enumerate all possibilities, and first of > all convince ourselves that all combinations are actually > meaningfully securable? Then we can use > the same enumeration to figure out what would be the meaning of > "instance" and where would be the right place to do the "domain > manager association". It seems to me that for certain POA policy > combinations the POA may be able to do it while for others we will > have to go deep into the target object. Am I simply competely wet > behind my ears in believing this? I will try: - It is a little hard to talk about what an object reference contains since only IORs are standardized. I will talk as if object references and IORs are equivalent. - in a POA based orb, all object references are created by POAs, at the request of the implementation code in the server. The poa requires two pieces of information to create an object reference - an ObjectId and a RepositoryId. These two pieces of information must be encoded in the object reference. In addition, the identification of the POA creating the reference and the server containing the POA must be encoded in the reference. The ObjectId and the identification of the POA both need to be encoded in the portion of the object reference called the Key, but the manner of encoding this information is not, and need not, be standardized. (The POA can also put whatever else it wants into the key.) There are well defined places within the IOR for the repositoryId and the server identification (address). - when a client invokes on an object reference, the client uses the addressing information identifying the server in order to send the request to it. The remaining information (the key) is passed back to the server - the client need not understand it. It is important to note that normally only the key from the IOR is passed in the request. The remainder is normally not sent. (Prior to giop 1.2 there was no way to send it. Starting in 1.2 it can now be sent optionally.) - in a POA based orb, the key from the incoming request must first be decoded to determine which POA it is addressed to, and which ObjectId within that POA. - next, the POA must decide what servant (if any) is to service the request. This is the part that is driven by POA Policies. Without getting into the details of the policies, the following is probably sufficient for this discussion: * the POA may select (based on the ObjectId) from a number of Servants that it has previously been told about. * the mapping from ObjectId to Servant need not be unique - the same Servant may service multiple ObjectIds. In this case the Servant may explicitly access the ObjectId to decide what "real object" to operate on. * the POA may need to call a separate ServantManager (an inplementation provided piece of code - locally constrained) to locate the Servant to use. * in many (most) cases, requests for the same POA/ObjectId will be directed to the same Servant even if they come from different clients (with different security attributes). * Under some policies a ServantManager is called to find a Servant for each and every request. In this case it is possible for two calls to the same POA/ObjectId to be *simultaneously* serviced by different Servants. - If no servant is found, the request fails. - Having found the Servant, the POA still has no idea what type it is. And even though the object reference contained the RepositoryId, this is not normally present in the request. (In any case there is no guarantee that it would match the Servant.) - The request contains the name of the operation, but in order for the POA to unmarshal the arguments it must first discover the signature of the operation. It must cooperate with the Servant in order to do this. In the case of a DSI servant it can call provided_interface and then work from that. In other cases the manner of doing this is proprietary. - After the arguments are unmarshalled, the method on the servant can be called. Somewhere before this point the security checking must have been done. - There is no prohibition against using the same Servant in multiple POAs concurrently. The implications of all of this on security aren't entirely clear to me because I still don't fully understand what expections there are. The following are probably important: - Within the server, the closest thing to a designation of a distinct target object is [POA,ObjectID]. Object references created with the same pair of these are indistinguishable by the server. - Servant is not useful for identifying target objects. But it is necessary for determining the MDI or other information about the target operation, like Required Rights. > Given the enromous amount of info that a Servent houses, it appears to > me that the currently specified Servent interface in the C++ and Java > language mapping is woefully inadequate to do many of these things > without using under the hood extensions. Am I way off base in thinking > this way? I don't know. I am not sure I understand what mean by the question. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 18 Aug 1999 18:49:26 -0400 (EDT) From: Polar Humenn To: Bob Blakley cc: Paul H Kyzivat , Jishnu Mukerji , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Wed, 18 Aug 1999, Bob Blakley wrote: > >> I guess I'd claim that we have domains in exactly the same sense that we > have > >> objects. > > > >Oh no we won't! :) > > I was using present tense, and I think it's clear that we *do*, because while > you can "refer" to domains (by naming a domain manager), there's not > really a domain object which would be the result of dereferencing. > > >I sincerely hope that we can get a handle of identity on domains. Domain > >Managers can be objects, but the domains they manage, better have names > >(identities). Otherwise management of them would be futile. > > > >I still have a problem figuring out this concept of multiple domain > >managers. > > > >I believe the fact, if I can remember why, we chose multiple domain > >managers. First we chose Domain "Manager" because "Domain" was too > >overloaded. > > Nope. We chose to define domain managers but not domains because while > it was clearly necessary to figure out, given an object, which domain it was > in (because you've got to be able to retrieve the policy and to manage it), > it was NOT clearly necessary, given a domain, to be able to enumerate its > members. Hence we avoided putting something in the spec. which would > require implementation of a domain as a collection (because this might have > caused performance or scale problems), or in fact which would require > implementation of domains at all. > > >Also, for the multiple part it is because we wanted the > >possibility of an object residing in multiple domains. So, we just made it > >plural. > > This is correct. We > > >I still have a problem with this. Say we have two objects O1 with > >DomainManager DM1 and O2 with DomainManager DM2. Say both DM1 and DM2 have > >AP1 for an AccessPolicy. O1, O2, DM1, DM2, and AP1 are all different > >object implemenations/instances. > > > >My ultimate question is, since DM1 and DM1 point to AP1 for and > >AccessPolicy, are the objects, O1 and O2 in the same "access" domain. > > Nope. They're in different domains with the same policy. Why is this > difficult? Because the access policy is not an object it's an object reference. > Directories do it all the time. I put an ACL on the directory root. > Now I have a bunch of objects (files, for example) which are in a > bunch of subdirectories -- all different -- but all of which have the > same policy. Now (later) I put an ACL on a subdirectory. Okay, we'll assume a Directory is synonomous with a DomainManager (I guess, in DFS/Andrew File System). > I now have > a bunch of objects which are in a different domain (but the same > domain they were in before) and which have a *different* policy. Doesn't explain my problem with the current model. If all those files where indeed in the same "access" domain, and I modify the ACL then they are all affected, fine, those files and subdirectories are all in the same domain. That is, they are governed by the AccessPolicy of their "enclosing" domain manager. Maybe this is where we are having the problem. First of all the subdirectory, doesn't have an ACL associated with it, so it uses the ACL of its parent directory. This situation is analogous to getting the AccessPolicy object reference from the object's domain manager's domain manager, correct? I'm fine with that, because the policy is not explicitly shared between actual DomainManager objects. The domain is implied because of this heirarchy we have placed on domain managers. Now, if you take the following scenario. If we have an Andrew file system and I place an ACL on directory D1. Then for some reason, I create a new directory D2 and I want the same ACL to govern D2. (I don't even know if an operation like this exists), but I must COPY the ACL, not reference it. Hmmm, so this kind of thing has a small difference. That ACL is COPIED. So if the orignal ACL is changed on D1 it doesn't change the other on D2. This is not the same thing as two DomainManagers "sharing" the AccessPolicy object. It's okay for them to share the same access "policy", but it is really okay for them to share the same AccessPolicy objects? The problem is what is the scope of the management? I say it should be at the "domain" of course. But I don't know whether that really implies whether it is at the DomainManager object, or the AccessPolicy object. > >Mathematically speaking I would say emphatically, YES. And the > >DomainManager doesn't represent a domain at all. > > Nope. The domain manager represents a domain. It is just a domain which is > *at the present time* policy-equivalent to another domain. > > >Now, if a "DomainManager" implies a certain empoweredness over a > >collection of objects, then I have a problem with this model. > > > >The "admin" of DM1 can certainly switch the AccessPolicy. > > > >But the AccessPolicy has an "admin" component to it as well. Take > >DomainAccessPolicy, in which an interface exists to change the policy. > > > >Now, who is in charge of the "domain"? > > This is something I was supposed to raise an issue about: domain managers are > supposed to have owners; ownership of a domain determines who can change > the domain's policy. The owner concept applies to the domain or a domain manager? I'm sorry for bringing all this up, but when you try to look at this stuff with some formal reasoning (yeah, I know, the evil terms of mathematics and formal methods), instead of a bunch of nuts and bolts thrown together in a bucket, all this stuff starts rising to the surface. So, if administration is suppose to be with the domain manager. Then I would say that Policies should have a real copy operation. I know they do have a copy() operation, but it is insufficient because it doesn't state how the "ownership" will work. If I were a domain manager and I wanted to "use" another domain managers AccessPolicy object, I would copy it, but I would want the "beef" of the policy object under MY control, not possibly in some other server somewhere. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: "Martin Chapman" To: "Gene Jarboe" , "Paul H Kyzivat" Cc: "Bob Blakley" , "Jishnu Mukerji" , "Polar Humenn" , , "William Pope" , "Steve Vinoski" , "Bob Kukura" Subject: RE: AccessDecision object Date: Thu, 19 Aug 1999 11:02:35 +0100 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal Gene, You always get the wrong end of the stick :-) :-) I wasn't suggesting to stop this converstation, mearly pointing out that it seems to be going out of scope for an RTF. There is a lot of RTF work to be done (129 issues I think,) and I think we need to have a decision to this issue (either to drop it or solve it) quite quickly. If it is dropped, the discussion should then take place in SecSIG. Martin. > -----Original Message----- > From: Gene Jarboe [mailto:gjarboe@promia.com] > Sent: 18 August 1999 15:12 > To: Paul H Kyzivat; Martin Chapman > Cc: Bob Blakley; Jishnu Mukerji; Polar Humenn; sec-rev@omg.org; William > Pope; Steve Vinoski; Bob Kukura > Subject: Re: AccessDecision object > > > Paul Kyzivat and et al., > > WRT to the included messages below: > > IMHO and speaking on behave of my company, I agree with Paul Kyzivat > that the > security related discussions ongoing on this thread is VERY IMPORTANT to > those of us > OMG member companies that trying to understand the far ranging > requirements, > issues, proposals, and solutions from the various original authors and > revision experts WRT to > the CORBASec standard. Therefore, PLEASE CONTINUE these emails unless as > Paul > suggests that "if enough people object, the discussion could become a > private one." > > I also agree that eventually there should be a new RFP for those > requirements that > are deemed not part of the security RTF. > > Gene Jarboe > > Paul H Kyzivat wrote: > > Martin Chapman wrote: > > > > > > Guys, > > > > > > I'm really confused by this thread. > > > I'm not disagreeing with the requirments, and some of the proposals > > > may make sense, but imho it is way out of scope for this RTF to be > > > doing this. > > > Issue a new RFP (if not already covered by the extant ones) to solve > > > this. > > > > At the moment this is just a far ranging discussion. > > It doesn't seem to me that it is out of scope to have the discussion. > > I agree it is likely that many possible resolutions will be out of scope > > for an RTF and will indeed require an RFP, but we won't know that for > > sure until we reach some conclusion in these discussions. (Maybe the > > conclusion will be that we need to issue an RFP.) > > > > But until then, this seems like a forum involving people with the right > > set of interests. Of course, if enough people object, the discussion > > could become a private one. > From: "Gene Jarboe" To: "Martin Chapman" , "Paul H Kyzivat" Cc: "Bob Blakley" , "Jishnu Mukerji" , "Polar Humenn" , , "William Pope" , "Steve Vinoski" , "Bob Kukura" Subject: Re: AccessDecision object Date: Thu, 19 Aug 1999 08:05:23 -0400 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Martin, What this wrong end of the stick stuff? :-)) My company and I agree WRT issues and RTF. Gene ----- Original Message ----- From: Martin Chapman To: Gene Jarboe ; Paul H Kyzivat Cc: Bob Blakley ; Jishnu Mukerji ; Polar Humenn ; ; William Pope ; Steve Vinoski ; Bob Kukura Sent: Thursday, August 19, 1999 6:02 AM Subject: RE: AccessDecision object > Gene, > > You always get the wrong end of the stick :-) :-) > > I wasn't suggesting to stop this converstation, mearly pointing out that it > seems to be going out of scope for an RTF. > There is a lot of RTF work to be done (129 issues I think,) and I think we > need to have a decision to this issue (either to drop it or solve it) quite > quickly. If it is dropped, the discussion should then take place in SecSIG. > > Martin. Date: Thu, 19 Aug 1999 09:08:49 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Polar Humenn CC: Jishnu Mukerji , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > > > Similarly one could specify > > > that get_required_rights shall go to the RequiredRights manager on > > > the ORB whence the object reference came from to get the RR > > > object. > > > > I suppose we could specify this, but without *some* new (on the > > wire )operation on Object, how can I find "the XXX on the ORB > > whence the object reference came"? > > That's why I suggest tacking in on a DomainManager. I think I am finally starting to understand what you are thinking: A client that wants to know required rights of a particular operation on a particular object: - uses get_domain_managers on the object to get a RequiredRightsManager. - uses the RequiredRightsManager to get a RequiredRights object. - uses the RequiredRights object to look up the required rights for the interface the client thinks the object is, and the desired operation. Hopefully the orb where the object is implemented deals with the get_domain_managers and provides as a RequiredRightsManager a reference implemented by its RequiredRightsRepository server. Then, as long as the RequiredRightsRepository and the ORB are implemented as a unit, there can be collusion between them on the server side to ensure an optimized path for access checking on the server side. > I'd rather see some kind of frame work in which notification and/or > policy description updating can be worked the access decision > mechanism of the particular server (since we actually have that > distinction so far). Like Jishnu, I don't understand what you mean here. Date: Thu, 19 Aug 1999 09:16:23 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jishnu Mukerji CC: Polar Humenn , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Jishnu Mukerji wrote: > > > > I suppose we could specify this, but without *some* new (on the > > > wire) operation on Object, how can I find "the XXX on the ORB > > > whence the object reference came"? > > Indeed there is a bit of an outage there isn't it? > > > I can see some merit in devising a way to find "the XXX on the ORB > > > whence the object reference came", and then using it as an > > > extensibility mechanism for all sorts of things. > > Coming to think of it, I think so too. Hmmmm need to think a bit more > about this one. See my last reply to Polar. Thinking about it, it seems like perhaps get_domain_managers may serve this purpose. It is more of a "find the XXX prefered by the ORB whence the object reference came". Whether it is actually *on* that orb is up to the orb itself to decide. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 19 Aug 1999 09:42:55 -0400 (EDT) From: Polar Humenn To: Paul H Kyzivat cc: Jishnu Mukerji , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Thu, 19 Aug 1999, Paul H Kyzivat wrote: > Polar Humenn wrote: > > > > > > Similarly one could specify > > > > that get_required_rights shall go to the RequiredRights manager on > > > > the ORB whence the object reference came from to get the RR > > > > object. > > > > > > I suppose we could specify this, but without *some* new (on the > > > wire )operation on Object, how can I find "the XXX on the ORB > > > whence the object reference came"? > > > > That's why I suggest tacking in on a DomainManager. > > I think I am finally starting to understand what you are thinking: > > A client that wants to know required rights of a particular operation on > a particular object: > > - uses get_domain_managers on the object to get a RequiredRightsManager. > - uses the RequiredRightsManager to get a RequiredRights object. > - uses the RequiredRights object to look up the required rights for > the interface the client thinks the object is, and the desired > operation. > > Hopefully the orb where the object is implemented deals with the > get_domain_managers and provides as a RequiredRightsManager a reference > implemented by its RequiredRightsRepository server. > > Then, as long as the RequiredRightsRepository and the ORB are > implemented as a unit, there can be collusion between them on the server > side to ensure an optimized path for access checking on the server side. Something like that, yes, I'd probably go with out the indirection of the RequiredRightsManager to the RequiredRights object, and just get a reference to something that can get me the required rights I'm asking for. In any case, lets not really worry about the client side just yet. We still can't figure out how the server side can work just yet. The reason is this, the client can call "get_domain_managers" and get the thingy that returns required rights interfaces and operations in that "required rights domain". However, the client *still* needs to know the MDI of the object in question to get a good answer. There is still now way for a client to know that. But in any case, I believe there should be a scope to this required rights thingy, and I see a domain or a domain manager as something along those ways of accomplishing scope. > > I'd rather see some kind of frame work in which notification and/or > > policy description updating can be worked the access decision > > mechanism of the particular server (since we actually have that > > distinction so far). > > Like Jishnu, I don't understand what you mean here. Lets suppose we actually recognized servers. Each server would have an administrative interface to its AccessDecision object that can be updated with a typed policy description. Much like I illustrated before about 100 messages ago :) Servers during initialization would register with a Policy Administrative service, call it an Enclave, for its security policy (access decision, auditing, whatever, etc.). So, the server can be notified by the Enclave on updates to the policy within the Enclave. And as you pointed out about 150 messages ago, you would like to bring up a single server and write an ACL for the objects it serves. So, this model can also work for standalone servers, which can plop out the object reference to its administrative interface, and dynamic updates can happen to the server with command line tools. During this process, alot of cool nifty things can be done, such as optimization of the AccessDecision. Also not having to keep asing the AP or RR constantly because something might have changed. Yes, it's a push model. But it seems kind of natural, I think. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 19 Aug 1999 09:55:53 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jishnu Mukerji , Bob Blakley , Polar Humenn , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object > Jishnu Mukerji wrote: > > > > Paul, maybe you can help a lot here. I get this feeling that many of > > us do not have a clear understanding of the different possible > > configurations/realtionships among POA, Servant, Target Object etc. > > that can exist. my understanding is that the nature of the > > relationship is determined by certain set of POA policies. > > Would it be possible to enumerate all possibilities, and first of > > all convince ourselves that all combinations are actually > > meaningfully securable? Then we can use > > the same enumeration to figure out what would be the meaning of > > "instance" and where would be the right place to do the "domain > > manager association". It seems to me that for certain POA policy > > combinations the POA may be able to do it while for others we will > > have to go deep into the target object. Am I simply competely wet > > behind my ears in believing this? I thought of a couple more things I forgot to say on this subject: The creation of object references is largely decoupled from the selection of servants to process requests on those object references: - The RepositoryId in the object reference is purely advisory. I can create references to the same [POA,ObjectId] with different repository ids. This may affect the way clients view and use them, but doesn't affect the way the server handles invocations on them. - When a request arrives, if a servant manager is used to find a servant, the only information it has available to make the selection is [POA,ObjectId]. The servant it provides should ideally support the interface the client is expecting, but the servant manager doesn't know what that is. It is the responsibility of the original creator of the object reference (who selects the ObjectId) to put enough information in it for the servant manager to create a suitable Servant. - You can create references and then refuse to provide a servant to handle calls on them. Uses can then fail with an OBJECT_NOT_EXIST exception, or they can be redirected by causing a LOCATION_FORWARD reply to be sent. (Not sure of the security implications of this.) Typically orbs don't maintain much persistent state. (If they did they wouldn't scale.) - They are only obligated to maintain enough state to start a server of the right sort to handle an incoming invocation on an object reference if no server is already running. - A POA needs to maintain the state required by its policies to select Servants. This is mostly in the form of an active object map from ObjectId to Servant. But this is *not* persistent. It is up to the server to initialize this as it wishes each time it starts. So any persistence of this mapping is the responsibility of the (user written) implementation code in the server. - The ORB needs to maintain state of object references it (actually the POA) creates. But it need only keep this state so long as the object reference is in use *in the server*. - An orb *cannot* be expected to maintain *any* state for object references that have been passed out of its control. (E.g. passed as arguments to callers or callees, or externalized via object_to_string.) Date: Thu, 19 Aug 1999 10:05:23 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Polar Humenn CC: Jishnu Mukerji , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > Lets suppose we actually recognized servers. > > Each server would have an administrative interface to its > AccessDecision object that can be updated with a typed policy > description. Much like I illustrated before about 100 messages ago :) > > Servers during initialization would register with a Policy > Administrative service, call it an Enclave, for its security policy > (access decision, auditing, whatever, etc.). So, the server can be > notified by the Enclave on updates to the policy within the Enclave. > > And as you pointed out about 150 messages ago, you would like to bring > up a single server and write an ACL for the objects it serves. > > So, this model can also work for standalone servers, which can plop > out the object reference to its administrative interface, and dynamic > updates can happen to the server with command line tools. > > During this process, alot of cool nifty things can be done, such as > optimization of the AccessDecision. Also not having to keep asing the > AP or RR constantly because something might have changed. > > Yes, it's a push model. But it seems kind of natural, I think. I like this. It is the first suggestion I have heard for how all this can work that actually appears to scale - permitting access decisions to be made totally within the server. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 19 Aug 1999 11:21:44 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Paul H Kyzivat , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > Paul H Kyzivat wrote: > > > > Polar Humenn wrote: > > > > > > Lets suppose we actually recognized servers. > > > > > > Each server would have an administrative interface to its > > > AccessDecision object that can be updated with a typed policy > > > description. Much like I illustrated before about 100 messages ago :) > > > > > > Servers during initialization would register with a Policy > > > Administrative service, call it an Enclave, for its security policy > > > (access decision, auditing, whatever, etc.). So, the server can be > > > notified by the Enclave on updates to the policy within the Enclave. > > > > > > And as you pointed out about 150 messages ago, you would like to bring > > > up a single server and write an ACL for the objects it serves. > > > > > > So, this model can also work for standalone servers, which can plop > > > out the object reference to its administrative interface, and dynamic > > > updates can happen to the server with command line tools. > > > > > > During this process, alot of cool nifty things can be done, such as > > > optimization of the AccessDecision. Also not having to keep asing the > > > AP or RR constantly because something might have changed. > > > > > > Yes, it's a push model. But it seems kind of natural, I think. > > > > I like this. It is the first suggestion I have heard for how all this > > can work that actually appears to scale - permitting access decisions to > > be made totally within the server. > > Well, if this is the direction that we want to take, it is time to start > writing an RFP. This change will be way beyond anything that can be > snuck through an RTF. There will be several ways to skin this cat and > definitely the alternatives need to be considered and everyone with an > idea needs to be given a chance to present it. So, who wants to craft > the requirements to put in an RFP? Whoa! do you think and RFP is quite prudent at this time? (am I sounding like an ex-pres?) I mean, let's do a few presentations, see what is out there, find out a few things first, about feasiblity, implementability, scalability, etc. , and then issue an RFP. ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Sender: jis@fpk.hp.com Date: Thu, 19 Aug 1999 12:01:38 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Polar Humenn CC: Paul H Kyzivat , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > > Well, if this is the direction that we want to take, it is time to start > > writing an RFP. This change will be way beyond anything that can be > > snuck through an RTF. There will be several ways to skin this cat and > > definitely the alternatives need to be considered and everyone with an > > idea needs to be given a chance to present it. So, who wants to craft > > the requirements to put in an RFP? > > Whoa! do you think and RFP is quite prudent at this time? (am I sounding > like an ex-pres?) > > I mean, let's do a few presentations, see what is out there, find out a > few things first, about feasiblity, implementability, scalability, etc. , > and then issue an RFP. I just want to make sure that no further attempts are made at this time to shoehorn any of this in through any RTF. Of course one should go through the proper motions to put together an RFP. A strawman draft is a legitimate thing to do to get the ball rolling. The other reason for starting with a draft rather than vague discussion is that when things get closer having draft as the basis of a discussion could save you at least one meeting cycle. Remember RFP's don't ask for a specific solution. What they ask for is a solution of a problem described through a set of requirements. I was talking of getting figuring out what the requirements should be. For example, clearly you cannot state as a requirement that "recognize servers". It will take considerable thought to put together the requirements. Perhaps a good starting point would be extracting a few of the requirements from Bob's list that we found are not quite met by the current system. Then we can think about what additional specificity makes sense. But certainly proposing a particular solution in an RFP would be a no-no. Also, I would like to see the RR object restored to where it was pending resolution of these broader issues. This can be done in the Security RTF. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: "PACHL, Jan" To: sec-rev@omg.org Subject: RE: AccessDecision object Date: Thu, 19 Aug 1999 11:49:46 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Re the retrieval of the RR information:- Going back to the requirements as stated by Bob Blakley and numbered by Jishnu Mukerji (see the messages way back then long time ago, on Monday August 16). Stating the requirements really clarified the issues, but I have some doubts about 5a: > 5a. (It must be possible at administration time to set > and/or change the required right(s) assigned to each > method of an interface.) How important is this requirement? I believe this was raised before in this discussion but then dropped with no clear agreement. Anybody has any scenarios where this is a requirement? If not, why not assume that RR are assigned to the method (operation) once and never changed. This would be consistent with the following quote from CORBASEC v1.5: --------- quote from para [701] -------- [the RequiredRights interface allows] Object interface developers to express the "access control types" of their operations using standard rights, which are likely to be understood by administrators, without requiring administrators to be aware of the detailed semantics of those operations. --------- quote ends --------- Of course, even with the assumption that the RR assignment is immutable, we still have to figure out how to refer to the interface and to assign the responsibility for storing the RR assignment---those problems don't go away. But at least we don't have to worry about propagating changes, refreshing the cached assignments, etc. ===================== Jan Pachl Applied Technology Research EDS E.Solutions jpachl@shl.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 19 Aug 1999 13:03:50 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Paul H Kyzivat , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > Polar Humenn wrote: > > > > On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > > > > Well, if this is the direction that we want to take, it is time to start > > > writing an RFP. This change will be way beyond anything that can be > > > snuck through an RTF. There will be several ways to skin this cat and > > > definitely the alternatives need to be considered and everyone with an > > > idea needs to be given a chance to present it. So, who wants to craft > > > the requirements to put in an RFP? > > > > Whoa! do you think and RFP is quite prudent at this time? (am I sounding > > like an ex-pres?) > > > > I mean, let's do a few presentations, see what is out there, find out a > > few things first, about feasiblity, implementability, scalability, etc. , > > and then issue an RFP. > > I just want to make sure that no further attempts are made at this time > to shoehorn any of this in through any RTF. Of course one should go > through the proper motions to put together an RFP. A strawman draft is a > legitimate thing to do to get the ball rolling. The other reason for > starting with a draft rather than vague discussion is that when things > get closer having draft as the basis of a discussion could save you at > least one meeting cycle. Yeah, but if my point is, "it's too soon", what does saving at least one meeting cycle really mean now? > Remember RFP's don't ask for a specific solution. What they ask for is a > solution of a problem described through a set of requirements. I was > talking of getting figuring out what the requirements should be. For > example, clearly you cannot state as a requirement that "recognize > servers". Surely, why specify something based on reality, practicality, and common sense? Incidentally, we place such inherent restrictions on "own" credentials and other stuff. > It will take considerable thought to put together the > requirements. Perhaps a good starting point would be extracting a few of > the requirements from Bob's list that we found are not quite met by the > current system. Then we can think about what additional specificity > makes sense. But certainly proposing a particular solution in an RFP > would be a no-no. It would also be nice to know the things that can and have already be accomplished instead before formulating the wish list. > Also, I would like to see the RR object restored to where it was pending > resolution of these broader issues. This can be done in the Security > RTF. I'm not saying that it should be elminated, but where it comes from and what's it scope is the more pertinate question. ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Sender: jis@fpk.hp.com Date: Thu, 19 Aug 1999 13:26:04 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Polar Humenn CC: Paul H Kyzivat , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Polar Humenn wrote: > > On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > > > Polar Humenn wrote: > > > > > > On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > > > > > > Well, if this is the direction that we want to take, it is time to start > > > > writing an RFP. This change will be way beyond anything that can be > > > > snuck through an RTF. There will be several ways to skin this cat and > > > > definitely the alternatives need to be considered and everyone with an > > > > idea needs to be given a chance to present it. So, who wants to craft > > > > the requirements to put in an RFP? > > > > > > Whoa! do you think and RFP is quite prudent at this time? (am I sounding > > > like an ex-pres?) > > > > > > I mean, let's do a few presentations, see what is out there, find out a > > > few things first, about feasiblity, implementability, scalability, etc. , > > > and then issue an RFP. > > > > I just want to make sure that no further attempts are made at this time > > to shoehorn any of this in through any RTF. Of course one should go > > through the proper motions to put together an RFP. A strawman draft is a > > legitimate thing to do to get the ball rolling. The other reason for > > starting with a draft rather than vague discussion is that when things > > get closer having draft as the basis of a discussion could save you at > > least one meeting cycle. > > Yeah, but if my point is, "it's too soon", what does saving at least one > meeting cycle really mean now? At the end of the day, it could mean anything between 2 to 4 months saving in the overall process, i.e. getting the final submission adopted. If you don't consider that important, clearly this must not be a pressing issue that needs a fix as soon as possible:-). > > Remember RFP's don't ask for a specific solution. What they ask for is a > > solution of a problem described through a set of requirements. I was > > talking of getting figuring out what the requirements should be. For > > example, clearly you cannot state as a requirement that "recognize > > servers". > > Surely, why specify something based on reality, practicality, and common > sense? RFPs, are Requests For Proposal. They are not specifications. The specification comes in response to an RFP. > Incidentally, we place such inherent restrictions on "own" credentials and > other stuff. Huh??? Couldn't parse that one. What has that got to do with requirements for inclusion in an RFP? Are you talking of restrictions that are in the spec? Those were arrived at by submitters to an RFP and previous RTFs. > > It will take considerable thought to put together the > > requirements. Perhaps a good starting point would be extracting a few of > > the requirements from Bob's list that we found are not quite met by the > > current system. Then we can think about what additional specificity > > makes sense. But certainly proposing a particular solution in an RFP > > would be a no-no. > > It would also be nice to know the things that can and have already be > accomplished instead before formulating the wish list. Sure, but constructing a list always helps keep track of what is and is not practical and helps one stop going around in circles. Sounds to me like you really don't want us to work on an RFP.:-) > > Also, I would like to see the RR object restored to where it was pending > > resolution of these broader issues. This can be done in the Security > > RTF. > > I'm not saying that it should be elminated, but where it comes from and > what's it scope is the more pertinate question. What I am saying is that currently it is at a place and we have no business removing it from there until we find another place for it. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 19 Aug 1999 13:20:24 -0400 (EDT) From: Polar Humenn To: "PACHL, Jan" cc: sec-rev@omg.org Subject: RE: AccessDecision object On Thu, 19 Aug 1999, PACHL, Jan wrote: > Re the retrieval of the RR information:- > Going back to the requirements as stated by Bob Blakley and numbered by > Jishnu Mukerji (see the messages way back then long time ago, on Monday > August 16). > Stating the requirements really clarified the issues, but I have some doubts > about 5a: > > > 5a. (It must be possible at administration time to set > > and/or change the required right(s) assigned to each > > method of an interface.) > > How important is this requirement? I believe this was raised before in this > discussion but then dropped with no clear agreement. > > Anybody has any scenarios where this is a requirement? If not, why not > assume that RR are assigned to the method (operation) once and never > changed. This would be consistent with the following quote from CORBASEC > v1.5: > > --------- quote from para [701] -------- > [the RequiredRights interface allows] Object interface developers to express > the "access control types" of their operations using standard rights, which > are likely to be understood by administrators, without requiring > administrators to be aware of the detailed semantics of those operations. > --------- quote ends --------- > > Of course, even with the assumption that the RR assignment is immutable, we > still have to figure out how to refer to the interface and to assign the > responsibility for storing the RR assignment---those problems don't go away. > But at least we don't have to worry about propagating changes, refreshing > the cached assignments, etc. Specifying such an immutable restriction is impractical. All sorts of things can happen, such as, the adminstrator spills his coffee on his keyboard/mouse, and some required rights get asigned to an interface you didn't want. Or more likely, he just does something stupid. The scene: Mission Control Columbia: Huston, we have a problem. Huston: What is it Columbia? Columbia: We cannot seem to access the flush operation on the toliet. Huston: I'm sorry Columbia, George, the sys admin down here, accidently protected the flush operation with the LauchNuclearMissles right. How he did that, I don't know. Must be an adminstrative glitch. Columbia: Can't we solve this problem? Huston: Negative Columbia, the only way to do that is to give you guys the LauchNuclearMissles right, but the President won't go for that. Columbia: Can we just fix the required rights? Huston: Negative Columbia, the OMG says that the required rights is immutable, it would violate their specification. Columbia: Huston, this is going to lead to a real mess. Can't we just point to another required rights object? Huston: Are you crazy, there is only one required rights object for the entire universe! We're just going to have to get you down here and change the interface signature for the toliet. Columbia: Huston, we're coming in! ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: "Gene Jarboe" To: "Jishnu Mukerji" , "Polar Humenn" Cc: "Paul H Kyzivat" , "Bob Blakley" , , "William Pope" Subject: Re: AccessDecision object Date: Thu, 19 Aug 1999 13:58:09 -0400 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Jishnu Mukerji wrote: > Polar Humenn wrote: > > > > On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > > > > Well, if this is the direction that we want to take, it is time to start > > > writing an RFP. This change will be way beyond anything that can be > > > snuck through an RTF. There will be several ways to skin this cat and > > > definitely the alternatives need to be considered and everyone with an > > > idea needs to be given a chance to present it. So, who wants to craft > > > the requirements to put in an RFP? > > > > Whoa! do you think and RFP is quite prudent at this time? (am I sounding > > like an ex-pres?) > > > > I mean, let's do a few presentations, see what is out there, find out a > > few things first, about feasiblity, implementability, scalability, etc. , > > and then issue an RFP. > > I just want to make sure that no further attempts are made at this time > to shoehorn any of this in through any RTF. Of course one should go > through the proper motions to put together an RFP. A strawman draft is a > legitimate thing to do to get the ball rolling. The other reason for > starting with a draft rather than vague discussion is that when things > get closer having draft as the basis of a discussion could save you at > least one meeting cycle. Jishnu Where will the strawman draft RFP be accomplished (e.g., at the OMG SecSIG or ORBOS)? Can we start the RFP next week? > > Remember RFP's don't ask for a specific solution. What they ask for is a > solution of a problem described through a set of requirements. I was > talking of getting figuring out what the requirements should be. For > example, clearly you cannot state as a requirement that "recognize > servers". It will take considerable thought to put together the > requirements. Perhaps a good starting point would be extracting a few of > the requirements from Bob's list that we found are not quite met by the > current system. Then we can think about what additional specificity > makes sense. But certainly proposing a particular solution in an RFP > would be a no-no. > > Also, I would like to see the RR object restored to where it was pending > resolution of these broader issues. This can be done in the Security > RTF. > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 19 Aug 1999 14:10:29 -0400 (EDT) From: Polar Humenn To: Gene Jarboe cc: Jishnu Mukerji , Paul H Kyzivat , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object On Thu, 19 Aug 1999, Gene Jarboe wrote: > Jishnu Mukerji wrote: > > > Polar Humenn wrote: > > > > > > On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > > > > > > Well, if this is the direction that we want to take, it is time to > start > > > > writing an RFP. This change will be way beyond anything that can be > > > > snuck through an RTF. There will be several ways to skin this cat and > > > > definitely the alternatives need to be considered and everyone with an > > > > idea needs to be given a chance to present it. So, who wants to craft > > > > the requirements to put in an RFP? > > > > > > Whoa! do you think and RFP is quite prudent at this time? (am I sounding > > > like an ex-pres?) > > > > > > I mean, let's do a few presentations, see what is out there, find out a > > > few things first, about feasiblity, implementability, scalability, etc. > , > > > and then issue an RFP. > > > > I just want to make sure that no further attempts are made at this time > > to shoehorn any of this in through any RTF. Of course one should go > > through the proper motions to put together an RFP. A strawman draft is a > > legitimate thing to do to get the ball rolling. The other reason for > > starting with a draft rather than vague discussion is that when things > > get closer having draft as the basis of a discussion could save you at > > least one meeting cycle. > > Jishnu > > Where will the strawman draft RFP be accomplished (e.g., at the > OMG SecSIG or ORBOS)? Can we start the RFP next week? > Gee! I've been spouting off about this kind of thing and idea for two or more years. Who did I convince so emphatically just now? ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 19 Aug 1999 14:05:05 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jishnu Mukerji CC: Polar Humenn , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Jishnu Mukerji wrote: > > Polar Humenn wrote: > > > > On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > > > > > Polar Humenn wrote: > > > > > > > > On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > > > > > > > > Well, if this is the direction that we want to take, it is > > > > > time to start writing an RFP. This change will be way beyond > > > > > anything that can be snuck through an RTF. There will be > > > > > several ways to skin this cat and definitely the alternatives > > > > > need to be considered and everyone with an > > > > > idea needs to be given a chance to present it. So, who wants > > > > > to craft the requirements to put in an RFP? I think you are right Jishnu, but I am not going to volunteer. Seems like the RFP ought to be written by real security people. This security stuff is at most a hobby with me - I am interested in seeing something practical and implementable, but I don't pretend to know much of the details. (I certainly haven't done a security service implementation.) I am mostly playing the devil's (i.e. ORB implementor's) advocate - asking dumb questions. Of course I probably won't be shy in commenting on drafts. I also won't be in San Jose next week. With luck I would think there might be a critical mass there to throw together a strawhorse. Sender: jis@fpk.hp.com Date: Thu, 19 Aug 1999 15:47:48 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Paul H Kyzivat CC: Polar Humenn , Bob Blakley , sec-rev@omg.org, William Pope Subject: Re: AccessDecision object Paul H Kyzivat wrote: > > Jishnu Mukerji wrote: > > > > Polar Humenn wrote: > > > > > > On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > > > > > > > Polar Humenn wrote: > > > > > > > > > > On Thu, 19 Aug 1999, Jishnu Mukerji wrote: > > > > > > > > > > Well, if this is the direction that we want to take, it is > > > > > > time to start writing an RFP. This change will be way beyond > > > > > > anything that can be snuck through an RTF. There will be > > > > > > several ways to skin this cat and definitely the alternatives > > > > > > need to be considered and everyone with an > > > > > > idea needs to be given a chance to present it. So, who wants > > > > > > to craft the requirements to put in an RFP? > > I think you are right Jishnu, but I am not going to volunteer. > > Seems like the RFP ought to be written by real security people. > This security stuff is at most a hobby with me - I am interested in > seeing something practical and implementable, but I don't pretend to > know much of the details. (I certainly haven't done a security service > implementation.) I am mostly playing the devil's (i.e. ORB > implementor's) advocate - asking dumb questions. > > Of course I probably won't be shy in commenting on drafts. > > I also won't be in San Jose next week. With luck I would think there > might be a critical mass there to throw together a strawhorse. and > > Where will the strawman draft RFP be accomplished (e.g., at the > OMG SecSIG or ORBOS)? Can we start the RFP next week? Weell the RFP eventually gets issued by ORBOS I think. But work on crafting it together presumably takes place in SecSIG. Would be a good thing to bring up at the upcoming SecSIG and see where it goes. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 22 Sep 1999 10:46:36 -0400 (EDT) From: Polar Humenn To: sec-rev@omg.org Subject: AccessDecision Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9d96b11ebb7cdfb7a5c8e9721db5330a RTF Members,, I'm trying to write the resolutions that we agreed to in the meeting, but my notes are bit foggy on some points, this one is on AccessDecision. At the meeting we agreed to copy the SecurityLevel2::AccessDecision interface into SecurityReplaceable as well. However, I have some notes about the interface. Did we agree or not agree to change the interface to not use a Credentials list, because the Credentials list no longer represents a delegation chain? I had two proposals scribbled down: #1: interface AccessDecision { boolean access_allowed( in SecurityLevel2::ReceivedCredentials creds, in Object target, in CORBA::RepositoryId interface, in CORBA::Identifier operation ); }; #2: interface AccessDecision { boolean access_allowed( in SecurityLevel2::Credentials creds, in Object target, in CORBA::RepositoryId interface, in CORBA::Identifier operation ); }; The only difference was ReceivedCredentials as opposed to Credentials. Any comments? Soon! -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com