Bug 5858 - Fix host authorization in GRAM4
: Fix host authorization in GRAM4
Status: RESOLVED FIXED
: GRAM
wsrf gram clients
: development
: All All
: P3 enhancement
: 4.2
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-02-07 07:42 by
Modified: 2008-04-30 16:09 (History)


Attachments


Note

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


Description From 2008-02-07 07:42:53
The GRAM4 client authenticates to the GRAM4 services expecting (by default)
host authorization. This authorization relies on DNS lookups which may cause
globusrun-ws to choose the wrong hostname for a multihomed host or an address
with multiple names. 

Also, notifications are authorized in the same way, which can cause two
problems. If there is no DNS support for an address, the authorization fails
and notifications are dropped. If any host sends a notification that has a
certificate that is trusted, it may assert state changes for a GRAM job that it
does not manage.

The authorization code in GRAM4 should use the host name passed on the
command-line to establish identity-based authorization for these cases, so that
the user can name the host on the command-line and authorize notifications that
come only from the same entity which the job was submitted to.
------- Comment #1 From 2008-02-08 16:13:37 -------
Committed some code to ws-gram-bug5247 to do name comparison based on the
factory hostname instead of using DNS lookups in globusrun-ws
------- Comment #2 From 2008-02-08 16:19:41 -------
TG RPs would like to setup multiple hosts each running a gram4 service
container for access to a single compute resource.  They want to do this for
redundancy/reliability/scalability.  If this fix enables sites to do that with
globusrun-ws, then we should be able to do similar client-side authorization
tricks for java clients too.  It would be great if this could be tested out and
confirmed.

-Stu
------- Comment #3 From 2008-04-30 16:09:48 -------
This is merged to trunk.