Hi Steve, Paul, the set of context attributes is supposed to allow the user to point to a specific security token, in a wide set of environments. You are right: apart from 'Type', different grid environments will require different attributes to be set. For example, a MyProxy context would probably specify 'Server', 'UserID' and 'UserPass', while a X509 proxy context would point the 'UserProxy' attribute to the proxie's location in the file system. We hope that the set of attributes cover all currently used Grid middlewares (we had the OGF security area check the attributes for completeness). If not, that needs fixing. Note that these attributes are what the SAGA _user_ sees on API level, and what he is supposed to use to specify what token to use. In most cases (by far, e.g. 99%), the user should not need to set the attributes at all (apart from type possibly), and the SAGA implementation should be able to pick up the security tokens from default locations etc. It is a different story altogether on implementation level though: a context representation within the SAGA implementation may well keep additional attributes, like (for the examples above) the MyProxy server version, or the X509 proxy file checksum. That might be useful information for the implementation to keep, and to pass around with the context - but these attributes do not need exposure on API level (that is why the context attributes are not extensible). I think the latter is what causes confusion for Paul in the implementation (will send a separate mail on that on the devel list). Did I answer your questions? Cheers, Andre. Quoting [Steve Fisher] (Feb 05 2009):

I have had no response - does anybody know why this set of attributes has been defined?

Steve

2009/2/3 Steve Fisher <dr.s.m.fisher@gmail.com>:

...

Hi,

I have been looking at the spec for details of the Context class. I don't understand why it has specific attributes defined when only "Type" is common to all contexts. Attributes such as "Server", "CertRepository" etc should not be there. The implementation can document which attributes are needed. Have I missed something?

Steve

-- Nothing is ever easy.

Quoting [Steve Fisher] (Feb 06 2009):

2009/2/6 Andre Merzky <andre@merzky.net>:

...

Hi Steve, Paul,

the set of context attributes is supposed to allow the user to point to a specific security token, in a wide set of environments. You are right: apart from 'Type', different grid environments will require different attributes to be set. For example, a MyProxy context would probably specify 'Server', 'UserID' and 'UserPass', while a X509 proxy context would point the 'UserProxy' attribute to the proxie's location in the file system.

We hope that the set of attributes cover all currently used Grid middlewares (we had the OGF security area check the attributes for completeness). If not, that needs fixing.

In that case the list will just get longer and longer. I was simply suggesting that it would be better to only have the "Type" and then allowing other attributes to be specified by the user to match the implementation he plans to use. If the user explicitly creates a gLite context there is no point in setting more than the location of his proxy. At the moment he could try setting other attributes - expecting them to do something useful - but the implementation will ignore them or it could report an error if useless attributes are set.

You are right: the implementation should document what attributes it supports. However, a completely free attribute list may lead to glite using the 'Server' attribute, MyProxy using 'ServerName', and OMII using 'ServerContact' - a predefined list of supported attributes avoids that. It is a tradeoff though, I certainly agree that other solutions are possible.

...

It is a different story altogether on implementation level though: a context representation within the SAGA implementation may well keep additional attributes, like (for the examples above) the MyProxy server version, or the X509 proxy file checksum. That might be useful information for the implementation to keep, and to pass around with the context - but these attributes do not need exposure on API level

...

(that is why the context attributes are not > extensible).

Here I think you are confusing the API and the implementation. The attributes can be extensible - but should not be used by the implementation to cache information. If the implementation changes a context created by the user (other than the default one) such that the user can see that it has been changed - then that implementation is broken.

Why? If I point to a myproxy credential, and the implementation is refreshing that credential beyond its default lifetime w/o notifying the user, I don't think the implementation is broken. 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.

...

I think the latter is what causes confusion for Paul in the implementation (will send a separate mail on that on the devel list).

Yes I think that Paul was wrong to try to set the VO in the context as all the information is defined in the proxy. In fact what he needs to store is all the information unpacked from the proxy which for a VOMS proxy is more complex than can be represented easily by attributes - even if multi-valued. This should be a private structure and not visible to the user via the API.

Agree. Best, Andre.

However I am tying to keep my nose out of the C++ implementation.

Steve

-- Nothing is ever easy.

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? Andre.

Ceriel

-- Nothing is ever easy.

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.