Bug 5630 - Support trust root provisioning in myproxy jglobus client
: Support trust root provisioning in myproxy jglobus client
Status: RESOLVED FIXED
: CoG jglobus
myproxy
: unspecified
: All All
: P3 enhancement
: 1.7
Assigned To:
: http://grid.ncsa.uiuc.edu/myproxy/tru...
:
:
:
  Show dependency treegraph
 
Reported: 2007-10-23 09:51 by
Modified: 2009-07-08 14:37 (History)


Attachments


Note

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


Description From 2007-10-23 09:51:33
The MyProxy API does not support option for trust root provisioning. Jim Basney
has code for such support and would be useful to incorporate those in the CoG
client API. This would greatly reduce the configuration overhead on the
clients.

Code to incorporate: 

 http://grid.ncsa.uiuc.edu/myproxy/MyProxyLogon/
 
http://cvs.ncsa.uiuc.edu/viewcvs.cgi/MyProxyLogon/src/edu/uiuc/ncsa/MyProxy/?cvsroot=myproxy
------- Comment #1 From 2008-02-21 23:54:59 -------
The reference code does not allow proxies and needs to be reworked before it
can be added to CoG to use the proxy path validator in CoG.
------- Comment #2 From 2008-02-22 07:37:38 -------
(In reply to comment #1)
> The reference code does not allow proxies and needs to be reworked before it
> can be added to CoG to use the proxy path validator in CoG.

I assume you're referring to the fact that the MyProxyLogon code requires the
myproxy-server to run with a host EEC.  This is the standard way to configure a
myproxy-server.  You have a requirement to run your myproxy-server with a proxy
credential?
------- Comment #3 From 2008-02-22 08:22:37 -------
I did a quick review of the MyProxy client side code in CoG and it did not seem
to preclude server side proxy. I'll review it once again to make sure, but I
was looking to add support for logon along the same lines. 
------- Comment #4 From 2008-02-22 09:02:23 -------
(In reply to comment #3)
> I did a quick review of the MyProxy client side code in CoG and it did not seem
> to preclude server side proxy. I'll review it once again to make sure, but I
> was looking to add support for logon along the same lines. 

I agree that the MyProxy CoG client will talk to a myproxy-server running with
a proxy credential and that this is something the MyProxyLogon client doesn't
support.
------- Comment #5 From 2009-03-24 10:20:52 -------
I'm assigning this bug to Neill Miller, who's volunteered to work on
it. Neill has recently implemented the C myproxy-get-trustroots
command (Bug 5899).

I propose we separately consider the following sub-tasks:

  1a. Implement getTrustroots() in org.globus.myproxy.MyProxy.
  1b. Implement get-trustroots in org.globus.tools.MyProxy.
      (Analogous to myproxy-get-trustroots on the C side.)
  2a. Implement get() with trustroots in org.globus.myproxy.MyProxy.
  2b. Implement get -T in org.globus.tools.MyProxy.
      (Analogous to myproxy-logon -T on the C side.)
  3.  Implement trust root "bootstrapping" in
      org.globus.myproxy.MyProxy. This is where the MyProxy client can
      run without any initial trust roots, by accepting the MyProxy
      server's host certificate without verification.

Neill may only be interested in doing a subset of the above, which is
OK with me.

As Rachana notes earlier in this bug, Java code for MyProxy trust root
management (2a,2b,3) is already in NCSA's Java MyProxyLogon
implementation, and I'm happy for Neill to re-use that existing code
in jglobus. However, MyProxyLogon uses javax.net.ssl.SSLSocket rather
than org.globus.gsi.gssapi.net.GssSocket, which means the code for #3
won't directly translate.
------- Comment #6 From 2009-04-20 12:30:28 -------
Patch 04-20-2009

http://www.mcs.anl.gov/~neillm/esg/jglobus-get-trustroots-04-20-2009.patch

The above linked patch adds the -T (-want_trustroots) command line option to
the existing jGlobus MyProxy client code and also adds a new get-trustroots
operation/command.  The -T option is analogous to the C myproxy-logon -T option
which gets the trustroot data from the server while retrieving the credential
from the server.  The separate get-trustroots command is analogous to the C
myproxy-get-trustroots command for getting the trustroot data alone.

It has been tested and appears to work properly for me, though I am requesting
feedback both on usage and code modifications.  The last part of the patch is
an error message improvement (for the user) and is not required for this patch
to work.  Some whitespace modifications have also been made throughout
(primarily removing some lines that had nothing but blank spaces on them).

The patch was generated using diff -N -a -u -r against the latest CVS snapshot
of the MyProxy code as of 04-20-2009.  Apply the patch as follows:

1) wget
http://www.mcs.anl.gov/~neillm/esg/jglobus-get-trustroots-04-20-2009.patch
2) cvs co jglobus
3) patch -p0 < jglobus-get-trustroots-04-20-2009.patch

Some additional patch notes:
---
Removed original readLine code from org.globus.myproxy.MyProxy and replaced
with readLine code from the MyProxyLogon code.  The alternate version is more
concise and handles lines longer than 512 characters (as is needed in the case
of receiving the trustroot data).  After replacing it, I've added back the
logging from the previous version so that it behaves otherwise identically.

handleReply has been modified by taking an additional parameter that specifies
if we're expecting the TRUSTROOT data to included in the reply.  If so, it is
retrieved.

The method of pulling in the TRUSTROOT data is pretty straightforward,
but it's complicated slightly by the fact that handleReply chooses to
buffer the socket's data into a ByteArrayInputStream.  This move is
likely more efficient for some operations, but in the case of getting
trustroots, it causes an extra step in processing, which is:

- since socket data has been buffered up in the ByteArrayInputStream,
  it's very likely when getting trustroot information that all of it
  has not been buffered yet in that stream, meaning some of it is
  present in that stream, and some of it is left in the socket stream.
  To handle this, the trustroot code that pulls in the data monitors
  when the ByteArrayInputStream's data has ended and attempts to swap
  streams to the socket stream and pick up from where it left off.
  While this works perfectly well, a conceptual alternative is to just
  bypass the ByteArrayInputStream all together and modify the
  handleReply method to always read all data from the socket stream.
------- Comment #7 From 2009-04-21 17:29:05 -------
(In reply to comment #6)

Neill, I've committed your patch to CVS with some modifications:

* re-worked the ByteArrayInputStream stuff in handleReply()
* remove call to System.getenv() (unsupported by Java 1.4)
* changed -want_trustroots to -trustroots to match C clients
* documented -T/-trustroots in -help message
* call writeTrustRoots when -T is given

If you could look over my commit and confirm that my changes didn't break
anything, I'd appreciate it.

I didn't commit your change to ConfigModule2.java, because I don't understand
it. Won't it throw an exception unless the first CA certificate issued the user
certificate, rather than checking all the CA certificates?

I notice that get-trustroots in org.globus.tools.MyProxy always does anonymous
authentication. That's probably OK, but it's different behavior from
myproxy-get-trustroots, which will do client-side authentication if it finds
client-side credentials.

Another difference is that myproxy-get-trustroots writes to
/etc/grid-security/certificates when run as root. Again, not sure we want or
need to match that behavior here.

We should add test cases for this new functionality to the myproxy-test script.

Otherwise, it looks like we've got everything except trust root "bootstrapping"
now.

Thanks for this contribution!
------- Comment #8 From 2009-04-27 11:31:14 -------
(In reply to comment #7)

> * re-worked the ByteArrayInputStream stuff in handleReply()
> * remove call to System.getenv() (unsupported by Java 1.4)
> * changed -want_trustroots to -trustroots to match C clients
> * documented -T/-trustroots in -help message
> * call writeTrustRoots when -T is given
> 
> If you could look over my commit and confirm that my changes didn't break
> anything, I'd appreciate it.

Looks great!

> I didn't commit your change to ConfigModule2.java, because I don't understand
> it. Won't it throw an exception unless the first CA certificate issued the user
> certificate, rather than checking all the CA certificates?

Hrm, good point -- yes, it will, though in my case it worked nicely.  The
attempt was trying to make the error message less cryptic by saying what the
problem actually was (mismatching cert subjects) instead of saying there were
no certs found.  While testing, I was actually stuck there for a while until I
added some of my own debug messaging to see what was going on.

> I notice that get-trustroots in org.globus.tools.MyProxy always does anonymous
> authentication. That's probably OK, but it's different behavior from
> myproxy-get-trustroots, which will do client-side authentication if it finds
> client-side credentials.
> 
> Another difference is that myproxy-get-trustroots writes to
> /etc/grid-security/certificates when run as root. Again, not sure we want or
> need to match that behavior here.
> 
> We should add test cases for this new functionality to the myproxy-test script.
> 
> Otherwise, it looks like we've got everything except trust root "bootstrapping"
> now.

I would think that all of the above could be added as separate enhancement
bugs, but however you think it should be handled is fine with me.  Thanks!
------- Comment #9 From 2009-06-12 12:48:46 -------
Patch 06-12-2009

http://www.mcs.anl.gov/~neillm/esg/jglobus-client-bootstrap-06-12-2009.patch

The above linked patch adds the bootstrapping of trust to
the existing jGlobus MyProxy client code in the case of a non-existent
X509_CERT_DIR directory.

It has been tested and appears to work properly for me, though I am requesting
feedback both on usage and code modifications.

The patch was generated using diff -N -a -u -r against the latest CVS snapshot
of the MyProxy code as of 06-12-2009.  Apply the patch as follows:

1) wget
http://www.mcs.anl.gov/~neillm/esg/jglobus-client-bootstrap-06-12-2009.patch
2) cvs co jglobus
3) patch -p0 < jglobus-client-bootstrap-06-12-2009.patch
------- Comment #10 From 2009-06-12 16:37:57 -------
(In reply to comment #9)

Neill, some comments on your patch:

Let's remove the unused params argument from bootstrapTrust().

We can't use sun.misc.BASE64Encoder. It's not portable. We should use
org.globus.util.Base64 instead.

I think MyTrustManager is too complicated. The version from MyProxyLogon
handles both bootstrapping and non-bootstrapping cases, but we just need it for
bootstrapping. I propose that MyTrustManager.checkServerTrusted() should just
stash certs[certs.length-1] in a private class variable and
MyTrustManager.getAcceptedIssuers() should return an array containing the
stashed certificate. I think it's best not to do anything else in
MyTrustManager, i.e., remove checkServerDN() and CertPathValidator.validate()
and the rest. All that validation will happen later in GssSocket when the
client reconnects. I also propose moving the bootstrapping code out of
MyTrustManager and into MyProxy.bootstrapTrust(), by calling
myTrustManager.getAcceptedIssuers() in MyProxy.bootstrapTrust() after
socket.close() to get the CA certificate and then putting the code to write out
the CA certificate and signing policy file in MyProxy.bootstrapTrust().

Lastly, I don't think any change to org.globus.tools.MyProxy is needed. I don't
think the test you added is what we want. We want to write the trust roots we
get from the myproxy-server even after bootstrapping. Otherwise, we'll be stuck
with just the CA that signed the myproxy-server certificate, and we won't get
the rest of the CA certificates installed. So, MyProxy.getTrustroots() can
probably still return void.

If you agree, would you be willing to make the changes and post an updated
patch?
------- Comment #11 From 2009-06-15 13:07:14 -------
Patch 06-15-2009

http://www.mcs.anl.gov/~neillm/esg/jglobus-client-bootstrap-06-15-2009.patch

The above linked patch adds the bootstrapping of trust to the existing jGlobus
MyProxy client code in the case of a non-existent X509_CERT_DIR directory on
get, anon-get, and get-trustroots operations.  This patch attempts to respect
all of Jim's previous comments and simplifies the code significantly.

It has been tested and appears to work properly for me, though I am requesting
feedback both on usage and code modifications.

The patch was generated using diff -N -a -u -r against the latest CVS snapshot
of the MyProxy code as of 06-15-2009.  Apply the patch as follows:

1) wget
http://www.mcs.anl.gov/~neillm/esg/jglobus-client-bootstrap-06-15-2009.patch
2) cvs co jglobus
3) patch -p0 < jglobus-client-bootstrap-06-15-2009.patch
------- Comment #12 From 2009-06-15 17:48:07 -------
(In reply to comment #11)

Neill, I've committed your patch to CVS with some modifications:

* replaced System.out.println in org.globus.myproxy.MyProxy with logger.debug
* added loop for multiple trust roots (i.e., intermediate CA certificates) in
org.globus.myproxy.MyProxy.bootstrapTrust()
* made opensslHash and openssl_X509_NAME_hash private
* changed MyTrustManager to also return intermediate CA certificates
* replaced File.getName calls with File.getPath
* used CertUtil.writeCertificate() in bootstrapTrust()
* only call bootstrapIfNeeded() if this.wantTrustroots

As before, if you could look over my commit and confirm that my changes didn't
break anything, I'd appreciate it.

Thanks again!
------- Comment #13 From 2009-06-16 09:57:56 -------
Jim, the changes look good from here.  Thanks!