Christopher Smith wrote:
I think that retaining the user name and group is useful, as I have customer use cases where the template of a job is permanently attached to a particular user identity for execution, so I think I'd like to see these stay.
In our project Collaboratory.nl (CNL) that also makes use of Grid and GT we also use a Job description linked to user identity and their credentials. In some respect the CNL process flow requires that the JobDescription carries some kind of delegation from the user, e.g. User want that Grid processing environment maintains the trust/delegation path.
The management and establishment of credentials, on the other hand, is generally very dependent on the protocol being used and the specific context of the job submission itself, that it doesn't make sense to put this in a job description. Having just finished a project Kerberizing one of our products, I'm feeling this first hand.
Generally, from the security point of view just using User name is not enough. Ee need to put some kind of SubjectConfirmationData that cryptographically binds UserID and their credential or trusted Identity Provider's key. So, I would like to see User/Subject section having two elements UserID/SubjectID and SubjectConfirmationData that can be extensible and include any type of assertion, e.g. SAML, or simply cryptovalue. Referring to another comment by Donal on "Subj: Re: [jsdl-wg] my view on "user credentials"", I would say that using directly SAML assertion is too heavy solution. And actually SAML is used not for Subject identification but for Subject confirmation. Regards, Yuri
-- Chris
On 30/3/05 05:38, "Darren Pulsipher" <darren@pulsipher.org> wrote:
Ok my turn to say something about the User section.
The User Section is attached to the Job definition and the Data Staging areas for stage in and stage out.
I believe that we need to have Name, Group and some passthru for credentials (or an extension for such) not only for POSIX applications but for all different types of jobs. Web services typically have these concepts, sql would have it, AFS with security uses it etc...
If it is not put into the JobDefinition or the DataStaging areas then people will add it in through extensions all over the place. As most jobs require some kind of identification of the user that will be running jobs and moving data.
Putting this in the POSIX Application area is too limiting and does not allow for referencing the User in other sections easily. For example in a complex workflow where the user identity will change depending on the job that is run it would be beneficial to reference the Users that are defined potentially outside of the JobDefinition several times.
Any questions?
Darren
-----Original Message----- From: owner-jsdl-wg@ggf.org [mailto:owner-jsdl-wg@ggf.org] On Behalf Of Donal K. Fellows Sent: Wednesday, March 30, 2005 5:14 AM To: Ali Anjomshoaa Cc: jsdl-wg@gridforum.org Subject: Re: [jsdl-wg] my view on execution user and group
Ali Anjomshoaa wrote:
...again, any other thoughts on this?
I think Karl's got the interpretation of the ExecutionUser and ExecutionGroup elements right. I'd just add that I would expect most JSDL instances to not specify these elements, with the identity to execute the job as being either implicit within the submission security context or present explicitly through SAML/XACML elements. Our experience with UNICORE is that this functionality is only rarely useful (but invaluable in those situations, of course, so the elements are worth retaining).
Donal.