[jsdl-wg] my view on execution user and group

[Karl Czajkowski]

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 at univa.com