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

[darren at pulsipher.org]

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 at epcc.ed.ac.uk
>         Edinburgh EH9 3JZ               Phone:  + 44 (0) 131 651 3388
>         United Kingdom                  Fax:    + 44 (0) 131 650 6555
>         -------------------------------------------------------------
>