Passing voms-enabled proxy to Jlite as Java Object.

[Ahmed]

Hello Oleg,

Thanks for the wonderful API. It is really a remarkable contribution.
I am trying to use JLite with a Portal system. However, the portal
takes care of the management of the proxy. Basically, it retrieves a
voms-enabled proxy object (GlobusCredential) from MyProxy Server.

What I am trying is do is, skip all the proxy creation steps done by
Jlite, pass the retrieved proxy to JLite, then use Jlite as normal,
i.e. delegate proxies, and submit job.

I don't know whether I missed something, but I couldn't figure out a
way of passing the retrieved proxy to JLite using the existing
methods. The GridSessionImpl has a field called vomsProxy
(GlobusCredential object). So I have added this class and its
interface a setter method that allows me to set the proxy directly and
skipped the proxy creation configurations. Jlite was happy with that
and accepted it!

However, the worst had happened when Jlite was about to send the Job
to the WMProxy. Under the hood, Jlite uses a WMProxyAPI class that
works as a WMProxy client and delegates and submits jobs to the
WMProxy Server. The problem is, non of the Constructors of this Glite
WMProxyAPI client class takes a proxy as a Java Object
(GlobusCredential object). It requires a string Url path of the proxy
file. One or two of the constructors take an InputStream as well but I
couldn’t think of a way of casting GLobusCredential Object into
InputStream. So that has killed my hopes.

So Oleg, I am trying the Impossible, or could it be done. Please Help.
Thanks.

[Oleg Sukhoroslov]

Hi Ahmed,

The correct way to pass an existing VOMS proxy to GridSession is:

GridSessionConfig config = new GridSessionConfig();
config.setProxyPath("path to VOMS proxy file")
...
GridSession session = GridSessionFactory.create(config);

If the specified file exists GridSession uses it as a VOMS proxy.
Then you can skip session.createProxy() step.
Hope that helps.

Best regards,
Oleg

[Ahmed]

Hello Oleg,

Thanks for the response. If I understood what you said correctly,
first I will have to save the existing proxy Java
object(GlobusCredential) that was retrieved from MyProxy Server to a
local file and then use the config.setProxyPath("path to VOMS proxy
file"). If I am not wrong, my assumption is ultimately JLite will
create a Java Object (GlobusCredential) from the saved proxy file. I
have taken the code below from the body of the GridSessionImpl
constructor. This tells me that proxy object is finally created from
the saved proxy file. I am trying to skip the proxy object saving
step.

private GlobusCredential vomsProxy = null;

protected GridSessionImpl(GridSessionConfig config) {
....
if ((new File(config.getProxyPath()).exists())) {
try {
vomsProxy = new
GlobusCredential(config.getProxyPath());
}
...
}

So, I introduced a new setter method that sets the proxy object
directly, something like..

public void setVomsProxy(GlobusCredential passedProxy) {
this.vomsProxy = passedProxy;
}

This was OK and Jlite was happy with it. But when I tried to submit a
job. The Delegation step happens before the submission step. The
Jlite delegate method calls the getWMProxyClient() mehtod. This is
where the problem lies. I can't get a WMProxyClient object without
specifying a proxy file path. Remeber I never saved my proxy to a
file, I directly set it. I expected the WMProxyAPI constructor to
allow me to pass a proxy as an object (GlobusCredentialor
GSSCredential type object). Rather it wants me to pass the path of the
proxy file (config.getProxyPath()) which I don't have. I had a look at
the WMProxyAPI API documents and I couldn't find a way setting a proxy
object directly.

private WMProxyAPI getWMProxyClient(String wmProxyURL) throws
Exception {
if (wmProxyClients.containsKey(wmProxyURL)) {
return wmProxyClients.get(wmProxyURL);
} else {
WMProxyAPI client;
if (config.getCertDir() == null) {
client = new WMProxyAPI(wmProxyURL, config.getProxyPath());
} else {
client = new WMProxyAPI(wmProxyURL, config.getProxyPath(),
config.getCertDir());
}
wmProxyClients.put(wmProxyURL, client);
return client;
}
}

Am I doing things wrongly? Is there a better way that I could do what
I am trying to do. I have read in one of your messages, saying JLite
doesn't support MyProxyServer. Do you think if we find a way of
passing a proxy object (GlobusCredential) to WMProxyAPI, Jlite could
support MyProxyServer?

Thanks

On Feb 18, 12:48 pm, Oleg Sukhoroslov <oleg.sukhoros...@gmail.com>
wrote:

> > Thanks.- Hide quoted text -
>
> - Show quoted text -

[Oleg Sukhoroslov]

Hi Ahmed,

Here's the workaround:

ByteArrayOutputStream out = new ByteArrayOutputStream();
vomsProxy.save(out);
out.close();
InputStream in = new ByteArrayInputStream(out.toByteArray());
client = new WMProxyAPI(wmProxyURL, in, config.getCertDir());
in.close();

I'm going to imlement it in jLite along with
GridSessionConfig.setProxy(GlobusCredential proxy) method.
It should work with MyProxy this way.

Regards,

[Ahmed]

Hello Oleg,

I am very happy that you found a solution for that and agreed to
implement it in JLite. This means JLite not supports MyProxy Server
which is a great win. When are you planning to implement this in
JLite, any time soon. I wanted to use the JLite API as it is rather
than using a modified copy.

Thanks

On Feb 23, 8:45 pm, Oleg Sukhoroslov <oleg.sukhoros...@gmail.com>

> >> - Show quoted text -- Hide quoted text -

[Oleg Sukhoroslov]

Hi Ahmed,

I'm going to release an updated version in a few days with an example of
using MyProxy with jLite.

By the way are you sure your MyProxy server stores proxy with VOMS
extensions?
I thought it is more convenient to store plain Globus proxy and add VOMS
extensions after retrieval.
In this case you can set retrieved Globus proxy as user cert and key
(without passphrase) in GridSessionConfig and then use jLite to init
VOMS proxy etc. (see the previous MyProxy related discussions).

[thor]

Hello,

MyProxy can store VOMS extensions, bu you have to create the proxy in
the following way:

voms-proxy-init --voms vo:extensions -proxyver 2

myproxy-init --certfile /tmp/x509up_u... --keyfile /tmp/x509up_u... -c
0 -l username -k credname -s myproxyserver

Regards,
Victor

On Feb 25, 12:14 pm, Oleg Sukhoroslov <oleg.sukhoros...@gmail.com>

[Oleg Sukhoroslov]

Yes, I know it is possible to store VOMS proxy.
I just wondered why can it be preferrable than storing plain Globus proxy?
User may be a member of several VOs. Also some VOMS servers limit proxy
lifetime to 48 hours or so.
In such cases storing plain proxy could be more efficient.
See also:
https://twiki.grid.iu.edu/twiki/bin/view/Integration/VOMSandMYPROXY

[david]

Hi Oleg,

Yes, I agree with you that it is more convenient to store plain
proxies in MyProxy Server and subsequently add VOMS attributes from
whatever grid client you are using after retrieving the plain proxy.
However, we still have a specific requirement for retrieving voms-
enabled proxies from a MyProxy Server. We use a independent
Certificate management tool http://www.ngs.ac.uk/tools/certwizard that
uses similar Libraries as JLite to create voms-enabled proxies and
delegate them to myproxy. So, yes, our proxy server stores proxy with
VOMS extensions. We are planning to add a new portal a feature for
adding VOMS attributes to plain proxies, and so we will have a use-
case for that also in future.

Regards,
Ahmed and David

On Feb 25, 2:10 pm, Oleg Sukhoroslov <oleg.sukhoros...@gmail.com>

[Oleg Sukhoroslov]

Hi Ahmed and David,

You can download the new release candidate of jLite here:
http://dcs.isa.ru/os/jlite-0.2-rc.zip
I added two methods to pass user credentials and VOMS proxy to jLite as
GlobusCredential objects (see the changelog for details).
I also implemented two demos of using MyProxy with jLite which cover
both cases (retrieving plain Globus proxy or VOMS enabled proxy).
Both demos runs fine for me. But just in case I ask you to test the code
too before releasing it.

Regards,
Oleg

[Ahmed]

Hello Oleg,

I have tested the new JLite API using the portal. It worked perfectly
fine for me without any modification to the JLite API code. I have
submitted jobs, checked job statuses, cancelled jobs, listed potential
execution CEs using JLite API through MyProxy Server. All I had to do
was set the certificates path directly using config.setCertDir("C:\
\Documents and Settings\\MyUserName\\.globus\\certificates");. And
pass the proxy object to JLite using GridSessionConfig’s setProxy()
method. Well done Oleg!!!!

However, I am concerned about the performance overhead resulting from
the creation of both the GridSessionConfig and GridSessionImpl objects
every time an interaction with MyProxy Server is required. This means
even if you want to check the status of a job, or submit a job, or
just list available CEs, these object will be created not only for
the first time but also for subsequent MyProxy Server interactions.
This is because the setProxy() method shown below is defined in the
GridSessionConfig class which is used by the GridSessionImpl class
through its constructor when being instantiated. Because we pass a
proxy for every MyProxy Server Interaction, we are forced to create
GridSessionConfig object and then set the proxy and then create
GridSessionImpl using the GridSessionConfig object.

/**
* Sets the VOMS user proxy certificate.
* This method provides an alternative to setProxyPath method
* for cases when proxy is already available as a
GlobusCredential
instance.
* The proxy must have VOMS extensions.
*
* @param proxy VOMS user proxy certificate
*/
public void setProxy(GlobusCredential proxy) {
this.proxy = proxy;
// unset default proxy path
this.proxyPath = null;
}

I think we can avoid this by creating these objects only once on the
first interaction, and then just set the proxy using the setProxy()
method. One way of doing this is to move the setProxy() method from
the GridSessionConfig class to GridSessionImpl. I think, in portal
environment, all Jlite wants is the proxy object and the CA
certificates directory path. I am not sure about sharing one CA
certificates directory for all Portal users (David or Oleg might be
able to clarify this for me), but if this is not a problem, it is good
news. Then all we need is to pass the proxy by using the setProxy() of
the GridSessionImpl class. I am not sure about thread safety here,
but again you may comment about this.

Thanks again Oleg, great API.

On Mar 10, 6:59 pm, Oleg Sukhoroslov <oleg.sukhoros...@gmail.com>
wrote:

> ...
>
> read more »- Hide quoted text -

[Oleg Sukhoroslov]

Hi Ahmed,

Do you cache user proxy in a portal after retrieving it from MyProxy?
Otherwise you have to contact MyProxy on each operation which is very
inefficient.
You can cache the grid session object, one for each user, with
corresponding proxy and reuse it for many operations for that user until
proxy expires.
Then proxy expires you can retrieve a new one and recreate grid session
object with that proxy, but this won't happen often.

The original concept behid the grid session object is that during its
lifetime it is tied to specific user credentials (set via its
configuration), so you can't reuse it among many users. Adding
setProxy() method would break this concept.

[Ahmed]

Hi Oleg,

Sorry my mistake, typo error, in my last post, some places I mention
'MyProxy Server' I really meant Glite WMS. Yes, we retrieve proxy
from MyProxy and keep it in memory. You have a good point about the
grid session object creation.

On Mar 11, 9:05 pm, Oleg Sukhoroslov <oleg.sukhoros...@gmail.com>

[Oleg Sukhoroslov]

Yes, you can keep the grid session object in memory as well and reuse it
for a given user.
The only trick is how to manage proxy expiration check and renewal.