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

[Michel Drescher]

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