Bug 3738 - self auth is applied to globusrun-ws, but host auth is still applied.
: self auth is applied to globusrun-ws, but host auth is still applied.
Status: RESOLVED FIXED
: GRAM
wsrf managed job factory service
: 4.0.1
: PC Linux
: P3 normal
: 4.0.2
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-09-10 08:58 by
Modified: 2005-09-28 16:04 (History)


Attachments
It's the sample.xml used to submit the job. (1.28 KB, text/plain)
2005-09-10 08:59, Feng QIN
Details
Submit to local gridftp server (1.04 KB, text/plain)
2005-09-13 08:06, Feng QIN
Details
Submit to remote gridftp server (1.06 KB, text/plain)
2005-09-13 08:06, Feng QIN
Details
Error output when submit to remote server (1.83 KB, text/plain)
2005-09-13 08:07, Feng QIN
Details
RFT transfer request file (705 bytes, text/plain)
2005-09-13 08:07, Feng QIN
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-09-10 08:58:17
Hello,
When I try to submit a RFT job, following command I use:

globusrun-ws -submit -staging-delegate -self-authz -f sample.xml

Following is the output:

Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:bd912aa4-2266-11da-be56-0013204cb636
Termination time: 09/12/2005 01:52 GMT
Current job state: StageIn
Current job state: Failed
Destroying job...Done.
Cleaning up any delegated credentials...Done.
globusrun-ws: Job failed: Staging error for RSL element fileStageIn.
 
 
 
 
; nested exception is:
        org.globus.common.ChainedIOException: Authentication failed [Caused by:
Operation unauthorized (Mechanism level: Authorization failed. Expected
"/CN=host/ergrid.shtvu.edu.cn" target but received
"/O=Grid/OU=GlobusTest/OU=simpleCA-ergrid.shtvu.edu.cn/OU=shtvu.edu.cn/CN=grid3")]
 
 
 
 
org.oasis.wsrf.faults.BaseFaultType
 
 
 
org.apache.axis.AxisFault
 
 
 
 
org.globus.exec.generated.StagingFaultType

Any idea?
------- Comment #1 From 2005-09-10 08:59:39 -------
Created an attachment (id=686) [details]
It's the sample.xml used to submit the job.
------- Comment #2 From 2005-09-12 14:01:27 -------
I suppose if we are assuming RFT is co-hosted by default when we setup the
staging delegation factory RP, then we can assume the same here and use the same
heuristics as the MMJS uses to determine the authorization method.

That said, the documentation does indicate that the staging subject
configuration option (i.e. the subject name to authorize the RFT service
against) needs to be speicified explicitly if you are deploying GRAM under your
user credentials:

http://www-unix.globus.org/toolkit/docs/4.0/execution/wsgram/admin-index.html#s-wsgram-admin-userproxy
------- Comment #3 From 2005-09-13 08:06:19 -------
Created an attachment (id=689) [details]
Submit to local gridftp server
------- Comment #4 From 2005-09-13 08:06:51 -------
Created an attachment (id=690) [details]
Submit to remote gridftp server
------- Comment #5 From 2005-09-13 08:07:15 -------
Created an attachment (id=691) [details]
Error output when submit to remote server
------- Comment #6 From 2005-09-13 08:07:37 -------
Created an attachment (id=692) [details]
RFT transfer request file
------- Comment #7 From 2005-09-13 08:08:16 -------
Thanks, I edited the jndi-config.xml, the stagingSubject section, and solved
the
problem, which will have the same function with your suggestiong, and make the
gram working under the user authz mode, right?

Now, I can submit RFT relative job to local gridftp server (see the enclosure
"sample_local.xml") by setting host subject in <rftOptions><subjectName>
section, but failed submit this kind of job to remote gridftp server (see the
enclosure "sampe_remote.xml"), Globus always report the subject is not correct
(If I set local host as subject, it report remote one received; if I set remote
host as subject, it report local one received...).

local: ergrid.shtvu.edu.cn
remote: ergrid.dec.ecnu.edu.cn

Above is the problem when I use GRAM to submit RFT job, but I can use RFT with
"rft" command successfully, since I can define source and destination host
subject in xfr file (also attached).

Could you kindly check it?
------- Comment #8 From 2005-09-28 16:04:44 -------
I just changed the code (both in the trunk and the 4.0 branch) to use the same
heuristics as the MMJS to determine what authz method should be done by the MEJS
when contacting RFT.