[saga-rg] Re: proposal for session handle
Andre Merzky
andre at merzky.net
Sun Jun 12 12:38:45 CDT 2005
The attachement eaters have striked again...
Anyway, here they are...
Andre
Quoting [Andre Merzky] (Jun 12 2005):
> Date: Sun, 12 Jun 2005 17:35:45 +0200
> From: Andre Merzky <andre at merzky.net>
> To: Simple API for Grid Applications WG <saga-rg at ggf.org>
> Subject: proposal for session handle
>
> Hi Saga,
>
> one of the topics which is still open in the strawman API is
> that of session handle and security handles.
>
> Attached to this mail is a proposal for each one. That is
> nothing fancy, but should serve until we have something
> better, or until we have use cases not implementable by
> them (for now, all uses cases should be ok AFAICS).
>
> Comments are invited! If there are no comments (or no
> negative ones ;-), I'd suggest to include both into the
> strawman API for re-iteration at GGF14.
>
> Cheers, Andre.
>
> For this with CVS access: i commited the files to CVS, but
> did not include them into the docs.
--
+-----------------------------------------------------------------+
| Andre Merzky | phon: +31 - 20 - 598 - 7759 |
| Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
| Dept. of Computer Science | mail: merzky at cs.vu.nl |
| De Boelelaan 1083a | www: http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands | |
+-----------------------------------------------------------------+
-------------- next part --------------
Context:
Proposal:
For encapsulating security information, a security
context is created and associated with a context (aka
session handle). The security context can hold
information about X509 certificates, privat/public keys,
username/password, kerberos tickets etc., and provides
these information to the SAGA implementation as needed.
A SAGA implementaqtion MAY be able to attache more than
one security context to one context.
+-------------------------------------------------------------+
Summary:
========
The Context provides the functionality of a session
handle. A context is created, and used as parameter to
ALL object instanciations. Multiple contexts can
co-exist. A single context can be shared between threads.
SAGA Objects created from other SAGA Objects inherit its
context.
A implementation CAN implement various types of Security
contexts. or just one type. The type of context to be
created is specified by a enum which is the only argument
to the Context constructor.
Every context has a specific set of attributes which can
be set/get via the SAGA attribute interface. Exactly what
attributes a Context offers depends on its type. A
context MUST issue an error if attributes not
corresponding to its type are set or requested.
+-------------------------------------------------------------+
Use Cases:
==========
Not applicable here; this is a general design decision.
+-------------------------------------------------------------+
API Summary:
============
API Summary:
package SAGA version 0.1 {
enum contextType {
X509 = 0,
SSH = 1,
Kerberos = 2,
UserPass = 3
};
interface Context extends-all SAGA.Attribute {
constructor (in contextType type);
getType (out contextType type);
}
}
+-------------------------------------------------------------+
API Detail:
===========
interface Context:
- constructor:
Purpose: create a security context
Format: create (in contextType type);
Inputs: type type of context to
create
Outputs: none
Throws: BadParameter: context type is not
supported.
- getType:
Purpose: query the context type
Format: getType (out contextType type);
Inputs: none
Outputs: type type of context
Throws: nothing
+-------------------------------------------------------------+
Examples:
=========
Context context;
File file (context);
File file2 = file.copy (location);
+-------------------------------------------------------------+
Notes:
======
- Following attributes MUST be supported by the
correponding context types:
X509:
X509_Proxy (/tmp/x509...)
X509_CertDir (/etc/grid-security/certificates/)
SSH
SSH_PrivKey ($HOME/.ssh/id_dsa)
SSH_PublKey ($HOME/.ssh/id_dsa.pub)
Kerberos
Kerberos_Ticket (/tmp/kticket...) ?
UserPass
UserPass_UserName (anonymous)
UserPass_Password (anon)
- Other types MAY be specified by a SAGA
implementation.
- Default values can be specified by a SAGA
implementation.
- Should we also specify the default values? Mostly
simple I guess. But then the defaults may differ per
platform and installation, so leaving that to the
implementation gives more flexibility...
+-------------------------------------------------------------+
Examples:
=========
Context context_1 (SSH); // default attribs apply
Context context_2 (UserPass);
context_2.setAttribute (UserName, "andre");
context_2.setAttribute (Password, "secret");
Session session;
session.addContext (context_1);
session.addContext (context_2);
File file (session);
-------------- next part --------------
Session:
Most libraries use session handles to distinguish scope
(security, settings, lifetime) of objects etc.
GAT used a Context object, which is a session handle
with attached information (security context, preferences)
and some methods (get 'self', init environment, current
status, ...).
Proposal: re-use what we have in GAT: falls back to the
well known paradigm of a session session handle), plus
give potential for a few more features (see above). For
simplicity, the session has no methods for now. They
will get added when schemes for preferences, security,
and status get defined.
+-------------------------------------------------------------+
Summary:
========
The session provides the functionality of a session
handle. A session is created, and used as parameter
to ALL object instanciations. Multiple contexts can
co-exist. A single session can be shared between threads.
SAGA Objects created from other SAGA Objects inherit its
session. Only some objects do not need a session handle
on creation time, and can hence be shared between
sessions. That includes:
- Context
- Utility classes
A Context (encapsulates security information) can be
attached to a Session. A SAGA implementation MAY allow
to attach more than one Context to a single Session.
+-------------------------------------------------------------+
Use Cases:
==========
Not applicable here; this is a general design decision.
+-------------------------------------------------------------+
API Summary:
============
API Summary:
package SAGA version 0.1 {
interface Session {
addContext (in Context context);
getContext (out array<Context> contexts);
}
}
+-------------------------------------------------------------+
API Detail:
===========
interface Session:
- addContext
Purpose: attach a security context to a session handle
Format: addContext (in Context context);
Inputs: context Security Context to add
Outputs: none
Throws: BadParameter: context is invalid,
IncorectState: implementation cannot
handle any more contexts
- getContexts
Purpose: retrieve all contexts attached to a session
Format: getContext (out array<Context>
contexts);
Inputs: none
Outputs: contexts list of contexts of this
session
Throws: nothing
Note: - a empty list is returned if no Context is
attached, yet.
+-------------------------------------------------------------+
Examples:
=========
Session session;
File file (session);
File file2 = file.copy (location);
+-------------------------------------------------------------+
More information about the saga-rg
mailing list