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