my view on execution user and group
The concrete use case I have from Globus is to indicate under which POSIX username a job should be executed. I see group (actually, default or primary group) as a reasonable extension of the concept, though we do not do that today. This use case is job configuration details, just like POSIX limits, environment variables, etc. It is important in situations where there is not a one-to-one mapping of global user identity (PKI subject) to local accounts for the GRAM service to apply, e.g. when a user has several role-specific accounts or temporary "scratch" accounts. Of course, such configuration values are subject to authorization checks in practice. I am not clear on whether this is the intended purpose of the existing user and group fields in the User section, but if it is not then I am not clear on what it is for at all... I admit my bias is towards thinking of the use of JSDL in distributed protocols like GRAM. I guess if we were to use it in the local "adapter" interface between the GRAM service and the local scheduler scripts, we might have a use for specifying the authenticated user name, which for GRAM would be a PKI subject name. This makes sense because the adapter scripts inherently trust GRAM; GRAM would reject the presence of such a field in the over-the-wire transmission of JSDL, since the user identification comes from the binding-level security mechanisms. I can see this kind of info belonging in a User section for the adapter case, but I still need the POSIX username in the executable section. karl -- Karl Czajkowski karlcz@univa.com
...again, any other thoughts on this? Thanks in advance, Ali On Wed, 30 Mar 2005, Karl Czajkowski wrote:
The concrete use case I have from Globus is to indicate under which POSIX username a job should be executed. I see group (actually, default or primary group) as a reasonable extension of the concept, though we do not do that today. This use case is job configuration details, just like POSIX limits, environment variables, etc. It is important in situations where there is not a one-to-one mapping of global user identity (PKI subject) to local accounts for the GRAM service to apply, e.g. when a user has several role-specific accounts or temporary "scratch" accounts. Of course, such configuration values are subject to authorization checks in practice.
I am not clear on whether this is the intended purpose of the existing user and group fields in the User section, but if it is not then I am not clear on what it is for at all...
I admit my bias is towards thinking of the use of JSDL in distributed protocols like GRAM. I guess if we were to use it in the local "adapter" interface between the GRAM service and the local scheduler scripts, we might have a use for specifying the authenticated user name, which for GRAM would be a PKI subject name. This makes sense because the adapter scripts inherently trust GRAM; GRAM would reject the presence of such a field in the over-the-wire transmission of JSDL, since the user identification comes from the binding-level security mechanisms. I can see this kind of info belonging in a User section for the adapter case, but I still need the POSIX username in the executable section.
karl
-- Karl Czajkowski karlcz@univa.com
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
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.
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.
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. 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. -- 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.
Hi Chris,
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.
Will a POSIX user ID in the Application section satisfy your use-case? If not, can you please suggest a more concrete definition for a user element that would satisfy your use-case? There is currently no definition for the UserCredential element in the Spec, but, there is one for UserGroup - anyone able to explain this? The UserGroup element's definition says that it contains the credentials necessary to run the job in a Grid!
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
I agree with Chris here. It doesn't make sense to have credentials in the JSDL. We decided in Berlin that security and credentials were out of JSDL's scope. We shouldn't let them creep back in! Cheers, Ali
products, I'm feeling this first hand.
-- 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.
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
I agree with Chris. I would even suggest put the POSIX user ID and group ID elements in the <application-executable/> (If that's what we have decided to call) section than the wrapping <application/> section, because it's quite 'binary job' specific. William On 31 Mar 2005, at 10:59, Ali Anjomshoaa wrote:
Hi Chris,
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.
Will a POSIX user ID in the Application section satisfy your use-case? If not, can you please suggest a more concrete definition for a user element that would satisfy your use-case?
There is currently no definition for the UserCredential element in the Spec, but, there is one for UserGroup - anyone able to explain this? The UserGroup element's definition says that it contains the credentials necessary to run the job in a Grid!
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
I agree with Chris here. It doesn't make sense to have credentials in the JSDL. We decided in Berlin that security and credentials were out of JSDL's scope. We shouldn't let them creep back in!
Cheers,
Ali
products, I'm feeling this first hand.
-- 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.
--
---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
--- William Lee @ London e-Science Centre, Imperial College London -- --- Software Coordinator --- A: Room 380, Department of Computing, Imperial College London, Huxley Building, South Kensington campus, London SW7 2AZ, UK E: wwhl@doc.ic.ac.uk | william@imageunion.com W: www.lesc.ic.ac.uk | www.imageunion.com P: +44(0)20 7594 8251 F: +44(0)20 7581 8024 --- Projects ---------------------------- GridSAM: http://www.lesc.ic.ac.uk/gridsam Markets: http://www.lesc.ic.ac.uk/markets ICENI: http://www.lesc.ic.ac.uk/iceni -----------------------------------------
I am fine with removing the UserCredential, this can be an extension that someone can put in if they please. BUT I still think we need a User Element with UserName (uid) and Group (gid) in it. These are common in all types of Jobs not just POSIX Application runs. Additionally they can and should be used in the data staging area. Darren -----Original Message----- From: Ali Anjomshoaa [mailto:ali@epcc.ed.ac.uk] Sent: Thursday, March 31, 2005 2:59 AM To: Christopher Smith Cc: Darren Pulsipher; 'Donal K. Fellows'; jsdl-wg@gridforum.org Subject: Re: [jsdl-wg] my view on execution user and group Hi Chris,
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.
Will a POSIX user ID in the Application section satisfy your use-case? If not, can you please suggest a more concrete definition for a user element that would satisfy your use-case? There is currently no definition for the UserCredential element in the Spec, but, there is one for UserGroup - anyone able to explain this? The UserGroup element's definition says that it contains the credentials necessary to run the job in a Grid!
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.
-- 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
I agree with Chris here. It doesn't make sense to have credentials in the JSDL. We decided in Berlin that security and credentials were out of JSDL's scope. We shouldn't let them creep back in! Cheers, Ali 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.
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
Thanks for this Darren, can you define more concretely what your suggested UserName (uid) and Group (gid) are if they are more general than just for POSIX applications? I had a chat with a few of the database guys around here and, for databases for example, each database has its own definition of a "user". So if we had a generic <User> element that one could use for mapping to databases, it would be differently interpreted and used by different systems. I think the same is true for file permissions depending on the file system type. So a generic User element would inhibit interoperability and may even be dangerous, say if all the job requirements were satisfied, but, the "wrong" user type was sent to an undesired database. You could find yourself having access to someone elses data! Well, that's a wild example, but. These issues could be answered by having the matching to the concrete user on the end-system be done through the security context. OGSA-DAI use security certificates and the credentials are mapped to local users of various databases in a manner specific to each database type - a more secure user mapping I think. You could imagine that for accounting also, the <User> element could be taken out of the security context. Accounting was one of my use-cases for having a <User> element. I imagine that in the Web Service world also, different protocols or architectures will define user in different ways. So perhaps this user thing does belong in the security context outside JSDL? Just a question? Cheers, Ali On Thu, 31 Mar 2005, Darren Pulsipher wrote:
I am fine with removing the UserCredential, this can be an extension that someone can put in if they please.
BUT I still think we need a User Element with UserName (uid) and Group (gid) in it. These are common in all types of Jobs not just POSIX Application runs. Additionally they can and should be used in the data staging area.
Darren
-----Original Message----- From: Ali Anjomshoaa [mailto:ali@epcc.ed.ac.uk] Sent: Thursday, March 31, 2005 2:59 AM To: Christopher Smith Cc: Darren Pulsipher; 'Donal K. Fellows'; jsdl-wg@gridforum.org Subject: Re: [jsdl-wg] my view on execution user and group
Hi Chris,
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.
Will a POSIX user ID in the Application section satisfy your use-case? If not, can you please suggest a more concrete definition for a user element that would satisfy your use-case?
There is currently no definition for the UserCredential element in the Spec, but, there is one for UserGroup - anyone able to explain this? The UserGroup element's definition says that it contains the credentials necessary to run the job in a Grid!
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
I agree with Chris here. It doesn't make sense to have credentials in the JSDL. We decided in Berlin that security and credentials were out of JSDL's scope. We shouldn't let them creep back in!
Cheers,
Ali
products, I'm feeling this first hand.
-- 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.
--
---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
On 31/3/05 01:59, "Ali Anjomshoaa" <ali@epcc.ed.ac.uk> 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.
Will a POSIX user ID in the Application section satisfy your use-case? If not, can you please suggest a more concrete definition for a user element that would satisfy your use-case?
That would definitely be good enough for me, as it is very much tied to the notion of executing a process. -- Chris
Hi, First off, a brief introduction. I've been lurking on this mailing list for a couple of months but not reading too many of the posts. I'm doing a PhD on task scheduling for computational grids and now realize I should have been following JSDL discussions a little more closely. A few comments on the 0.9.5-01 specification from someone who has never looked at it before: Figure 1: Job Manager/Scheduler has two directed arrows and JSDL bubbles for both. None of the other "links" do. I sort of understand why this might be, but really it just looks confusing. Namespaces: You have probably already had lots of discussion on namespaces. There can be problems with forwards and backwards compatibility of schemas if you make the namespace the same as a resolvable URL. Things like "bug compatibility, processing repeatability, existing JSDL documents, existing JSDL-aware services all come into play. My 2 cents would be that date-based versioning is a good idea, and that you should not get some kind of philosophical hang-up about versioning and namespaces (e.g. "But the *plan* says that version 2.0 will come out in 6 months time!"). Transparent schema changes which keep the same namespace are typically OK so long as: 1. All systems using the schema can be updated "instantly"; and, 2. Any formerly-valid instance document is still valid. This amounts to "Minor changes result from a relaxing of schema constraints" (e.g. a mandatory element or attribute is now optional) Any schema changes which would invalidate existing valid instance documents really mean you need to change the namespace (major version change). Plethora of "Job Languages" in order for job submission to work: My gut feeling is that you are dreaming if you think all these "envisioned" languages will independently materialize and precisely manage to interface -- that is, have consistent semantics, not overlap, and not leave any gaps. Isn't it necessary for one group to try to grapple with all these issues together in one place? Just labling the issues as "out of scope" may result in a situation where JSDL is sufficiently incomplete as to be unuseable in practice, which would be ashame. It is, of course, extremely valuable to have identified and decomposed the "big picture" into these sub-requirements. Numerical Operators: It is not at all clear to me what the following sentence or the example XML are supposed to indicate: "Numerical operators can be used through the general XML extensibility mechanism. For example:" Is that to say JSDL asserts "There shall be no numerical operators", or that JSDL simply doesn't have anything to say about numerical operators? What is the point of listing 5 operators but then having a 6th in the example XML (greater than >)? I also don't see what "general XML extensibility mechanism" has to do with anything. Comment: Your pseudo-schemas are very nice. Glad you opted *not* to include the raw XSDL, which generally obscures the structure it represents very effectively. Normative XML Schema Types: It is not clear to me what you mean by this section. For example, what is xsd:any##other? or "Complex"? Is that to say those are the only types you allow? Surely not, but then what does 4.2.1 mean? I don't think 4.2.1 adds anything to the specification. I'm guessing you just mean "The following built-in XSDL types are used in JSDL ...", but so what? And "any##other" is not a type, nor is "Complex". OSType: That is an odd list. For example, you mix software versions with base operating system for Windows, but not for Linux. You even provide Windows 64-bit specialisation as a specific "OSType", but don't do the same for anything else. Surely elsewhere 64-bitedness or OS version will have to be "labelled" for other OSs' (e.g. "RedHat 7.3" or "RedHat Enterprise Linux", or "REL, 64-bit"). ExecutionGroupID, Hostname (and others bits): These seem to go against the idea that you are not going to support security aspects in JSDL, but then the user can assert groups or hostnames which may require a particular authorization token in order to access or complete the request. Something will need to provide a mapping which says "Use this token to be able to exec in group X or on host Y", don't you think? jsdl: namespace prefix: In the examples, sometimes it is used and sometimes it isn't. If there is a reason for that, it isn't clear to me. Final comment: it would be nice to have a single tabular summary of all the "elements" in JSDL along with: cardinality (*,+,?, etc.) description parent element data type (string, numeric, enumeration, etc.) Maybe alternately organizing this list alphabetically, but grouped by element "category" would be useful. THe current "sections" format is very difficult to scan to pick out useful information. Regards, Ian. Ali Anjomshoaa wrote:
There is currently no definition for the UserCredential element in the Spec, but, there is one for UserGroup - anyone able to explain this? The UserGroup element's definition says that it contains the credentials necessary to run the job in a Grid!
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
I agree with Chris here. It doesn't make sense to have credentials in the JSDL. We decided in Berlin that security and credentials were out of JSDL's scope. We shouldn't let them creep back in! -- Ian Stokes-Rees i.stokes-rees@physics.ox.ac.uk Particle Physics, Oxford http://www-pnp.physics.ox.ac.uk/~stokes
Hi Ian, My 2 cents.
Namespaces: You have probably already had lots of discussion on namespaces. There can be problems with forwards and backwards compatibility of schemas if you make the namespace the same as a resolvable URL. Things like "bug compatibility, processing repeatability, existing JSDL documents, existing JSDL-aware services all come into play. My 2 cents would be that date-based versioning is a good idea, and that you should not get some kind of philosophical hang-up about versioning and namespaces (e.g. "But the *plan* says that version 2.0 will come out in 6 months time!"). Transparent schema changes which keep the same namespace are typically OK so long as:
I'm not sure what you mean by "namespace the same as a resolvable URL". The namespace "http://www.ggf.org/namespaces/2005/03/jsdl-o.9.4.xsd" is just an URI, it has no meaning apart from a string that satisfies the required URI syntax. Whether or not that "http://..." string resolves to a network resource or not is not implied and often a cause for confusion. By the way, there is a typo in the schema (version 0.9.4 on gridforge), the namespace attribute reads <xsd:schema ... xmlns="http://www.ggf.org/namespaces/2005/03/jsdl-o.9.4.xsd" ....> spot "..jsdl-o.9.4.xsd", I think it should read "..jsdl-0.9.4.xsd". (Did you see that?)
Numerical Operators: It is not at all clear to me what the following sentence or the example XML are supposed to indicate:
"Numerical operators can be used through the general XML extensibility mechanism. For example:"
I agree the "Numerical Operators" section is a bit out-of-place, maybe this can be action for the call to see whether we need to explicitly say in the spec. something that is NOT going to be included in this version.
Normative XML Schema Types: It is not clear to me what you mean by this section. For example, what is xsd:any##other? or "Complex"? Is that to say those are the only types you allow? Surely not, but then what does 4.2.1 mean? I don't think 4.2.1 adds anything to the specification. I'm guessing you just mean "The following built-in XSDL types are used in JSDL ...", but so what? And "any##other" is not a type, nor is "Complex".
Shall we just say in the spec any type that is defined with the http://www.w3.org/2001/XMLSchema xsd namespace has the semantic defined in the "XSD Schema Part 2: Data Type" recommendation.
Final comment: it would be nice to have a single tabular summary of all the "elements" in JSDL along with:
cardinality (*,+,?, etc.) description parent element data type (string, numeric, enumeration, etc.)
I'll let Andreas or the list to decide on that. Here is one I've prepared (from the schema on gridforge - version 0.9.4 - 15th March 2005) using the Oxygen tool, which you might find useful. http://www.doc.ic.ac.uk/~wwhl/download/jsdl.html William --- William Lee @ London e-Science Centre, Imperial College London -- --- Software Coordinator --- A: Room 380, Department of Computing, Imperial College London, Huxley Building, South Kensington campus, London SW7 2AZ, UK E: wwhl@doc.ic.ac.uk | william@imageunion.com W: www.lesc.ic.ac.uk | www.imageunion.com P: +44(0)20 7594 8251 F: +44(0)20 7581 8024 --- Projects ---------------------------- GridSAM: http://www.lesc.ic.ac.uk/gridsam Markets: http://www.lesc.ic.ac.uk/markets ICENI: http://www.lesc.ic.ac.uk/iceni -----------------------------------------
Hi, I only have one follow-up comment to the replies I received: William Lee wrote:
I'm not sure what you mean by "namespace the same as a resolvable URL". The namespace "http://www.ggf.org/namespaces/2005/03/jsdl-o.9.4.xsd" is just an URI, it has no meaning apart from a string that satisfies the required URI syntax. Whether or not that "http://..." string resolves to a network resource or not is not implied and often a cause for confusion.
Namespace are confusing, period. I have worked with XML for several years and still find it difficult to get my head around all the rules for scoping, schema declarations, default NSs, null NS, chameleon NSs, attribute vs. element NSs, etc. My reading of xml-dev general-opinion and (the xsdl-dev mailing list when I used to read it) is that everyone agrees it was a mistake to use "http://..." for something which *looks* like a URL but, in fact, is just a URI and does not (nor perhaps ever will) actually resolve. It is ashame that this has not been embded in the XSDL Schema primer and has been widely adopted. My very strong recommendation would be (in this order): 1. Definitely do not put ".xsd" at the end of the NS. That 100% looks like you are giving a NS with a one-to-one mapping to a resolvable URL to the schema for that namespace. 2. Do not put "http://" at the start. Use "uri:" or "urn:" instead. 3. If you do you "http://" or "*.xsd" then make sure it *does* resolve to something, probably to the "master" or "top-level" schema file. A not-altogether-bad approach might be to have (for example) urn:www.ggf.org/schemas/jsdl/2005/04 and then convince someone that the URL: http://www.ggf.org/schemas/jsdl/2005/04/ should provide some information about where to actually find the various XSD files (by set, by version, etc.) -- perhaps at: http://www.ggf.org/schemas/jsdl/2005/04/jsdl-2005-04.xsd (yes, I know, for redundant see redundant, but it means if the file is copied locally it still has a sensible name). Anyway, just my thoughts on this. Cheers, Ian. -- Ian Stokes-Rees i.stokes-rees@physics.ox.ac.uk Particle Physics, Oxford http://www-pnp.physics.ox.ac.uk/~stokes
Ian, You're preaching to the converted here. :^) Since JSDL is not the only specification embedded within OGSA and GGF, we've to be aware of what's decided within GGF. Currently, we're in the middle of unifying the namespaces used at GGF, and how to embed them in a larger scope than only JSDL. Cheers, Michel On 4 Apr 2005, at 14:49, Ian Stokes-Rees wrote:
Namespace are confusing, period. I have worked with XML for several years and still find it difficult to get my head around all the rules for scoping, schema declarations, default NSs, null NS, chameleon NSs, attribute vs. element NSs, etc.
My reading of xml-dev general-opinion and (the xsdl-dev mailing list when I used to read it) is that everyone agrees it was a mistake to use "http://..." for something which *looks* like a URL but, in fact, is just a URI and does not (nor perhaps ever will) actually resolve. It is ashame that this has not been embded in the XSDL Schema primer and has been widely adopted.
My very strong recommendation would be (in this order):
1. Definitely do not put ".xsd" at the end of the NS. That 100% looks like you are giving a NS with a one-to-one mapping to a resolvable URL to the schema for that namespace.
2. Do not put "http://" at the start. Use "uri:" or "urn:" instead.
3. If you do you "http://" or "*.xsd" then make sure it *does* resolve to something, probably to the "master" or "top-level" schema file.
A not-altogether-bad approach might be to have (for example)
urn:www.ggf.org/schemas/jsdl/2005/04
and then convince someone that the URL:
http://www.ggf.org/schemas/jsdl/2005/04/
should provide some information about where to actually find the various XSD files (by set, by version, etc.) -- perhaps at:
http://www.ggf.org/schemas/jsdl/2005/04/jsdl-2005-04.xsd
(yes, I know, for redundant see redundant, but it means if the file is copied locally it still has a sensible name).
Anyway, just my thoughts on this.
Cheers,
Ian.
-- Ian Stokes-Rees i.stokes-rees@physics.ox.ac.uk Particle Physics, Oxford http://www-pnp.physics.ox.ac.uk/~stokes
Ian Stokes-Rees wrote:
First off, a brief introduction. I've been lurking on this mailing list for a couple of months but not reading too many of the posts. I'm doing a PhD on task scheduling for computational grids and now realize I should have been following JSDL discussions a little more closely.
Hi! I'd like to start by telling you that standardization is very much about the art of the possible. Keep this in mind as you read my replies; it tells you much about why things are the way they are...
Figure 1: Job Manager/Scheduler has two directed arrows and JSDL bubbles for both. None of the other "links" do. I sort of understand why this might be, but really it just looks confusing.
Both figures need more work. (In this case, the two arrows are to indicate that the vision of the JM/S connection is in terms of JSDL rewriting.)
Namespaces: [...] 1. All systems using the schema can be updated "instantly"; and, 2. Any formerly-valid instance document is still valid.
I don't disagree. These things are not an issue *yet* as anyone using JSDL now really ought to be aware that they're using something that is pre-release and should be prepared to adapt what they're doing, but the issues clearly will matter going forward.
Plethora of "Job Languages" in order for job submission to work: My gut feeling is that you are dreaming if you think all these "envisioned" languages will independently materialize and precisely manage to interface -- that is, have consistent semantics, not overlap, and not leave any gaps. Isn't it necessary for one group to try to grapple with all these issues together in one place? Just labling the issues as "out of scope" may result in a situation where JSDL is sufficiently incomplete as to be unuseable in practice, which would be ashame. It is, of course, extremely valuable to have identified and decomposed the "big picture" into these sub-requirements.
Here's where what I said above about the "art of the possible" comes into play. The full picture of what you're talking about is both immensely contentious (perhaps more than it ought to be) and complex. We have tackled this by scoping right down what we are seeking to do so that we can get more people to buy into it (i.e. so that it is a standard; without buy-in, it's just a document gathering dust) and so that we can get relatively rapid agreement. The issues relating to the other areas of the job description and management picture are both more complex, and more heavily occupied by "armed camps". By scoping down as we have done, we have nearly finished a useful subset of the overall functionality (the previous situation at the ground level was dire, or perhaps even something of a joke) and a foundation from which to build the higher-level specs. Note that now that JSDL is just about there, there are moves afoot to get other groups going to fill in the other parts of the picture.
Numerical Operators: It is not at all clear to me what the following sentence or the example XML are supposed to indicate:
I think we could probably just drop that subsection entirely. The range scheme covers just about everything useful that isn't obscenely complex.
OSType: That is an odd list. For example, you mix software versions with base operating system for Windows, but not for Linux. You even provide Windows 64-bit specialisation as a specific "OSType", but don't do the same for anything else. Surely elsewhere 64-bitedness or OS version will have to be "labelled" for other OSs' (e.g. "RedHat 7.3" or "RedHat Enterprise Linux", or "REL, 64-bit").
That list of types is defined by the DMTF in CIM, and it is good politics to use external standards where appropriate. http://www.dmtf.org/standards/cim/cim_schema_v29 (I think it is over-specific, but there you go.)
ExecutionGroupID, Hostname (and others bits): These seem to go against the idea that you are not going to support security aspects in JSDL, but then the user can assert groups or hostnames which may require a particular authorization token in order to access or complete the request. Something will need to provide a mapping which says "Use this token to be able to exec in group X or on host Y", don't you think?
We used to have this mechanism (called Profiles) but we removed it. It belongs in the scope of other specs (e.g. WS-Agreement).
jsdl: namespace prefix: In the examples, sometimes it is used and sometimes it isn't. If there is a reason for that, it isn't clear to me.
That's a clean-up task to be done. ;-) Have you raised it as a tracker item on GridForge?
Final comment: it would be nice to have a single tabular summary of all the "elements" in JSDL along with:
That'd be nice, but it is something for a non-normative appendix and should only be done with a tool starting from our final-candidate schema. Or it could go in a Primer doc, of course. Donal.
Guys, here're my comments to this thread: On 3 Apr 2005, at 10:53, Donal K. Fellows wrote:
Ian Stokes-Rees wrote:
Numerical Operators: It is not at all clear to me what the following sentence or the example XML are supposed to indicate:
I think we could probably just drop that subsection entirely. The range scheme covers just about everything useful that isn't obscenely complex.
I second that. I think it's a left over from earlier versions of the spec.
ExecutionGroupID, Hostname (and others bits): These seem to go against the idea that you are not going to support security aspects in JSDL, but then the user can assert groups or hostnames which may require a particular authorization token in order to access or complete the request. Something will need to provide a mapping which says "Use this token to be able to exec in group X or on host Y", don't you think?
We used to have this mechanism (called Profiles) but we removed it. It belongs in the scope of other specs (e.g. WS-Agreement).
Donal, I think you missed what Ian said here. Profiles were not meant to provide different security tokens the way Ian outlined it. At least, they were not designed having that in mind; but they were certainly (ab)usable that way. :^) I think Ian meant something different: While JSDL claims to be a job dcescription language striving to scope out security issues (which we did not always do) there're still security related issues creeping in like ExecutonUserID. Well, IMHO I'd like to follow the "clean trail of purity" and kick these things out, bbut yu always have to consider the trade off between purity and usability. Vulgo, have a nice pure document that nobody will use or have a document that has its stains but is incredibly popular. :^) Also take in mind that standardised documents always represent comppromises on all ends of it. That's the inherent nature of standardisation bodies. :^)
jsdl: namespace prefix: In the examples, sometimes it is used and sometimes it isn't. If there is a reason for that, it isn't clear to me.
That's a clean-up task to be done. ;-) Have you raised it as a tracker item on GridForge?
It also has something to do with the style elements and types are defined in the schema. We need to find a stringent way with this.
Final comment: it would be nice to have a single tabular summary of all the "elements" in JSDL along with:
That'd be nice, but it is something for a non-normative appendix and should only be done with a tool starting from our final-candidate schema. Or it could go in a Primer doc, of course.
I agree to that one, too. Cheers, Michel
Michel
ExecutionGroupID, Hostname (and others bits): These seem to go against the idea that you are not going to support security aspects in JSDL, but then the user can assert groups or hostnames which may require a particular authorization token in order to access or complete the request. Something will need to provide a mapping which says "Use this token to be able to exec in group X or on host Y", don't you think?
We used to have this mechanism (called Profiles) but we removed it. It belongs in the scope of other specs (e.g. WS-Agreement).
Donal, I think you missed what Ian said here. Profiles were not meant to provide different security tokens the way Ian outlined it. At least, they were not designed having that in mind; but they were certainly (ab)usable that way. :^)
I think Ian meant something different: While JSDL claims to be a job dcescription language striving to scope out security issues (which we did not always do) there're still security related issues creeping in like ExecutonUserID.
Well, IMHO I'd like to follow the "clean trail of purity" and kick these things out, bbut yu always have to consider the trade off between purity and usability. Vulgo, have a nice pure document that nobody will use or have a document that has its stains but is incredibly popular. :^) Also take in mind that standardised documents always represent comppromises on all ends of it. That's the inherent nature of standardisation bodies. :^)
I don't see this as a purity issue. We put out of scope security saying that jsdl should be composed with some specialized language to describe those requirements. This is not the same as saying that jsdl should have no elements that might need such extra security assertions. So I can ask for machine with name X but whether I am allowed to use it or not (and what I have to provide to be able to use it) is a different issue and is out of scope. But asking for the machine or resource by name is a resource request and is in scope. (And I do hope such in-scope / out-of-scope statements don't sound too arbitrary. :-) Andreas
Andreas and others, On 4 Apr 2005, at 14:19, Andreas Savva wrote:
I don't see this as a purity issue. We put out of scope security saying that jsdl should be composed with some specialized language to describe those requirements. This is not the same as saying that jsdl should have no elements that might need such extra security assertions. So I can ask for machine with name X but whether I am allowed to use it or not (and what I have to provide to be able to use it) is a different issue and is out of scope. But asking for the machine or resource by name is a resource request and is in scope.
(And I do hope such in-scope / out-of-scope statements don't sound too arbitrary. :-)
Hmm, somehow I thought I was stating the same. Anyway, the way you stated it makes it much more clearer. Cheers, Michel
Michel I was partly objecting to the statement about 'purity' I guess. In any case it's good to know we agree. Michel Drescher wrote:
Andreas and others,
On 4 Apr 2005, at 14:19, Andreas Savva wrote:
I don't see this as a purity issue. We put out of scope security saying that jsdl should be composed with some specialized language to describe those requirements. This is not the same as saying that jsdl should have no elements that might need such extra security assertions. So I can ask for machine with name X but whether I am allowed to use it or not (and what I have to provide to be able to use it) is a different issue and is out of scope. But asking for the machine or resource by name is a resource request and is in scope.
(And I do hope such in-scope / out-of-scope statements don't sound too arbitrary. :-)
Hmm, somehow I thought I was stating the same. Anyway, the way you stated it makes it much more clearer.
Cheers, Michel
Donal K. Fellows wrote:
Ian Stokes-Rees wrote:
We used to have this mechanism (called Profiles) but we removed it. It belongs in the scope of other specs (e.g. WS-Agreement).
jsdl: namespace prefix: In the examples, sometimes it is used and sometimes it isn't. If there is a reason for that, it isn't clear to me.
For my observation the reason is that some elements are defined as global and some as local also using global types. IMHO, I don't like such practice. It is not good for implementation.
That's a clean-up task to be done. ;-) Have you raised it as a tracker item on GridForge?
Final comment: it would be nice to have a single tabular summary of all the "elements" in JSDL along with:
That'd be nice, but it is something for a non-normative appendix and should only be done with a tool starting from our final-candidate schema. Or it could go in a Primer doc, of course.
Simple solution - use XMLSpy Generate documentation and you will get all in order. Yuri
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.
On Apr 07, Yuri Demchenko loaded a tape reading: ...
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. ... 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
I think JSDL-WG is having a bit of an identity crisis (no pun intended) as to whether or how much security is in scope. I have heard statements that security mechanisms are out of scope, which I think means that any form of delegation or rights management is out of scope. To me, the reason we can include execution user and group ID is that they can be viewed (sideways, if you squint just right) as simple execution parameters. Requesting a particular executing user/group environment is not so different from asking for certain input, output, and executable files or working directories. It is a request that is subject to authentication and authorization in the messaging system within which the JSDL document fragments are embedded. I am still not sure whether Donal is suggesting that JSDL should explicitly call out a use of SAML, or whether he just raises the question of whether SAML would serve as a nice, standardized mechanism for expressing rights management in the open content "slots" in the JSDL document. (A "SAML in JSDL Profile" document could probably serve as a good rallying point for getting interop between different implementors of a future messaging standard that embraces JSDL.) karl -- Karl Czajkowski karlcz@univa.com
Karl Czajkowski wrote:
I am still not sure whether Donal is suggesting that JSDL should explicitly call out a use of SAML, or whether he just raises the question of whether SAML would serve as a nice, standardized mechanism for expressing rights management in the open content "slots" in the JSDL document. (A "SAML in JSDL Profile" document could probably serve as a good rallying point for getting interop between different implementors of a future messaging standard that embraces JSDL.)
The profile suggestion sounds a good official way of describing what I was thinking of. :^) Donal.
Donal K. Fellows wrote:
Karl Czajkowski wrote:
I am still not sure whether Donal is suggesting that JSDL should explicitly call out a use of SAML, or whether he just raises the question of whether SAML would serve as a nice, standardized mechanism for expressing rights management in the open content "slots" in the JSDL document. (A "SAML in JSDL Profile" document could probably serve as a good rallying point for getting interop between different implementors of a future messaging standard that embraces JSDL.)
The profile suggestion sounds a good official way of describing what I was thinking of. :^)
I completely agree with using relevant SAML features for carrying JSDL document's credibility. I would repeat my comment, also from our experience (sorry for using this argument :-) On Apr 07, Yuri Demchenko loaded a tape reading:
... 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.
And again repeating:
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.
of which SubjectConfirmation is optional. Yuri
On 7 Apr 2005, at 9:43, Karl Czajkowski wrote:
On Apr 07, Yuri Demchenko loaded a tape reading: ...
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. ... 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
I think JSDL-WG is having a bit of an identity crisis (no pun intended) as to whether or how much security is in scope. I have heard statements that security mechanisms are out of scope, which I think means that any form of delegation or rights management is out of scope.
Any information that directly relates to authentication or authorisation of the information stored in a JSDL instance document (yes, I promised to be clearer in my language...) should be handled in the embracing instance document (or by other means).
To me, the reason we can include execution user and group ID is that they can be viewed (sideways, if you squint just right) as simple execution parameters. Requesting a particular executing user/group environment is not so different from asking for certain input, output, and executable files or working directories. It is a request that is subject to authentication and authorization in the messaging system within which the JSDL document fragments are embedded.
Exactly.
I am still not sure whether Donal is suggesting that JSDL should explicitly call out a use of SAML, or whether he just raises the question of whether SAML would serve as a nice, standardized mechanism for expressing rights management in the open content "slots" in the JSDL document. (A "SAML in JSDL Profile" document could probably serve as a good rallying point for getting interop between different implementors of a future messaging standard that embraces JSDL.)
I think it is the latter (expressing rights management, that is). However, I'd prefer not "tainting" a JSDL instance document with security information in the open content "slots". Instead, I think of using references within an embracing instance document that associate certain security information to instance elements in the JSDL instance document. Cheers, Michel
Michel Drescher wrote:
On Apr 07, Yuri Demchenko loaded a tape reading:
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.
Any information that directly relates to authentication or authorisation of the information stored in a JSDL instance document (yes, I promised to be clearer in my language...) should be handled in the embracing instance document (or by other means).
I persistently want to draw your attention to the specific use case when users/customers require that all jobs submitted on behalf of them carry unbroken path of credentials/trust. This is a requirement to the Resource's processing environment to have this functionality and this can be achieved by including SubjectID and SubjConfData/Creds information. You may decide not to include this elements but then you probably need to explain this in the Security considerations section. If you move your JSDL doc from one su-exec/admin domain/host to another, you definitely need to worry about this kind of potential vulnerability. This is also outcome from ongoing EGEE operational security model development. Regards, Yuri
Yuri, many thanks for your contributions and discussions. Very valuable I assure you. If I understand your use-case, you envisage that a JSDL document will be passed around on a Grid, and thus, that this document needs to carry some reference to user ID and credentials for target resources to be able to carry out Authn and Authz. What we have been working on is a model where a JSDL document describes the core (i.e. resource and application) requirements of the job within a larger job context. That encompassing job context will, then, also include the security information for the job. For this reason we have put security issues, such as the specification of user credentials, firmly out of scope for JSDL. This has been done on the advice of the security gurus in GGF. I agree with them that a more general and widely applicable Grid-Security context should encompass a JSDL doc and not the other way round. In our model, then, you wouldn't be sending around JSDL docs, but job docs that have a larger scope than JSDL. A job doc would encompass a JSDL doc instance and carry security information, such as user credentials, as well as scheduling, policy, and Agreement information, etc. about that job. See Figure 2 in the JSDL spec (which for some reason doesn't show any security context! We'll need to fix that.) I hope my point is clear. Many thanks again for your feedback. Please continue on this line until we have ironed out the wrinkles. Cheers and take care, Ali On Thu, 7 Apr 2005, Yuri Demchenko wrote:
Michel Drescher wrote:
On Apr 07, Yuri Demchenko loaded a tape reading:
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.
Any information that directly relates to authentication or authorisation of the information stored in a JSDL instance document (yes, I promised to be clearer in my language...) should be handled in the embracing instance document (or by other means).
I persistently want to draw your attention to the specific use case when users/customers require that all jobs submitted on behalf of them carry unbroken path of credentials/trust.
This is a requirement to the Resource's processing environment to have this functionality and this can be achieved by including SubjectID and SubjConfData/Creds information.
You may decide not to include this elements but then you probably need to explain this in the Security considerations section.
If you move your JSDL doc from one su-exec/admin domain/host to another, you definitely need to worry about this kind of potential vulnerability.
This is also outcome from ongoing EGEE operational security model development.
Regards,
Yuri
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
I think we need to have the concept of User and Group most definitely but the question is where it needs to be. In the JSDL document it used to be in there but it was removed because it had some element of security and some where in favor of a more simplified standard. So as a group we have decided to at this time leave the out the User and Group as part of a User element and tie this specifically to the POSIX application. If implementators want to pass credential information they can use and extension mechanism to do that. Darren
Yuri,
many thanks for your contributions and discussions. Very valuable I assure you.
If I understand your use-case, you envisage that a JSDL document will be passed around on a Grid, and thus, that this document needs to carry some reference to user ID and credentials for target resources to be able to carry out Authn and Authz.
What we have been working on is a model where a JSDL document describes the core (i.e. resource and application) requirements of the job within a larger job context. That encompassing job context will, then, also include the security information for the job.
For this reason we have put security issues, such as the specification of user credentials, firmly out of scope for JSDL. This has been done on the advice of the security gurus in GGF. I agree with them that a more general and widely applicable Grid-Security context should encompass a JSDL doc and not the other way round.
In our model, then, you wouldn't be sending around JSDL docs, but job docs that have a larger scope than JSDL. A job doc would encompass a JSDL doc instance and carry security information, such as user credentials, as well as scheduling, policy, and Agreement information, etc. about that job. See Figure 2 in the JSDL spec (which for some reason doesn't show any security context! We'll need to fix that.)
I hope my point is clear.
Many thanks again for your feedback. Please continue on this line until we have ironed out the wrinkles.
Cheers and take care,
Ali
On Thu, 7 Apr 2005, Yuri Demchenko wrote:
Michel Drescher wrote:
On Apr 07, Yuri Demchenko loaded a tape reading:
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.
Any information that directly relates to authentication or authorisation of the information stored in a JSDL instance document (yes, I promised to be clearer in my language...) should be handled in the embracing instance document (or by other means).
I persistently want to draw your attention to the specific use case when users/customers require that all jobs submitted on behalf of them carry unbroken path of credentials/trust.
This is a requirement to the Resource's processing environment to have this functionality and this can be achieved by including SubjectID and SubjConfData/Creds information.
You may decide not to include this elements but then you probably need to explain this in the Security considerations section.
If you move your JSDL doc from one su-exec/admin domain/host to another, you definitely need to worry about this kind of potential vulnerability.
This is also outcome from ongoing EGEE operational security model development.
Regards,
Yuri
--
---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
We could have a POSIX extemsion in the user section allowing user and group information back in there. steve.. darren@pulsipher.org wrote:
I think we need to have the concept of User and Group most definitely but the question is where it needs to be. In the JSDL document it used to be in there but it was removed because it had some element of security and some where in favor of a more simplified standard.
So as a group we have decided to at this time leave the out the User and Group as part of a User element and tie this specifically to the POSIX application. If implementators want to pass credential information they can use and extension mechanism to do that.
Darren
Yuri,
many thanks for your contributions and discussions. Very valuable I assure you.
If I understand your use-case, you envisage that a JSDL document will be passed around on a Grid, and thus, that this document needs to carry some reference to user ID and credentials for target resources to be able to carry out Authn and Authz.
What we have been working on is a model where a JSDL document describes the core (i.e. resource and application) requirements of the job within a larger job context. That encompassing job context will, then, also include the security information for the job.
For this reason we have put security issues, such as the specification of user credentials, firmly out of scope for JSDL. This has been done on the advice of the security gurus in GGF. I agree with them that a more general and widely applicable Grid-Security context should encompass a JSDL doc and not the other way round.
In our model, then, you wouldn't be sending around JSDL docs, but job docs that have a larger scope than JSDL. A job doc would encompass a JSDL doc instance and carry security information, such as user credentials, as well as scheduling, policy, and Agreement information, etc. about that job. See Figure 2 in the JSDL spec (which for some reason doesn't show any security context! We'll need to fix that.)
I hope my point is clear.
Many thanks again for your feedback. Please continue on this line until we have ironed out the wrinkles.
Cheers and take care,
Ali
On Thu, 7 Apr 2005, Yuri Demchenko wrote:
Michel Drescher wrote:
On Apr 07, Yuri Demchenko loaded a tape reading:
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.
Any information that directly relates to authentication or
authorisation
of the information stored in a JSDL instance document (yes, I promised to be clearer in my language...) should be handled in the embracing instance document (or by other means).
I persistently want to draw your attention to the specific use case when users/customers require that all jobs submitted on behalf of them carry unbroken path of credentials/trust.
This is a requirement to the Resource's processing environment to have this functionality and this can be achieved by including SubjectID and SubjConfData/Creds information.
You may decide not to include this elements but then you probably need to explain this in the Security considerations section.
If you move your JSDL doc from one su-exec/admin domain/host to another, you definitely need to worry about this kind of potential vulnerability.
This is also outcome from ongoing EGEE operational security model development.
Regards,
Yuri
--
---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
-- -- ------------------------------------------------------------------------ Dr A. Stephen McGough http://www.doc.ic.ac.uk/~asm ------------------------------------------------------------------------ Technical Coordinator, London e-Science Centre, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8409 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------
participants (12)
-
Ali Anjomshoaa -
Andreas Savva -
Andrew Stephen McGough -
Christopher Smith -
Darren Pulsipher -
darren＠pulsipher.org
-
Donal K. Fellows -
Ian Stokes-Rees -
Karl Czajkowski -
Michel Drescher -
William Lee -
Yuri Demchenko