[SAGA-RG] Context attributes

[Andre Merzky]

Hi Ceriel, 

Quoting [Ceriel Jacobs] (Feb 20 2009):
> 
>Andre Merzky wrote:
>> Hi Ceriel,
>>
>> Quoting [Ceriel Jacobs] (Feb 06 2009):
>>> Andre Merzky wrote:
>>>
>>>> Again: saga::context instance is not supposed to allow
>>>> the user to create a credential on API level, or to
>>>> manage it, etc - it is solely supposed to _point_ to an
>>>> existing credential, and to deliver additional
>>>> information about it, if available (such as lifetime).
>>>> 
>>>> So, there is no reason not to allow the implementation to
>>>> attach additional information, or state attributes, or
>>>> whatever to the context internally.  In fact, the
>>>> implementation may need to do credential management - and
>>>> these actions are not expressed at API level at all.
>>> 
>>> There recently was an issue with the JavaGAT
>>> implementation, see
>>> https://mail.cct.lsu.edu/mailman/private/gat-devel/2008-December/001234.html,
>>> where an application has a GSSCredential object and needs
>>> to use that object for authentication to a GRAM.
>>> Currently, there is no way in SAGA to deal with this
>>> situation. A SAGA context extends SAGA attributes, and
>>> attributes only deal with strings. So, I guess that even
>>> allowing only string-string attributes in the API can
>>> already be a problem.
>>
>> Can't the JavaSAGA implementation recreate the same
>> GSSCredential object within the adaptor?  
> 
> How would you do that? The application would have
> to create a SAGA context for it? Can you create a
> SAGA context from any GSSCredential and then
> create a new GSSCredential for it with exactly the
> same info?

I do not know the GGS-API intimitately, so hope my answer is
not too much off target... ;-)

AFAIK, the GSS-API has indeed means to serialize a
credential into a string, and to de-serialize it.  But that
is not what I mean.

Rather, I assume the application needs some information to
create the original GSSContext instance, such as the
mech(anism) to use, the UserID, etc.  IIUC, these
information can also be retrieved from any previously
instantiated credential (in case the application gets the
credential passed form another library or so).

What I would hope is that this set of information can be
passed to the saga::context, via the attribute interface,
and that the adaptor can create a GSS credential in just the
same way as the original application did.

AFAICS, the following attributes would match directly

  saga context: Type     - gss: desired_mechs
  saga context: UserID   - gss: desired_name
  saga context: LifeTime - gss: lifetime_req

Everything else seems to be set GSS implementation specific,
e.g. via environment variables etc.

So, in pseudocode:

  saga::context gss-to-saga (const gss_cred_id_t & gss_cred)
  {
    char             type [256];
    char             name [256];
    unsigned int     lifetime; 
    gss_OID_set      mechset;
    gss_cred_usage_t usage;

    unsigned int     major;
    unsigned int     minor;

    major = OM_uint32 gss_inquire_cred (&minor
                                        gss_cred, 
                                        name, 
                                        &lifetime,
                                        &usage, 
                                        &mechset);

    // simply use the first mech id.  Ideally, one would
    // iterate over the mechs, and either return the first
    // which can be used to create a context, or even retrun
    // a list of contexts, one per mech type
    major = gss_oid_to_str (&minor, mechset->elements, type);

    saga::context c (type);
    c.set_attribute ("UserID", name);
    c.set_defaults  ();

    return c;
  }


Maybe I misunderstand the reason why the implementation you
refer to wants to pass the credential to SAGA though.  If,
for example, an adaptor wants to reuse a context which was
added to the GSS credential, e.g. to authenticate messages
on an IO channel, then that would not be supported by the
mechanism above.  But, then again, the sharing of IO
channels between the SAGA implementation and the application
is not supported in the first place, so that does not seem
to be a valid use case either...

Best, Andre.

  Andre.



-- 
Nothing is ever easy.