Issue 634: Credentials in Security rev 1.2 are inconsistent (sec-rev) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Section 15.5.4[2], 15.5.3[3], 15.5.7[12]: what was meant is that Credential cannot be exported to non-security service object, can only be imported to client. Resolution: resolved close issue Revised Text: Since Credentials are locality constrained objects, it stands to reason that any other object that has an operation that has a Credentials or CredentialsList type parameter or return value must also be a locality constrained object. issue superseded by i Actions taken: July 29, 1997: received issue August 5, 1997: closed issue, superseded by issues649/650 August 5, 1997: closed issue; Duplicate or Merged Discussion: End of Annotations:===== Return-Path: Date: Tue, 29 Jul 1997 16:10:09 -0400 From: Ken Geisinger Organization: Concept 5 Technologies To: security@omg.org, sec-rev@omg.org CC: rudell@concept5.com, adutta@concept5.com, mkatz@concept5.com Subject: Credentials in rev1.2 I think I found an inconsistency in the Security rev1.2 Draft02. Section 15.5.4[2] says "Credentials must not be exported to other processes..." and states that an exception must be raised if an attempt is made. Section 15.5.3[3] says that the PrincipleAuthenticator Object creates a Credential and "Its object reference is also returned so it can be used for other operations..." Section 15.5.7[12] Says that the AuditChannel object can recieve a Credential as does Vault (section 15.7.4[34]), AccessDecision (section 15.7.4[45], and AccessPolicy (section 15.6.4[17]) and that SecurityContext returns a Credential (section 15.7.4[37]). So, either our poor client is a server to all of these interfaces or perhaps a clarification is required. I believe what was meant is that the Credential can not be exported to a non-security service object an can only be imported to the client an any service object on the execution thread from a security service object or pseudo-object. "Security service objects" are those defined by the security specification. -- --------------------------------- Ken Geisinger Sr. Software Integration Engineer Concept Five Technologies, Inc --------------------------------- Return-Path: Sender: jis@fpk.hp.com Date: Tue, 29 Jul 1997 17:53:21 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: Ken Geisinger Cc: security@omg.org, sec-rev@omg.org, rudell@concept5.com, adutta@concept5.com, mkatz@concept5.com Subject: Re: Credentials in rev1.2 References: <33DE4E21.F5CF2A90@concept5.com> Ken Geisinger wrote: > > I think I found an inconsistency in the Security rev1.2 Draft02. > > Section 15.5.4[2] says "Credentials must not be exported to other > processes..." and states that an exception must be raised if an > attempt > is made. > > Section 15.5.3[3] says that the PrincipleAuthenticator Object > creates a > Credential and "Its object reference is also returned so it can be > used > for other operations..." > > Section 15.5.7[12] Says that the AuditChannel object can recieve a > Credential as does Vault (section 15.7.4[34]), AccessDecision > (section > 15.7.4[45], and AccessPolicy (section 15.6.4[17]) and that > SecurityContext returns a Credential (section 15.7.4[37]). > > So, either our poor client is a server to all of these interfaces or > perhaps a clarification is required. I believe what was meant is > that > the Credential can not be exported to a non-security service object > an > can only be imported to the client an any service object on the > execution thread from a security service object or pseudo-object. > "Security service objects" are those defined by the security > specification. The ORB infrastructure on the node in which the client is running has indeed got to provide all of those interfaces to the client. The client itself does not have to act as a server for any of these interfaces. The general model is as follows. The client runs in a process on a system. There is an ORB infrastructure in place on that system. Interfaces like the Vault, and SecurityContext are internal to the ORB and are for all practical purposes library interfaces. The Credentials that pass around there are internal to the ORB. The Client can directly access only the Application level objects like PrincipalAuthenticator, AuditDecision, AccessPolicy etc. Those interfaces are instantiated within the process in which the client resides, and they provide access to the underlying security infrastructure to the client. The Credentials objects that pass through the operations of these interfaces are local to the process in which they are instantiated. The security information contained in those credentials objects eventually find their way inside the ORB, but the details of how that happens has been left unspecified on purpose because specifying that would start nailing down the impementation too much, which is a no-no. So, there is nothing wrong with the particular statement about the locality constraint of Credentials objects. What is wrong with Draft 02 and earlier drafts is a lack of explanation of the overall picture. We are working hard on trying to fix that. Hope that helps. Jishnu. -- Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA Return-Path: Date: Wed, 30 Jul 1997 08:42:43 -0400 From: Ken Geisinger Organization: Concept 5 Technologies To: Jishnu Mukerji CC: security@omg.org, sec-rev@omg.org, rudell@concept5.com, adutta@concept5.com, mkatz@concept5.com Subject: Re: Credentials in rev1.2 References: <33DE4E21.F5CF2A90@concept5.com> <33DE6651.6AD9@fpk.hp.com> Jishnu Mukerji wrote: > > Ken Geisinger wrote: > > > > I think I found an inconsistency in the Security rev1.2 Draft02. > > > > Section 15.5.4[2] says "Credentials must not be exported to other > > processes..." and states that an exception must be raised if an > attempt > > is made. > > > > Section 15.5.3[3] says that the PrincipleAuthenticator Object > creates a > > Credential and "Its object reference is also returned so it can be > used > > for other operations..." > > > > Section 15.5.7[12] Says that the AuditChannel object can recieve a > > Credential as does Vault (section 15.7.4[34]), AccessDecision > (section > > 15.7.4[45], and AccessPolicy (section 15.6.4[17]) and that > > SecurityContext returns a Credential (section 15.7.4[37]). > > > > So, either our poor client is a server to all of these interfaces > or > > perhaps a clarification is required. I believe what was meant is > that > > the Credential can not be exported to a non-security service > object an > > can only be imported to the client an any service object on the > > execution thread from a security service object or pseudo-object. > > "Security service objects" are those defined by the security > > specification. > > The ORB infrastructure on the node in which the client is running > has > indeed got to provide all of those interfaces to the client. The > client > itself does not have to act as a server for any of these interfaces. > So, your saying 15.5.4[2] should have said "Credentials must not be exported to other nodes...." and not "...exported to other processes..." > The general model is as follows. The client runs in a process on a > system. There is an ORB infrastructure in place on that system. > Interfaces like the Vault, and SecurityContext are internal to the > ORB > and are for all practical purposes library interfaces. The > Credentials > that pass around there are internal to the ORB. The Client can > directly > access only the Application level objects like > PrincipalAuthenticator, > AuditDecision, AccessPolicy etc. Those interfaces are instantiated > within the process in which the client resides, and they provide > access > to the underlying security infrastructure to the client. The > Credentials > objects that pass through the operations of these interfaces are > local > to the process in which they are instantiated. The security > information > contained in those credentials objects eventually find their way > inside > the ORB, but the details of how that happens has been left > unspecified > on purpose because specifying that would start nailing down the > impementation too much, which is a no-no. > So, the client application is a server as well since it has and must manage the PrincipleAuthenticator, AuditDecision, AccessPolicy, etc... and this is to be linked in with the rest of the client side of security. Once again, I find this distressing that we are forcing the client application to act as a server to objects. If these objects are to remain in the client, why are they not pseudo-objects so we don't incur the overhead of making them distributed objects? Also, if Credentials can't be passed, then why isn't it a pseudo-object? This would make it impossible to pass Credentials without having to do anything special. > So, there is nothing wrong with the particular statement about the > locality constraint of Credentials objects. What is wrong with Draft > 02 > and earlier drafts is a lack of explanation of the overall > picture. We > are working hard on trying to fix that. > > Hope that helps. > > Jishnu. > -- > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs > Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 > Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA -- --------------------------------- Ken Geisinger Sr. Software Integration Engineer Concept Five Technologies, Inc --------------------------------- Return-Path: From: "David M. Chizmadia" To: Jishnu Mukerji , "'Ken Geisinger'" Cc: "security@omg.org" , "sec-rev@omg.org" , "rudell@concept5.com" , "adutta@concept5.com" , "mkatz@concept5.com" Subject: RE: Credentials in rev1.2 Date: Wed, 30 Jul 1997 09:51:46 -0400 With apologies to Jishnu, who probably have a more specific set of CORBA related comments, I'd like to respond to some of your queries from a more generic security perspective... -DMC ---------- From: Ken Geisinger[SMTP:kegeisi@concept5.com] Sent: Wednesday, July 30, 1997 8:43 AM To: Jishnu Mukerji Cc: security@omg.org; sec-rev@omg.org; rudell@concept5.com; adutta@concept5.com; mkatz@concept5.com Subject: Re: Credentials in rev1.2 < much background omitted > So, the client application is a server as well since it has and must manage the PrincipleAuthenticator, AuditDecision, AccessPolicy, etc... and this is to be linked in with the rest of the client side of security. Once again, I find this distressing that we are forcing the client application to act as a server to objects. If these objects are to remain in the client, why are they not pseudo-objects so we don't incur the overhead of making them distributed objects? Also, if Credentials can't be passed, then why isn't it a pseudo-object? This would make it impossible to pass Credentials without having to do anything special. * It is my understanding that the OMG is trying to piddle on PIDL (which * is the traditional mechanism for specifying psuedo-objects), so there * is a natural tendency to avoid *specifying* psuedo-objects where * possible. On the other hand, the specification makes it clear that * the objects should be locality constrained, which has the same effect * as specifying them as pseudo-objects without constraining implementations * and complicating language bindings. * * With respect to the client being a server, although I think I understand * the sentiment from an efficiency perspective, the statement is irrational * from a conceptual perspective (and remember that OMG specs are *supposed* * to operate primarily at the conceptual level). The greatest contribution * of the DOC paradigm is the fact that it enables multi-tier architectures * by defining the terms "client" and "server" only in terms of each other. * In a DOC system, it is perfectly sensible and quite likely that a single * entity may be both server to some entities and client of others. * * In the context of traditional security models, the clients that are * directly attached to Principals are in fact full fledged servers. They * are the "official" proxy of the user in the system and therefore MUST be * able to contain and control the information that uniquely defines that * user. In this, security probably does operate in a fashion that is * counter-intuitive to most existing system design patterns; however, that * doesn't mean that the security design pattern is wrong, simply that it * changes the ground rules for system design. This is consistent with the * aversion that most designers display towards security :-{ --------------------------------- Ken Geisinger Sr. Software Integration Engineer Concept Five Technologies, Inc --------------------------------- Return-Path: Sender: jis@fpk.hp.com Date: Wed, 30 Jul 1997 10:55:09 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: Ken Geisinger Cc: Jishnu Mukerji , security@omg.org, sec-rev@omg.org, rudell@concept5.com, adutta@concept5.com, mkatz@concept5.com Subject: Re: Credentials in rev1.2 References: <33DE4E21.F5CF2A90@concept5.com> <33DE6651.6AD9@fpk.hp.com> <33DF36C3.D2764F96@concept5.com> Ken Geisinger wrote: > > Jishnu Mukerji wrote: > > > > Ken Geisinger wrote: > > > > > > I think I found an inconsistency in the Security rev1.2 Draft02. > > > > > > Section 15.5.4[2] says "Credentials must not be exported to > other > > > processes..." and states that an exception must be raised if an > attempt > > > is made. > > > > > > Section 15.5.3[3] says that the PrincipleAuthenticator Object > creates a > > > Credential and "Its object reference is also returned so it can > be used > > > for other operations..." > > > > > > Section 15.5.7[12] Says that the AuditChannel object can recieve > a > > > Credential as does Vault (section 15.7.4[34]), AccessDecision > (section > > > 15.7.4[45], and AccessPolicy (section 15.6.4[17]) and that > > > SecurityContext returns a Credential (section 15.7.4[37]). > > > > > > So, either our poor client is a server to all of these > interfaces or > > > perhaps a clarification is required. I believe what was meant is > that > > > the Credential can not be exported to a non-security service > object an > > > can only be imported to the client an any service object on the > > > execution thread from a security service object or > pseudo-object. > > > "Security service objects" are those defined by the security > > > specification. > > > > The ORB infrastructure on the node in which the client is running > has > > indeed got to provide all of those interfaces to the client. The > client > > itself does not have to act as a server for any of these > interfaces. > > > > So, your saying 15.5.4[2] should have said "Credentials must not be > exported to other nodes...." and not "...exported to other > processes..." No. I am saying that the Credential (CORBA Objects) must not be exported outside of the "Process" or in RM-ODP terminology, the "Capsule" in which they are instantiated. The only consequence of this is that they cannot be accessed from outside the Capsule. This does not imply that the data associated with that interface may not be exported via suitable key/credentials management protocols to other capsules, where they can be accessed through a Credentials object that is loca to that capsule. This is just clean separation of interfaces from implementation and security token transmission protocols. > > The general model is as follows. The client runs in a process on a > > system. There is an ORB infrastructure in place on that system. > > Interfaces like the Vault, and SecurityContext are internal to the > ORB > > and are for all practical purposes library interfaces. The > Credentials > > that pass around there are internal to the ORB. The Client can > directly > > access only the Application level objects like > PrincipalAuthenticator, > > AuditDecision, AccessPolicy etc. Those interfaces are instantiated > > within the process in which the client resides, and they provide > access > > to the underlying security infrastructure to the client. The > Credentials > > objects that pass through the operations of these interfaces are > local > > to the process in which they are instantiated. The security > information > > contained in those credentials objects eventually find their way > inside > > the ORB, but the details of how that happens has been left > unspecified > > on purpose because specifying that would start nailing down the > > impementation too much, which is a no-no. > > > > So, the client application is a server as well since it has and must > manage the PrincipalAuthenticator, AuditDecision, AccessPolicy, > etc... > and this is to be linked in with the rest of the client side of > security. Once again, I find this distressing that we are forcing > the > client application to act as a server to objects. If these objects > are > to remain in the client, why are they not pseudo-objects so we don't > incur the overhead of making them distributed objects? Also, if > Credentials can't be passed, then why isn't it a pseudo-object? This > would make it impossible to pass Credentials without having to do > anything special. No. The client "application" is not a server (necessarily) to any of those objects. The process/capsule in which the client "application" executes also contains infrastructure that is provided by the Security Service vendor that supports these interfaces. The PrincipalAuthenticator, AuditDecision, AccessPolicy, etc., as well as the Credentials objects are all part of what you call the "rest of the client side" of security. As for passing Credentials, I don't see how one can maintain their integrity in transit without doing something special for them anyway, so I consider the point that you raise about this aspect moot. As for pseudo-objects, the Architecture Board has decreed that this term should be avoided as much as possible, since it is not a precisely defined term. Instead, the exact contraints that are placed on the specific object associated with the interface is to be spelled out clearly. This is what has been done (or at least a first attempt has been made towards that) in Draft D02. Further work is needed. BTW saying that an object is "locally-constrained" basically says that they are not distributed. From your comment above it seems that this meaning is the same as that you ascribe to the term "pseudo-object". Since the interface is defined in straight IDL we don't have to specify distinct language mappings for these interfaces, they use the standard language mapping, but are constrained in the spects clearly spelled out. Examples of constraints are "locally-constrained", "singleton" etc., which have to be enforced by the implementors of those objects. You are correct in stating that we should clarify which of the objects other than Credentials (i.e. e.g. PrincipalAutheticator, AccessDecision, AuditDecision etc. are also "locally-constrained", and that we will progressively in the upcoming drafts. As a matter of fact, some of them are not only locally constrained, but are also "singleton" (i.e. one per process/capsule). Incidentally, I think Dave Chizmadia's notes on this matter in the message that he sent in this thread is right on the mark. As usual, he states these things much better than I manage to do. Jishnu. -- Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA Return-Path: Date: Wed, 30 Jul 1997 13:01:49 -0400 From: Ken Geisinger Organization: Concept 5 Technologies To: Jishnu Mukerji CC: security@omg.org, sec-rev@omg.org, rudell@concept5.com, adutta@concept5.com, mkatz@concept5.com Subject: Re: Credentials in rev1.2 References: <33DE4E21.F5CF2A90@concept5.com> <33DE6651.6AD9@fpk.hp.com> <33DF36C3.D2764F96@concept5.com> <33DF55CD.1571@fpk.hp.com> Jishnu Mukerji wrote: > Jishnu, et. al., I have no problem with the intent of the Security model. Hopefully, we have people who are more familiar with the applicable security issues than I am or we are in big trouble ;). But, the point I am trying to make is that the current draft of the security specification remains unclear and therefore can be interpreted as being inconsistent. I was unaware that the OMG was moving away from specifying things as pseudo-objects. That is probably a good plan since it avoids the specific language binding issues. Is there some language binding changes since these objects are "locally contained"? The thing I'm trying to avoid here is unnecessary overhead on the client application. If we were to compile these interfaces and establish instances of object references to them, then we must incur the additional overhead of managing object references above what we typically need to manage objects. My use of the word "server" to describe this condition does not fit well with the OMG description of the world, but it does present a convenient viewpoint to those who have not implemented interfaces. Take the C++ environment. Typically, one must write an implementation object and then acquire an object reference to it. The object reference provides the bridge, so to speak, between the language/environment differences that could exist between clients and the implementation. The reference also provides for location transparency. These implementations must be managed and exist in a process which "listens" for messages on objects which it is managing. For convenience, I labeled this as a server since it acts as a servicer of requests to the contained objects. Now, I do not wish to impose all of this on a simple client. Which means, I'd rather not have an object reference to these "locally constrained" objects. It adds unnecessary overhead and therefore introduces inefficiencies. Is the OMG working on this problem? > Ken Geisinger wrote: > > > > Jishnu Mukerji wrote: > > > > > > Ken Geisinger wrote: > > > > > > > > I think I found an inconsistency in the Security rev1.2 > Draft02. > > > > [...snip...] > Jishnu. > -- > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs > Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 > Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA -- --------------------------------- Ken Geisinger Sr. Software Integration Engineer Concept Five Technologies, Inc --------------------------------- Return-Path: Sender: jon@sems.com Date: Wed, 30 Jul 1997 11:27:12 -0700 From: Jonathan Biggar Organization: Seagate Software NMSG To: Ken Geisinger Cc: Jishnu Mukerji , security@omg.org, sec-rev@omg.org, rudell@concept5.com, adutta@concept5.com, mkatz@concept5.com Subject: Re: Credentials in rev1.2 References: <33DE4E21.F5CF2A90@concept5.com> <33DE6651.6AD9@fpk.hp.com> <33DF36C3.D2764F96@concept5.com> <33DF55CD.1571@fpk.hp.com> <33DF737D.80CDFFF7@concept5.com> Ken Geisinger wrote: > My use of the word "server" to describe this condition does not > fit > well with the OMG description of the world, but it does present a > convenient viewpoint to those who have not implemented > interfaces. Take > the C++ environment. Typically, one must write an implementation > object > and then acquire an object reference to it. The object reference > provides the bridge, so to speak, between the language/environment > differences that could exist between clients and the > implementation. The > reference also provides for location transparency. These > implementations > must be managed and exist in a process which "listens" for messages > on > objects which it is managing. For convenience, I labeled this as a > server since it acts as a servicer of requests to the contained > objects. > Now, I do not wish to impose all of this on a simple > client. Which > means, I'd rather not have an object reference to these "locally > constrained" objects. It adds unnecessary overhead and therefore > introduces inefficiencies. Is the OMG working on this problem? What you really have here is a quality of implementation issue. To restate your concern, you don't want all of the stuff done by a "true" CORBA "server" to make it listen for incoming messages from the network when all you are doing is using the security credential interface. It is certainly feasible for an ORB implementation to avoid all of that overhead if the only object implementations currently active in the "client" process are all locally-constrained. Jon Biggar jon@sems.com Return-Path: From: "David M. Chizmadia" To: "'Ken Geisinger'" Cc: "security@omg.org" , "sec-rev@omg.org" , "rudell@concept5.com" , "adutta@concept5.com" , "mkatz@concept5.com" Subject: RE: Credentials in rev1.2 Date: Wed, 30 Jul 1997 15:04:19 -0400 ---------- From: Ken Geisinger[SMTP:kegeisi@concept5.com] Sent: Wednesday, July 30, 1997 1:02 PM To: Jishnu Mukerji Cc: security@omg.org; sec-rev@omg.org; rudell@concept5.com; adutta@concept5.com; mkatz@concept5.com Subject: Re: Credentials in rev1.2 Jishnu Mukerji wrote: > Jishnu, et. al., I have no problem with the intent of the Security model. Hopefully, we have people who are more familiar with the applicable security issues than I am or we are in big trouble ;). But, the point I am trying to make is that the current draft of the security specification remains unclear and therefore can be interpreted as being inconsistent. I was unaware that the OMG was moving away from specifying things as pseudo-objects. That is probably a good plan since it avoids the specific language binding issues. Is there some language binding changes since these objects are "locally contained"? The thing I'm trying to avoid here is unnecessary overhead on the client application. If we were to compile these interfaces and establish instances of object references to them, then we must incur the additional overhead of managing object references above what we typically need to manage objects. My use of the word "server" to describe this condition does not fit well with the OMG description of the world, but it does present a convenient viewpoint to those who have not implemented interfaces. Take the C++ environment. Typically, one must write an implementation object and then acquire an object reference to it. The object reference provides the bridge, so to speak, between the language/environment differences that could exist between clients and the implementation. The reference also provides for location transparency. These implementations must be managed and exist in a process which "listens" for messages on objects which it is managing. For convenience, I labeled this as a server since it acts as a servicer of requests to the contained objects. Now, I do not wish to impose all of this on a simple client. Which means, I'd rather not have an object reference to these "locally constrained" objects. It adds unnecessary overhead and therefore introduces inefficiencies. Is the OMG working on this problem? | I was tempted to respond to a number of your implementation issues, but | since my knowledge of implementation is probably on par with your | professed knowledge of security, I decided not to embarrass myself. I | do have two comments. First, the ambiguities you note do have to be | resolved in the next revision and Jishnu is striving mightily to do so. | Second, As far as your final question: it is not an OMG problem, it is | a security service vendor opportunity! There are no implementation | limits imposed on the realization of locality constrained objects, so | if you wish to have a particular performance profile in your security | service - TALK TO YOUR VENDOR. In your case, go down the hall, since | it has been emphatically asserted in my presence that your organization | has a CORBA Security Level 2 implementation ready for imminent release. | | Thinking through the problem a bit more, it seems to be a moot point, | since the easiest way to minimize the reference management overhead | would be to bundle all of the objects into one interface (which I think | is the unit of reference in CORBA). This limits the security related | references to 1, while providing rich access to the security objects. | Comments from the technically knowledgeable members of this list??? > Ken Geisinger wrote: > > > > Jishnu Mukerji wrote: > > > > > > Ken Geisinger wrote: > > > > > > > > I think I found an inconsistency in the Security rev1.2 > Draft02. > > > > [...snip...] > Jishnu. > -- > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs > Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 > Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA -- --------------------------------- Ken Geisinger Sr. Software Integration Engineer Concept Five Technologies, Inc -DMC Return-Path: Sender: jis@fpk.hp.com Date: Tue, 05 Aug 1997 16:27:29 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: Juergen Boldt Cc: sec-rev@omg.org, mkatz@concept5.com Subject: Re: issues634 References: <3.0.32.19970730104838.009e67c4@emerald.omg.org> > Issue 634: Credentials in Security rev 1.2 are inconsistent > Source: Concept 5 Technologies (Mr. Ken Geisinger, HREF="mailto:kegeisi@concept5.com">kegeisi@concept5.com) > Nature: Uncategorized > Severity: > Summary: Section 15.5.4[2], 15.5.3[3], 15.5.7[12]: what was meant is > that Credential cannot be exported to non-security service object, > can only be imported to client. > Resolution: > Actions taken: > 07/29/1997: received issue Since Credentials are locality constrained objects, i.e. object references to them cannot be exported outside the process in which they reside, it stands to reason that any other object that has an operation that has a Credentials or CredentialsList type parameter or return value must also be a locality constrianed object. this rule is violated in two cases as identified in Issues 649 and 650, and they will be fixed in resolution of those issues. The rest of the comments in this issue have been discussed ad-infinitum and explaination given in email discussions, and have no material effect on the security specification. Issue 634 is thus superseded by issues 649 and 650. Please close Issue 634 with an annoation noting this fact. Thanks. Jishnu. -- Jishnu Mukerji Systems Architect Open Systems Software Division Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA Return-Path: Date: Wed, 06 Aug 1997 08:25:19 -0400 From: Ken Geisinger Organization: Concept 5 Technologies To: sec-rev@omg.org CC: mkatz@concept5.com Subject: Re: issues634 References: <3.0.32.19970730104838.009e67c4@emerald.omg.org> <33E78CB1.144B@fpk.hp.com> Jishnu Mukerji wrote: > > > Issue 634: Credentials in Security rev 1.2 are inconsistent > > Source: Concept 5 Technologies (Mr. Ken Geisinger, kegeisi@concept5.com) > > Nature: Uncategorized > > Severity: > > Summary: Section 15.5.4[2], 15.5.3[3], 15.5.7[12]: what was meant > is > that Credential cannot be exported to non-security service object, > can > only be imported to client. > > Resolution: > > Actions taken: > > 07/29/1997: received issue > > Since Credentials are locality constrained objects, i.e. object > references to them cannot be exported outside the process in which > they > reside, it stands to reason that any other object that has an > operation > that has a Credentials or CredentialsList type parameter or return > value > must also be a locality constrianed object. this rule is violated in > two > cases as identified in Issues 649 and 650, and they will be fixed in > resolution of those issues. > Does this mean that PrincipleAuthenticator, Vault, SecurityContext, and AccessDecision are also locality constrained? If so, can this be added to the specification for clarity? > The rest of the comments in this issue have been discussed > ad-infinitum > and explaination given in email discussions, and have no material > effect > on the security specification. > > Issue 634 is thus superseded by issues 649 and 650. Please close > Issue > 634 with an annoation noting this fact. > > Thanks. > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > Open Systems Software Division > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs > Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 > Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA -- --------------------------------- Ken Geisinger | The opinions expressed above are my own Sr. Software Integration Engineer| and not necessarily those of the company Concept Five Technologies, Inc | to which I am employed. --------------------------------- Return-Path: Sender: jis@fpk.hp.com Date: Wed, 06 Aug 1997 11:03:24 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: Ken Geisinger Cc: sec-rev@omg.org, mkatz@concept5.com Subject: Re: issues634 References: <3.0.32.19970730104838.009e67c4@emerald.omg.org> <33E78CB1.144B@fpk.hp.com> <33E86D2F.AEFE6070@concept5.com> Ken Geisinger wrote: > > Jishnu Mukerji wrote: > > > > > Issue 634: Credentials in Security rev 1.2 are inconsistent > > > Source: Concept 5 Technologies (Mr. Ken Geisinger, kegeisi@concept5.com) > > > Nature: Uncategorized > > > Severity: > > > Summary: Section 15.5.4[2], 15.5.3[3], 15.5.7[12]: what was > meant is > > that Credential cannot be exported to non-security service object, > can > > only be imported to client. > > > Resolution: > > > Actions taken: > > > 07/29/1997: received issue > > > > Since Credentials are locality constrained objects, i.e. object > > references to them cannot be exported outside the process in which > > they > > reside, it stands to reason that any other object that has an > > operation > > that has a Credentials or CredentialsList type parameter or return > > value > > must also be a locality constrianed object. this rule is violated > in > > two > > cases as identified in Issues 649 and 650, and they will be fixed > in > > resolution of those issues. > > > > Does this mean that PrincipleAuthenticator, Vault, SecurityContext, > and > AccessDecision are also locality constrained? If so, can this be > added > to the specification for clarity? Yup. Jishnu. -- Jishnu Mukerji Systems Architect Open Systems Software Division Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA