Issue 1756: Semantics of the Mechanism Policy is not defined wel (sec-rev) Source: (, ) Nature: Clarification Severity: Significant Summary: Summary: Semantics of the Mechanism Policy is not defined well. There are different semantics if it is applied to a client object reference than to a server object reference. On the server side, the mechanism list stipulates which mechanisms can be used to handle the requests. This may stipulate which mechanisms are advertised in the IOR. However, since there is an order, and order preference should be specified. If a client wishes to invoke on said object and two mechanisms support the requested features, the first one that does so in the IOR should be said to be selected. To support multiple mechanisms on the client side, one would have to inquire which one was used and in which order to use them. This can also be implied by the order of the list. However, the semantics of such should be specified. Resolution: Revised Text: Actions taken: July 30, 1998: received issue November 13, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Date: Thu, 30 Jul 1998 16:27:25 -0400 From: www To: juergen@omg.org, web-incoming@omg.org Subject: WWW Form output Name: Polar Humenn Company: Adiron, LLC Email: polar@adiron.com Notification: Yes Specification: Service (Security) Section: 15-5.5.2 Formal #: who knows Version: 1.2 Draft Revision_Date: 5 Jan 98 Page: 15-94 Nature: Clarification Severity: Significant full_desc: BACKGROUND: Semantics of the Mechanism Policy is not defined well. There are different semantics if it is applied to a client object reference than to a server object reference. On the server side, the mechanism list stipulates which mechanisms can be used to handle the requests. This may stipulate which mechanisms are advertised in the IOR. However, since there is an order, and order preference should be specified. If a client wishes to invoke on said object and two mechanisms support the requested features, the first one that does so in the IOR should be said to be selected. To support multiple mechanisms on the client side, one would have to inquire which one was used and in which order to use them. This can also be implied by the order of the list. However, the semantics of such should be specified. PROPOSED SOLUTION Add text after the third paragraph under Mechanism Policy to the section, starting with "This interface has a single.." The mechanism policy contains a list of mechanism types. The order of this list is importan both when applied to a client side object reference and an object reference used as a server. When a MechanismsPolicy with more than one mechanism type is applied to a client object reference, the semantics of mechanism selection at the point of invocation is as follows: 1. Select the first mechanism in the mechanisms attribute of the applied MechanismPolicy. 2. The selected mechanism shall be checked for support by the selected invocation credentials list and the selected quality of protection. The invocation credentals list may be selected by virtue of the InvocationCredentialsPolicy. The quality of protection may be selected by the QOPPolicy. Invocation credentials is itself an ordered list. The invocation credentials are checked in that order. 3. Select the first credentials in the ivocation credentials list. 4. Check the selected invocation credentials against the target's IOR for support of the selected mechanism. The profiles in the IOR, as well as any of subcomponents they contain, are in an ordered list. The profiles and their components are checked in that order. 5. Select the first profile in the IOR. 6. Check the selected invocation credentials against the selected profile for support of the selected mechanism. 7. If profile does not support the criteria of step 6, select the next profile and go to step 6. 8. If no profiles in the IOR support the selected credentials and selected mechansim, select the next credentials in the invocation credentials list and go to step 4. 9. If no credentials match the selected mechanism and the profiles in the IOR, select the next mechanism from the mechanisms list and go to step 2. 10.If no mechanism matches any of the invocation credentials and the profile in the IOR, the invocation raises the CORBA::NO_PERMISSION exception. When a MechanismPolicy is applied to a server object reference the mechanisms listed in the MechanismPolicy direct the construction of profiles in the IOR. This order is important as it cooperates with the semantics of mechanism selection on the client side of an invocation. 1. Select the first mechanism in the mechanisms attribute of the applied MechanismPolicy. 2. The selected mechanism shall be checked for support by the own credentials. Own credentials is itself an ordered list. The own credentials are checked in that order. 3. Select the first credentials in the own credentials list. 4. Check the selected credentials for support of the selected mechansim. If the credentials can support the mechansim create the IOR profile and/or subcomponent that reflects the capabilities and restrictions of the selected mechanism and selected credentials. Add that profile or subcomponent to the IOR for the server object. 5. Select the next member of the own credentials list and go to step 4. 6. If no more credentials, select the next mechanism in the mechanisms list and go to step 3. 7. If no more mechanisms, processing is complete. 8. If no mechanisms can be applied, thereby making the object in accessable, a CORBA::BAD_PARAM exception is raised at the point that a policy override is applied to the server object reference. Interaction with other Policies. On the server side, if the InvocationCredentialsPolicy or the QOPPolicy is overriden the MechanismsPolicy must be checked again. A CORBA::BAD_PARAM exception may be raised if the check fails. ==================== Of course, text concerning "Interaction with other Policies" should apply to the InvocationCredentialsPolicy and the QOP Policy. submit: Submit Issue Report