> > to a globus container. this will output an epr which can be used to
> > access the delegated credential.
> >
> > but how can a service access the credentials? where can a service
> > find the security related information?
>
> Maybe try something like this:
>
> String caller = org.globus.wsrf.security.SecurityManager.getManager()
> .getCaller();
thanks, I had already found this one:
javax.security.auth.Subject
sub=(Subject)ctx.getProperty(Constants.PEER_SUBJECT);
which returns a java.util.Set containing an array of X509Certificates. however,
that's not
exactly what I've been looking for -- but see below.
> String remoteAddress = MessageContext.getCurrentContext()
> .getStrProp(org.apache.axis.Constants.MC_REMOTE_ADDR);
that's intereresting. is the remote addr the address of the interface the
message
has left the client? if yes, this means that probably private IP addresses would
show up in the message, while a getpeername(2) would probaby return a public
NATed address.
ok, now for the delegated credentials:
with pre-wsgram, a job-proxy is stored at the job-side, pointed to by the
X509_USER_{CERT,PROXY,KEY}. GT4-wsgram also shows this behaviour, e.g.
a job of mine sent via WS shows:
X509_USER_CERT=/home/local/joe/.globus/gram_job_proxy_717d6410-7b52-11dc-ac93-abb5182b27b6
X509_USER_KEY=/home/local/joe/.globus/gram_job_proxy_717d6410-7b52-11dc-ac93-abb5182b27b6
I have two questions related to this ...
(1) how do I instruct the service to generate these X509_USER_* files? I *know*
they
exist, but only ... sometimes? Of for some particular jobs? sometimes, the
job-proxy is not there at all.
the "how" is meant: API-wise, C and java, and for both: client and service.
(2) how is the creation of a job-proxy-file implemented in the service?
best regards,
h.rosmanith
