my view on "user credentials"
I don't disagree that user credentials will be important for many jobs. However, I disagree that a type and semantics-free UserCredential field, as in the current draft, actually helps. I think a consumer of a JSDL document needs to know two things to make use of credentials: 1) what is it, and 2) what is it for. I think it is wishful thinking to say there is one generic user credential category and the consumer can divine the rest from the value itself. If this is so, we might as well put this expressive value in the xsd:any##other slot as an extension (understood by some, but not all, consumers). For example, in WS-GRAM for GT4, we do not pass around credentials per se, but we do pass around references to credentials (the actual credentials are moved ahead of time by out-of-band means relative to WS-GRAM). Because each of these references is of the same type (and referring to the same type of credential: our GSI proxies), we have separate fields in the WS-GRAM job language to designate the purpose of each one: one to put in the job's environment (as a file), one for WS-GRAM to use when invoking our RFT file transfer service, and a third to pass through (by reference) to the RFT service itself (which it then uses to authenticate with GridFTP). We would have to use these wrappers in the JSDL transliteration, since "user credentials" is too abstract to actually convey the different meanings we have. I suspect that any meaningful "pass through" would have to do the same thing---designate _which_ target mechanism to pass the values to. It wouldn't help much if a JSDL consumer "passed" a Kerberos ticket in the file where we expect GSI proxies, or vice versa. karl -- Karl Czajkowski karlcz@univa.com
Many thanks for this Karl. It is very clear. Any other thoughts on this? Donal, Michel, Darren...? Thanks in advance, Ali On Wed, 30 Mar 2005, Karl Czajkowski wrote:
I don't disagree that user credentials will be important for many jobs. However, I disagree that a type and semantics-free UserCredential field, as in the current draft, actually helps.
I think a consumer of a JSDL document needs to know two things to make use of credentials: 1) what is it, and 2) what is it for. I think it is wishful thinking to say there is one generic user credential category and the consumer can divine the rest from the value itself. If this is so, we might as well put this expressive value in the xsd:any##other slot as an extension (understood by some, but not all, consumers).
For example, in WS-GRAM for GT4, we do not pass around credentials per se, but we do pass around references to credentials (the actual credentials are moved ahead of time by out-of-band means relative to WS-GRAM). Because each of these references is of the same type (and referring to the same type of credential: our GSI proxies), we have separate fields in the WS-GRAM job language to designate the purpose of each one: one to put in the job's environment (as a file), one for WS-GRAM to use when invoking our RFT file transfer service, and a third to pass through (by reference) to the RFT service itself (which it then uses to authenticate with GridFTP).
We would have to use these wrappers in the JSDL transliteration, since "user credentials" is too abstract to actually convey the different meanings we have. I suspect that any meaningful "pass through" would have to do the same thing---designate _which_ target mechanism to pass the values to. It wouldn't help much if a JSDL consumer "passed" a Kerberos ticket in the file where we expect GSI proxies, or vice versa.
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 -------------------------------------------------------------
Guys, my view basically matches Karls view. To me, the consequence would be to refactor out the User section to an embracing document, which then maps User credentials to particular elements in the JSDL document (hence the ability to construct QNames referring to elements in a JSDL document). Referring to Karls other mail concerning Execution(User|Group), these would consequently permeate to the POSIXApplication element I think. Cheers, Michel N.B.: Ali, I didn't check, but did you already upload the conf minutes to Gridforge? On 30 Mar 2005, at 10:00, Ali Anjomshoaa wrote:
Many thanks for this Karl. It is very clear. Any other thoughts on this? Donal, Michel, Darren...?
Thanks in advance,
Ali
On Wed, 30 Mar 2005, Karl Czajkowski wrote:
I don't disagree that user credentials will be important for many jobs. However, I disagree that a type and semantics-free UserCredential field, as in the current draft, actually helps.
I think a consumer of a JSDL document needs to know two things to make use of credentials: 1) what is it, and 2) what is it for. I think it is wishful thinking to say there is one generic user credential category and the consumer can divine the rest from the value itself. If this is so, we might as well put this expressive value in the xsd:any##other slot as an extension (understood by some, but not all, consumers).
For example, in WS-GRAM for GT4, we do not pass around credentials per se, but we do pass around references to credentials (the actual credentials are moved ahead of time by out-of-band means relative to WS-GRAM). Because each of these references is of the same type (and referring to the same type of credential: our GSI proxies), we have separate fields in the WS-GRAM job language to designate the purpose of each one: one to put in the job's environment (as a file), one for WS-GRAM to use when invoking our RFT file transfer service, and a third to pass through (by reference) to the RFT service itself (which it then uses to authenticate with GridFTP).
We would have to use these wrappers in the JSDL transliteration, since "user credentials" is too abstract to actually convey the different meanings we have. I suspect that any meaningful "pass through" would have to do the same thing---designate _which_ target mechanism to pass the values to. It wouldn't help much if a JSDL consumer "passed" a Kerberos ticket in the file where we expect GSI proxies, or vice versa.
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 -------------------------------------------------------------
Hi Michel,
N.B.: Ali, I didn't check, but did you already upload the conf minutes to Gridforge?
I have now: https://forge.gridforum.org/projects/jsdl-wg/document/Minutes_-_2005-03-29/e... Cheers, Ali On Wed, 30 Mar 2005, Michel Drescher wrote:
Guys,
my view basically matches Karls view. To me, the consequence would be to refactor out the User section to an embracing document, which then maps User credentials to particular elements in the JSDL document (hence the ability to construct QNames referring to elements in a JSDL document).
Referring to Karls other mail concerning Execution(User|Group), these would consequently permeate to the POSIXApplication element I think.
Cheers, Michel
N.B.: Ali, I didn't check, but did you already upload the conf minutes to Gridforge?
On 30 Mar 2005, at 10:00, Ali Anjomshoaa wrote:
Many thanks for this Karl. It is very clear. Any other thoughts on this? Donal, Michel, Darren...?
Thanks in advance,
Ali
On Wed, 30 Mar 2005, Karl Czajkowski wrote:
I don't disagree that user credentials will be important for many jobs. However, I disagree that a type and semantics-free UserCredential field, as in the current draft, actually helps.
I think a consumer of a JSDL document needs to know two things to make use of credentials: 1) what is it, and 2) what is it for. I think it is wishful thinking to say there is one generic user credential category and the consumer can divine the rest from the value itself. If this is so, we might as well put this expressive value in the xsd:any##other slot as an extension (understood by some, but not all, consumers).
For example, in WS-GRAM for GT4, we do not pass around credentials per se, but we do pass around references to credentials (the actual credentials are moved ahead of time by out-of-band means relative to WS-GRAM). Because each of these references is of the same type (and referring to the same type of credential: our GSI proxies), we have separate fields in the WS-GRAM job language to designate the purpose of each one: one to put in the job's environment (as a file), one for WS-GRAM to use when invoking our RFT file transfer service, and a third to pass through (by reference) to the RFT service itself (which it then uses to authenticate with GridFTP).
We would have to use these wrappers in the JSDL transliteration, since "user credentials" is too abstract to actually convey the different meanings we have. I suspect that any meaningful "pass through" would have to do the same thing---designate _which_ target mechanism to pass the values to. It wouldn't help much if a JSDL consumer "passed" a Kerberos ticket in the file where we expect GSI proxies, or vice versa.
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 -------------------------------------------------------------
-- ---------------------------------------------------- |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 -------------------------------------------------------------
Any other takers...? I guess I should wait for US to wake up... Ali On Wed, 30 Mar 2005, Michel Drescher wrote:
Guys,
my view basically matches Karls view. To me, the consequence would be to refactor out the User section to an embracing document, which then maps User credentials to particular elements in the JSDL document (hence the ability to construct QNames referring to elements in a JSDL document).
Referring to Karls other mail concerning Execution(User|Group), these would consequently permeate to the POSIXApplication element I think.
Cheers, Michel
N.B.: Ali, I didn't check, but did you already upload the conf minutes to Gridforge?
On 30 Mar 2005, at 10:00, Ali Anjomshoaa wrote:
Many thanks for this Karl. It is very clear. Any other thoughts on this? Donal, Michel, Darren...?
Thanks in advance,
Ali
On Wed, 30 Mar 2005, Karl Czajkowski wrote:
I don't disagree that user credentials will be important for many jobs. However, I disagree that a type and semantics-free UserCredential field, as in the current draft, actually helps.
I think a consumer of a JSDL document needs to know two things to make use of credentials: 1) what is it, and 2) what is it for. I think it is wishful thinking to say there is one generic user credential category and the consumer can divine the rest from the value itself. If this is so, we might as well put this expressive value in the xsd:any##other slot as an extension (understood by some, but not all, consumers).
For example, in WS-GRAM for GT4, we do not pass around credentials per se, but we do pass around references to credentials (the actual credentials are moved ahead of time by out-of-band means relative to WS-GRAM). Because each of these references is of the same type (and referring to the same type of credential: our GSI proxies), we have separate fields in the WS-GRAM job language to designate the purpose of each one: one to put in the job's environment (as a file), one for WS-GRAM to use when invoking our RFT file transfer service, and a third to pass through (by reference) to the RFT service itself (which it then uses to authenticate with GridFTP).
We would have to use these wrappers in the JSDL transliteration, since "user credentials" is too abstract to actually convey the different meanings we have. I suspect that any meaningful "pass through" would have to do the same thing---designate _which_ target mechanism to pass the values to. It wouldn't help much if a JSDL consumer "passed" a Kerberos ticket in the file where we expect GSI proxies, or vice versa.
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 -------------------------------------------------------------
-- ---------------------------------------------------- |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 -------------------------------------------------------------
Karl Czajkowski wrote:
I don't disagree that user credentials will be important for many jobs. However, I disagree that a type and semantics-free UserCredential field, as in the current draft, actually helps.
I think I can agree with that (and I like your motivating examples). But there is a way forward. We can drop the UserCredential element itself but instead allow a sequence of SAML assertions or assertion references. This is a clearly defined (if large) standard and so using it would be a good thing. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security In particular, the SAML <AssertionIDRef> <AssertionURIRef> <Assertion> and <EncryptedAssertion> elements (of SAML 2.0) seem to cover just about any use case I could possibly think of *except* hand-authoring the whole document, but that isn't really something you'd want to do anyway when working with such things. Instead, the first software agent to handle the JSDL document would probably set all that up. If you're trawling the SAML spec, I focussed on saml-core-2.0-os.pdf and especially on Section 2. A separate issue is whether the SAML assertions would be best structured under the User element. Possibly not... Donal.
participants (4)
-
Ali Anjomshoaa -
Donal K. Fellows -
Karl Czajkowski -
Michel Drescher