Issue 2033: Construction Policy (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Need specific way to associated credentials with the target object reference on the target side. Resolution: Revised Text: Actions taken: October 5, 1998: received issue Discussion: :Opaque because the C++ mapping causes a new object to End of Annotations:===== Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Sat, 3 Oct 1998 19:56:19 -0400 (EDT) From: Polar Humenn To: issues@adiron.com, secsig@omg.org, sec-rev@omg.org cc: polar@adiron.com, fred@adiron.com Subject: Construction Policy Document: Security 1.2 5 Jan 98 Severity: Critical Summary: Need specific way to associated credentials with the target object reference on the target side. Hi People, It appears that we need to associate a set of credentials with a particular object when its reference is created on the target side. There currently is no specific way to do this. This capability is needed to stipulate the credentisls mechanisms and principal ids (i.e. security components) that must go into the object's IOR. The best I can figure out is that it must be the particular capsule specific own_credentials list when the object is created. However, that may need to be more restrictive. Trust me on this one. :) Okay, let me elaborate. At the time of object construction, i.e. during a POA:create_reference, we need to tell the ORB/POA to which security mechanism & names, requires/supports association options the object will "answer". The best way to do this is to attach a list of own credentials to the object reference. So, say we have a set of own credentials for our capsule/orb instance ("server" in POA terms) stipulating that I am "Polar" in various credentials forms, each for kerberos, SPKM_1, and SSL. Each Credentials object will represent one mechanism and has a settable valid range of requires/supports association options. Say that I only want the object that I just created to only handle kerberos and SSL, but not use our SPKM_1 Credentials. I would attach only two of the three Credentials objects I have to the object reference. However, since object references should be immutable, it can be done only at object construction. Enter the POA. I imagine this association credentials to object reference would be done via a ConstructionPolicy. It should not be done by a domain manager, since the domain manager may not be locality constrained; and therefore, will not be able to get to access to capsule specific Credentials Lists. The approach can be two fold: 1. Create a locality constrained Construction Policy in SecurityLevel2 extending CORBA::ConstructionPolicy and add a credentials list it. There is a reference to CORBA::SecConstructionPolicy in the spec, but no currently defined construction policy interface. (Section 15.6.3 "Security Policies Introduction") interface SecConstructionPolicy : CORBA::ConstructionPolicy {//Locality constrained readonly attribute CredentialsList creds; } Therefore, POA's that are security aware (or via a portable binding interceptor) can narrow it to SecurityLevel2::SecConstructionPolicy (will this policy be placed on the POA?) and get the credentials to associate with the new object reference. The POA may also further use the SecureInvocationPolicy from the relavent domain manager and query for the requires/supports association options to further constrain the security components in the constructed IOR. (The credentials will have settable default association options particular to the mechanism they support. So if no SecureInvocationPolicy objects are associated with the domain manager, the default association options on each Credentials object are used. I like this approach since you don't have to support the existance of a domain manager for lightweight ORB applications. (i.e. the way ORB applications are currently being written). 2. To further enhance the model would be to add a SecurityAdmin::MechanismPolicy interface to hang off of a security domain manager. For the target side, upon creation of an object this policy would aid in selecting the credentials to use from the list of capsule specific own credentials list just as the SecurityAdmin::DelegationMode policy is said to be used to aid in selecting credentials for invocation. (Section 15.6.6.4 "SecurityAdmin::DelegationPolicy Interface") Note: A POA using the SecurityAdmin interfaces would use this policy to further whittle down and select the credentials that were set forth in the SecConstructionPolicy. interface MechanismPolicy { Security::MechanismTypeList get_mechanisms( in CORBA::InterfaceDef object_type ); void set_mechanism( in CORBA::InterfaceDef object_type, in Security::MechanismTypeList mechanisms ); }; This mechanism policy's implications on the client side may help to further restrict any SecurityLevel2::MechanismPolicy override placed on an object reference by an application. So, any comments about 1. Creating a SecurityLevel2::SecConstructionPolicy 2. Adding a SecurityAdmin::MechanismPolicy for completeness. Please reply and discuss. Thanks, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Return-Path: Sender: jon@floorboard.com Date: Sat, 03 Oct 1998 17:31:59 -0700 From: Jonathan Biggar X-Accept-Language: en To: Polar Humenn CC: issues@adiron.com, secsig@omg.org, sec-rev@omg.org, fred@adiron.com Subject: Re: Construction Policy References: Just wondering, would it also be useful to define security Policy objects that would be used when creating the POA, i.e. in the create_POA's policy list? Perhaps as defaults that would be used for all references created by the POA unless overridden? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Polar Humenn wrote: > > Document: Security 1.2 5 Jan 98 > Severity: Critical > Summary: Need specific way to associated credentials with > the target object reference on the target side. > > Hi People, > > It appears that we need to associate a set of credentials with a > particular object when its reference is created on the target side. > There currently is no specific way to do this. > > This capability is needed to stipulate the credentisls mechanisms > and > principal ids (i.e. security components) that must go into the > object's > IOR. > > The best I can figure out is that it must be the particular capsule > specific own_credentials list when the object is created. However, > that > may need to be more restrictive. > > Trust me on this one. :) > > Okay, let me elaborate. At the time of object construction, > i.e. during a > POA:create_reference, we need to tell the ORB/POA to which security > mechanism & names, requires/supports association options the object > will > "answer". The best way to do this is to attach a list of own > credentials > to the object reference. So, say we have a set of own credentials > for our > capsule/orb instance ("server" in POA terms) stipulating that I am > "Polar" in various credentials forms, each for kerberos, SPKM_1, and > SSL. > Each Credentials object will represent one mechanism and has a > settable > valid range of requires/supports association options. > > Say that I only want the object that I just created to only handle > kerberos and SSL, but not use our SPKM_1 Credentials. I would attach > only > two of the three Credentials objects I have to the object reference. > However, since object references should be immutable, it can be > done only at object construction. > > Enter the POA. > > I imagine this association credentials to object reference would be > done > via a ConstructionPolicy. It should not be done by a domain > manager, > since the domain manager may not be locality constrained; and > therefore, > will not be able to get to access to capsule specific Credentials > Lists. > > The approach can be two fold: > > 1. > Create a locality constrained Construction Policy in SecurityLevel2 > extending CORBA::ConstructionPolicy and add a credentials list it. > > There is a reference to CORBA::SecConstructionPolicy in the spec, > but > no currently defined construction policy interface. (Section 15.6.3 > "Security Policies Introduction") > > interface SecConstructionPolicy > : CORBA::ConstructionPolicy {//Locality constrained > readonly attribute CredentialsList creds; > } > > Therefore, POA's that are security aware (or via a portable binding > interceptor) can narrow it to SecurityLevel2::SecConstructionPolicy > (will > this policy be placed on the POA?) and get the credentials to > associate > with the new object reference. > > The POA may also further use the SecureInvocationPolicy from the > relavent > domain manager and query for the requires/supports association > options to > further constrain the security components in the constructed > IOR. (The > credentials will have settable default association options > particular to > the mechanism they support. So if no SecureInvocationPolicy objects > are > associated with the domain manager, the default association options > on > each Credentials object are used. > > I like this approach since you don't have to support the existance > of a > domain manager for lightweight ORB applications. (i.e. the way ORB > applications are currently being written). > > 2. > To further enhance the model would be to add a > SecurityAdmin::MechanismPolicy interface to hang off of a security > domain > manager. > > For the target side, upon creation of an object this policy would > aid in > selecting the credentials to use from the list of capsule specific > own > credentials list just as the SecurityAdmin::DelegationMode policy is > said > to be used to aid in selecting credentials for invocation. (Section > 15.6.6.4 "SecurityAdmin::DelegationPolicy Interface") > > Note: A POA using the SecurityAdmin interfaces would use this policy > to > further whittle down and select the credentials that were set forth > in the > SecConstructionPolicy. > > interface MechanismPolicy { > Security::MechanismTypeList get_mechanisms( > in CORBA::InterfaceDef object_type > ); > void set_mechanism( > in CORBA::InterfaceDef object_type, > in Security::MechanismTypeList mechanisms > ); > }; > > This mechanism policy's implications on the client side may help to > further restrict any SecurityLevel2::MechanismPolicy override placed > on > an object reference by an application. > > So, any comments about > 1. Creating a SecurityLevel2::SecConstructionPolicy > 2. Adding a SecurityAdmin::MechanismPolicy for completeness. > > Please reply and discuss. Thanks, > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > President 2-212 Center for Science & Technology > mailto:polar@adiron.com CASE Center/Syracuse University > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Sun, 4 Oct 1998 10:41:57 -0400 (EDT) From: Polar Humenn To: Jonathan Biggar cc: issues@adiron.com, secsig@omg.org, sec-rev@omg.org, orbos@omg.org, fred@adiron.com Subject: Re: Construction Policy On Sat, 3 Oct 1998, Jonathan Biggar wrote: > Just wondering, would it also be useful to define security Policy > objects that would be used when creating the POA, i.e. in the > create_POA's policy list? > Perhaps as defaults that would be used for all references created by > the > POA unless overridden? Yes, however, the POA specification says that only policies created by the parent POA can be used in the create_POA's policy list. This restriction would have to be changed. Or, as you say, define security Policy objects that are created by the POA. We already have a CORBA::ConstructionPolicy in 2.2, which can be extended for security, as I did below. Hell, it was introduced by security. However, we still have no specification of where the thing goes. I would like to see it go on the POA, but not have to be created by the POA, as it can be created by other entities, such as a security service. I also imagine some mechanism for initializing the "RootPOA" with a construction policy as well. > Polar Humenn wrote: > > Issue: > > Document: Security 1.2 5 Jan 98 > > Severity: Critical > > Summary: Need specific way to associated credentials with > > the target object reference on the target side. > > > > Hi People, > > > > It appears that we need to associate a set of credentials with a > > particular object when its reference is created on the target > side. > > There currently is no specific way to do this. > > > > This capability is needed to stipulate the credentisls mechanisms > and > > principal ids (i.e. security components) that must go into the > object's > > IOR. > > > > The best I can figure out is that it must be the particular > capsule > > specific own_credentials list when the object is created. > However, that > > may need to be more restrictive. > > > > Trust me on this one. :) > > > > Okay, let me elaborate. At the time of object construction, > i.e. during a > > POA:create_reference, we need to tell the ORB/POA to which > security > > mechanism & names, requires/supports association options the > object will > > "answer". The best way to do this is to attach a list of own > credentials > > to the object reference. So, say we have a set of own credentials > for our > > capsule/orb instance ("server" in POA terms) stipulating that I > am > > "Polar" in various credentials forms, each for kerberos, SPKM_1, > and SSL. > > Each Credentials object will represent one mechanism and has a > settable > > valid range of requires/supports association options. > > > > Say that I only want the object that I just created to only handle > > kerberos and SSL, but not use our SPKM_1 Credentials. I would > attach only > > two of the three Credentials objects I have to the object > reference. > > However, since object references should be immutable, it can be > > done only at object construction. > > > > Enter the POA. > > > > I imagine this association credentials to object reference would > be done > > via a ConstructionPolicy. It should not be done by a domain > manager, > > since the domain manager may not be locality constrained; and > therefore, > > will not be able to get to access to capsule specific Credentials > Lists. > > > > The approach can be two fold: > > > > 1. > > Create a locality constrained Construction Policy in > SecurityLevel2 > > extending CORBA::ConstructionPolicy and add a credentials list it. > > > > There is a reference to CORBA::SecConstructionPolicy in the spec, > but > > no currently defined construction policy interface. (Section > 15.6.3 > > "Security Policies Introduction") > > > > interface SecConstructionPolicy > > : CORBA::ConstructionPolicy {//Locality > constrained > > readonly attribute CredentialsList creds; > > } > > > > Therefore, POA's that are security aware (or via a portable > binding > > interceptor) can narrow it to > SecurityLevel2::SecConstructionPolicy (will > > this policy be placed on the POA?) and get the credentials to > associate > > with the new object reference. > > > > The POA may also further use the SecureInvocationPolicy from the > relavent query for the requires/supports association options to > > further constrain the security components in the constructed > IOR. (The > > credentials will have settable default association options > particular to > > the mechanism they support. So if no SecureInvocationPolicy > objects are > > associated with the domain manager, the default association > options on > > each Credentials object are used. > > > > I like this approach since you don't have to support the existance > of a > > domain manager for lightweight ORB applications. (i.e. the way ORB > > applications are currently being written). > > > > 2. > > To further enhance the model would be to add a > > SecurityAdmin::MechanismPolicy interface to hang off of a security > domain > > manager. > > > > For the target side, upon creation of an object this policy would > aid in > > selecting the credentials to use from the list of capsule specific > own > > credentials list just as the SecurityAdmin::DelegationMode policy > is said > > to be used to aid in selecting credentials for > invocation. (Section > > 15.6.6.4 "SecurityAdmin::DelegationPolicy Interface") > > > > Note: A POA using the SecurityAdmin interfaces would use this > policy to > > further whittle down and select the credentials that were set > forth in the > > SecConstructionPolicy. > > > > interface MechanismPolicy { > > Security::MechanismTypeList get_mechanisms( > > in CORBA::InterfaceDef object_type > > ); > > void set_mechanism( > > in CORBA::InterfaceDef object_type, > > in Security::MechanismTypeList mechanisms > > ); > > }; > > > > This mechanism policy's implications on the client side may help > to > > further restrict any SecurityLevel2::MechanismPolicy override > placed on > > an object reference by an application. > > > > So, any comments about > > 1. Creating a SecurityLevel2::SecConstructionPolicy > > 2. Adding a SecurityAdmin::MechanismPolicy for completeness. > > > > Please reply and discuss. Thanks, > > -Polar > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > President 2-212 Center for Science & > Technology > > mailto:polar@adiron.com CASE Center/Syracuse University > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com