Hi All, John, the streams interface has a security info object, which allows to get information about the 'other' side of the stream. That overlaps somewhat with the context we intend to use to specify/query security information. Also, they are very similar: both are extending the attrributes interface, and specify a set of attributes to be supported. I'd like to propose to merge both, and use a read only context for security info in the stream interface. It makes sense to have dedicated GetXXX methods I think, for those attributes which are required. What do you think? Cheers. Andre. PS.: I know its summer, so you are probably all too lazy to dig through the doc for this :-) Here are the context and the security info: SecurityInfo: interface SecurityInfo extends-all SAGA.Attribute { /* These methods are shortcuts for typical * information that would be used to * make authorization decisions based on * connection information. However, the * the validity of the information is * dependent on the security model implementation. * Typically, the information is stored using * the SAGA.Attribute interface. The data * returned by the sample methods below are * also available via the Attribute interface. */ void getSourceUserName (out string name); void getSourceDN (out string DN); void getSourceHost (out string hostname); void getSourcePort (out int port); } Context: enum contextType { X509 = 0, SSH = 1, Kerberos = 2, UserPass = 3 }; interface Context extends-all SAGA.Attribute { constructor (in contextType type); getType (out contextType type); } -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
That sounds reasonable to me. My only concern (a minor concern) is that the underlying security information is actually different than the kind of information that is stored locally. (eg. its going to be a credential rather than a public/private key pair). So the way that we interact with the two kinds of security contexts is compatible (its reasonably represented as a list of key-value pairs), but the underlying object or information may in fact be different. -john On Jun 23, 2005, at 5:18 AM, Andre Merzky wrote:
Hi All, John,
the streams interface has a security info object, which allows to get information about the 'other' side of the stream.
That overlaps somewhat with the context we intend to use to specify/query security information. Also, they are very similar: both are extending the attrributes interface, and specify a set of attributes to be supported.
I'd like to propose to merge both, and use a read only context for security info in the stream interface. It makes sense to have dedicated GetXXX methods I think, for those attributes which are required.
What do you think?
Cheers. Andre.
PS.: I know its summer, so you are probably all too lazy to dig through the doc for this :-) Here are the context and the security info:
SecurityInfo:
interface SecurityInfo extends-all SAGA.Attribute { /* These methods are shortcuts for typical * information that would be used to * make authorization decisions based on * connection information. However, the * the validity of the information is * dependent on the security model implementation. * Typically, the information is stored using * the SAGA.Attribute interface. The data * returned by the sample methods below are * also available via the Attribute interface. */ void getSourceUserName (out string name); void getSourceDN (out string DN); void getSourceHost (out string hostname); void getSourcePort (out int port); }
Context:
enum contextType { X509 = 0, SSH = 1, Kerberos = 2, UserPass = 3 };
interface Context extends-all SAGA.Attribute {
constructor (in contextType type); getType (out contextType type);
}
-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
John Shalf wrote:
That sounds reasonable to me.
To me as well.
My only concern (a minor concern) is that the underlying security information is actually different than the kind of information that is stored locally. (eg. its going to be a credential rather than a public/private key pair). So the way that we interact with the two kinds of security contexts is compatible (its reasonably represented as a list of key-value pairs), but the underlying object or information may in fact be different.
Sorry for a possibly dumb question: Isn't this reflected in the contextType enum already? Regards Hartmut
-john
On Jun 23, 2005, at 5:18 AM, Andre Merzky wrote:
Hi All, John,
the streams interface has a security info object, which allows to get information about the 'other' side of the stream.
That overlaps somewhat with the context we intend to use to specify/query security information. Also, they are very similar: both are extending the attrributes interface, and specify a set of attributes to be supported.
I'd like to propose to merge both, and use a read only context for security info in the stream interface. It makes sense to have dedicated GetXXX methods I think, for those attributes which are required.
What do you think?
Cheers. Andre.
PS.: I know its summer, so you are probably all too lazy to dig through the doc for this :-) Here are the context and the security info:
SecurityInfo:
interface SecurityInfo extends-all SAGA.Attribute { /* These methods are shortcuts for typical * information that would be used to * make authorization decisions based on * connection information. However, the * the validity of the information is * dependent on the security model implementation. * Typically, the information is stored using * the SAGA.Attribute interface. The data * returned by the sample methods below are * also available via the Attribute interface. */ void getSourceUserName (out string name); void getSourceDN (out string DN); void getSourceHost (out string hostname); void getSourcePort (out int port); }
Context:
enum contextType { X509 = 0, SSH = 1, Kerberos = 2, UserPass = 3 };
interface Context extends-all SAGA.Attribute {
constructor (in contextType type); getType (out contextType type);
}
-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
Quoting [Hartmut Kaiser] (Jun 23 2005):
My only concern (a minor concern) is that the underlying security information is actually different than the kind of information that is stored locally. (eg. its going to be a credential rather than a public/private key pair). So the way that we interact with the two kinds of security contexts is compatible (its reasonably represented as a list of key-value pairs), but the underlying object or information may in fact be different.
Sorry for a possibly dumb question: Isn't this reflected in the contextType enum already?
My thought as well - that is at least the intent of the context type thingie. Do you think that is unsufficient? Cheers, Andre.
Regards Hartmut
-john
On Jun 23, 2005, at 5:18 AM, Andre Merzky wrote:
Hi All, John,
the streams interface has a security info object, which allows to get information about the 'other' side of the stream.
That overlaps somewhat with the context we intend to use to specify/query security information. Also, they are very similar: both are extending the attrributes interface, and specify a set of attributes to be supported.
I'd like to propose to merge both, and use a read only context for security info in the stream interface. It makes sense to have dedicated GetXXX methods I think, for those attributes which are required.
What do you think?
Cheers. Andre.
PS.: I know its summer, so you are probably all too lazy to dig through the doc for this :-) Here are the context and the security info:
SecurityInfo:
interface SecurityInfo extends-all SAGA.Attribute { /* These methods are shortcuts for typical * information that would be used to * make authorization decisions based on * connection information. However, the * the validity of the information is * dependent on the security model implementation. * Typically, the information is stored using * the SAGA.Attribute interface. The data * returned by the sample methods below are * also available via the Attribute interface. */ void getSourceUserName (out string name); void getSourceDN (out string DN); void getSourceHost (out string hostname); void getSourcePort (out int port); }
Context:
enum contextType { X509 = 0, SSH = 1, Kerberos = 2, UserPass = 3 };
interface Context extends-all SAGA.Attribute {
constructor (in contextType type); getType (out contextType type);
}
-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
On Jun 23, 2005, at 8:48 AM, 'Andre Merzky' wrote:
Quoting [Hartmut Kaiser] (Jun 23 2005):
My only concern (a minor concern) is that the underlying security information is actually different than the kind of information that is stored locally. (eg. its going to be a credential rather than a public/private key pair). So the way that we interact with the two kinds of security contexts is compatible (its reasonably represented as a list of key-value pairs), but the underlying object or information may in fact be different.
Sorry for a possibly dumb question: Isn't this reflected in the contextType enum already?
My thought as well - that is at least the intent of the context type thingie. Do you think that is unsufficient?
Sorry, I didn't read the rest of your email. (I'm hastily reading email during a meeting in Atlanta) The context type takes care of everything. -john
Great! Than, if you don't mind, I adjust the streams, and move what you wrote as documentation and example to the context, to make sure that that is completely covered there. Cheers, Andre. Quoting [John Shalf] (Jun 23 2005):
On Jun 23, 2005, at 8:48 AM, 'Andre Merzky' wrote:
Quoting [Hartmut Kaiser] (Jun 23 2005):
My only concern (a minor concern) is that the underlying security information is actually different than the kind of information that is stored locally. (eg. its going to be a credential rather than a public/private key pair). So the way that we interact with the two kinds of security contexts is compatible (its reasonably represented as a list of key-value pairs), but the underlying object or information may in fact be different.
Sorry for a possibly dumb question: Isn't this reflected in the contextType enum already?
My thought as well - that is at least the intent of the context type thingie. Do you think that is unsufficient?
Sorry, I didn't read the rest of your email. (I'm hastily reading email during a meeting in Atlanta) The context type takes care of everything.
-john
-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
OK. Thanks! -john On Jun 23, 2005, at 8:59 AM, Andre Merzky wrote:
Great! Than, if you don't mind, I adjust the streams, and move what you wrote as documentation and example to the context, to make sure that that is completely covered there.
Cheers, Andre.
Quoting [John Shalf] (Jun 23 2005):
On Jun 23, 2005, at 8:48 AM, 'Andre Merzky' wrote:
Quoting [Hartmut Kaiser] (Jun 23 2005):
My only concern (a minor concern) is that the underlying security information is actually different than the kind of information that is stored locally. (eg. its going to be a credential rather than a public/private key pair). So the way that we interact with the two kinds of security contexts is compatible (its reasonably represented as a list of key-value pairs), but the underlying object or information may in fact be different.
Sorry for a possibly dumb question: Isn't this reflected in the contextType enum already?
My thought as well - that is at least the intent of the context type thingie. Do you think that is unsufficient?
Sorry, I didn't read the rest of your email. (I'm hastily reading email during a meeting in Atlanta) The context type takes care of everything.
-john
-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
participants (4)
-
'Andre Merzky' -
Andre Merzky
-
Hartmut Kaiser -
John Shalf