Re: [gt-user] Error : globus-stop-container . GSSException: Defective credential detected
2009/9/17 zhong kai zhok...@163.com: I've trid that command, but it doesn't work. here is the error message : E:\ws-core-4.0.5\bin\globus-stop-container -m msg -s h ttp://localhost:8080/wsrf/services/ShutdownService 2009-09-17 21:09:47,396 ERROR securemsg.X509SignHandler [main,handleMessage:109] Failed to sign message org.globus.gsi.GlobusCredentialException: Proxy file (C:\Users\ADMINI~1\AppData\ Local\Temp\x509up_u_administrator) not found. That says it all. You need a credential. Follow this tutorial: http://gridshib.globus.org/docs/gridshib/install-windows.html#install-jwscore40-windows Hope this helps, Tom
Re: [gt-user] Expiration date in GSI proxy
On Fri, Mar 27, 2009 at 1:23 PM, Davide Guidotti d.guido...@cineca.it wrote:
new GlobusCredential(mykey, new X509Certificate[] {mycert});
The problem concerns the expiration date. Now the proxy has the same
expiration date of the certificate, but I want to specify a different
date. How can I specify the expiration date? I have tried using the
BouncyCastleCertProcessingFactory.createCredential function, but I
didn't succeed.
Here is an example how to create a GlobusCredential using
BouncyCastleCertProcessingFactory:
http://viewcvs.globus.org/viewcvs.cgi/gridshib/saml/common/java/src/org/globus/gridshib/security/util/GSIUtil.java?view=log
See one of the createCredential methods for details.
Hope this helps,
Tom
Re: [gt-user] How to use the DenyOverride algorithm with PDPs?
On Tue, Mar 17, 2009 at 9:05 AM, Roland Kuebert kueb...@hlrs.de wrote: Tom Scavo wrote: I'm glad you got it to work, finally. But you've uncovered a bug since clearly the documentation says otherwise: http://www.globus.org/toolkit/docs/4.2/4.2.1/security/wsaajava/descriptor/ Would you mind filing a bug and including a link to this thread in the bug report? I wouldn't mind doing that. The appropriate product is Java WS Security, right (Java APIs and tools for authentication, authorization and certificate management)? Yes, I think so. Thanks for documenting this issue, Roland. Tom
Re: [gt-user] How to use the DenyOverride algorithm with PDPs?
Roland, can you please enable DEBUG logging in the container and post the relevant logs? Not the entire log file of course, just the relevant log entries. Also, what version of GT (or JWS Core) are you using? Thanks, Tom On Wed, Mar 11, 2009 at 8:11 AM, Roland Kuebert kueb...@hlrs.de wrote: Hi, I've written a PDP which I want to use, additionally to the gridmap PDP, in the ManagedJobFactoryService. I want to use this service before the gridmap one and allow it to deny a request, even if the gridmap would allow it, so I want to use the DenyOverride algorithm but I can't figure out how to specify. I can successfully specify PermitOverride and FirstApplicable, but whenever I specify the DenyOverride, I get the following error: [JWSCORE-210] Failed to initialize 'ManagedJobFactoryService' service org.globus.wsrf.config.ConfigException: [JWSSEC-186] Authoriation algorithm provider not found for name DenyOverride. (There's a typo in the JWSSEC-186 message; Authoriation should be Authorization) I specify it by using authzChain combiningAlg=DenyOverride , which works, as I said before, if I replace DenyOverride with PermitOverride or FirstApplicable. Any hints? Regards, Roland
Re: [gt-user] How to use the DenyOverride algorithm with PDPs?
Thanks, Roland. That was helpful.
I think I see what's going on. Deny-overrides is configured in the
security descriptor using the fully qualified classname, as indicated
in Comment #1 of this bug report:
http://bugzilla.globus.org/globus/show_bug.cgi?id=6033
Can you please try that and see if that works for you?
Tom
On Wed, Mar 11, 2009 at 10:17 AM, Roland Kuebert kueb...@hlrs.de wrote:
Hi Tom,
Tom Scavo wrote:
Roland, can you please enable DEBUG logging in the container and post
the relevant logs? Not the entire log file of course, just the
relevant log entries.
I added DEBUG logging for org.globus.wsrf.impl.security (and wsrf.config)
and I get:
2009-03-11T15:11:59.904+01:00 ERROR handler.AddressingHandler
[ServiceThread-55,invoke:142] Exception in AddressingHandler
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: org.globus.wsrf.config.ConfigException: [JWSSEC-186]
Authoriation algorithm provider not found for name quot;DenyOverridequot;
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:org.globus.wsrf.config.ConfigException:
[JWSSEC-186] Authoriation algorithm provider not found for name
quot;DenyOverridequot;
at
org.globus.wsrf.impl.security.authorization.AuthorizationEngine.getInstance(AuthorizationEngine.java:74)
at
org.globus.wsrf.impl.security.util.AuthzUtil.getAuthzEngine(AuthzUtil.java:142)
at
org.globus.wsrf.impl.security.descriptor.ServiceSecurityDescriptor.initAuthorizationConfig(ServiceSecurityDescriptor.java:778)
at
org.globus.wsrf.impl.security.descriptor.ServiceSecurityDescriptor.initialize(ServiceSecurityDescriptor.java:474)
at
org.globus.wsrf.impl.security.descriptor.ServiceSecurityDescriptor.initialize(ServiceSecurityDescriptor.java:141)
at
org.globus.wsrf.impl.security.descriptor.ServiceSecurityDescriptor.lt;initgt;(ServiceSecurityDescriptor.java:115)
at
org.globus.wsrf.impl.security.descriptor.ServiceSecurityHelper.createServiceDescriptor(ServiceSecurityHelper.java:337)
at
org.globus.wsrf.impl.security.descriptor.ServiceSecurityHelper.initialize(ServiceSecurityHelper.java:120)
at
org.globus.wsrf.impl.security.descriptor.ServiceSecurityHelper.initialize(ServiceSecurityHelper.java:90)
at
org.globus.wsrf.impl.security.descriptor.ServiceSecurityHelper.initialize(ServiceSecurityHelper.java:80)
at
org.globus.wsrf.container.ServiceManager.initializeService(ServiceManager.java:262)
at
org.globus.axis.description.ServiceDescUtil.resetOperations(ServiceDescUtil.java:138)
at
org.globus.wsrf.handlers.AddressingHandler.resetOperations(AddressingHandler.java:310)
at
org.globus.axis.message.addressing.handler.AddressingHandler.processServerRequest(AddressingHandler.java:434)
at
org.globus.wsrf.handlers.AddressingHandler.processServerRequest(AddressingHandler.java:115)
at
org.globus.axis.message.addressing.handler.AddressingHandler.invoke(AddressingHandler.java:136)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.server.AxisServer.invokeService(AxisServer.java:199)
at org.apache.axis.server.AxisServer.invoke(AxisServer.java:375)
at org.globus.wsrf.container.ServiceThread.doPost(ServiceThread.java:949)
at org.globus.wsrf.container.ServiceThread.process(ServiceThread.java:684)
at
org.globus.wsrf.container.GSIServiceThread.process(GSIServiceThread.java:182)
at org.globus.wsrf.container.ServiceThread.run(ServiceThread.java:471)
org.globus.wsrf.config.ConfigException: [JWSSEC-186] Authoriation algorithm
provider not found for name DenyOverride
at org.apache.axis.AxisFault.makeFault(AxisFault.java:104)
at
org.globus.axis.description.ServiceDescUtil.resetOperations(ServiceDescUtil.java:142)
at
org.globus.wsrf.handlers.AddressingHandler.resetOperations(AddressingHandler.java:310)
at
org.globus.axis.message.addressing.handler.AddressingHandler.processServerRequest(AddressingHandler.java:434)
at
org.globus.wsrf.handlers.AddressingHandler.processServerRequest(AddressingHandler.java:115)
at
org.globus.axis.message.addressing.handler.AddressingHandler.invoke(AddressingHandler.java:136)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.server.AxisServer.invokeService(AxisServer.java:199)
at org.apache.axis.server.AxisServer.invoke(AxisServer.java:375)
at org.globus.wsrf.container.ServiceThread.doPost(ServiceThread.java:949)
at org.globus.wsrf.container.ServiceThread.process(ServiceThread.java:684)
at
org.globus.wsrf.container.GSIServiceThread.process(GSIServiceThread.java:182
Re: [gt-user] SAML based VOMS Server
On Fri, Jan 30, 2009 at 4:40 AM, Benjamin Henne he...@rvs.uni-hannover.de wrote: 1. How to set up a VOMS Server which issues SAML based assertions instead of AC ? To get SAML assertions containing the VOMS information you extent your existing VOMS installation by adding the VOMS SAML service. Originally the service was standalone, but it will be integrated with VOMS-Admin. VOMS-Admin is going to be the container for all the WS effort around VOMS. Version 2.0.17 shall be the first release containing the VOMS SAML endpoint. It was originally scheduled for this month, but seems not to be released yet. Maybe you can get it from CVS. What about the client side? Will the voms-proxy-init tool be extended to support this new server-side option? If so, can you provide a pointer? The reason I ask is because a VOMS-SAML token bound to a proxy certificate MUST contain a ds:X509SubjectName element in its saml:SubjectConfirmation element. Do we know if this is the case? Thanks, Tom
Re: [gt-user] SAML based VOMS Server
On Fri, Jan 30, 2009 at 7:21 AM, Ralf Groeper groe...@rvs.uni-hannover.de wrote: Globus Toolkit can consume SAML1.x assertions (e.g. issued by GridShib SAML Tools) using GridShib for GT . As far as I know there is no SAML2 support available at all. However, SAML VOMS issues SAML2 assertions. Actually, it is worse than that. GridShib for GT will process self-issued SAML tokens with sender-vouches subject confirmation, such as those issued by a portal on behalf of a portal user. (This is the TeraGrid Science Gateway use case, which we fully support.) GridShib for GT does not currently support holder-of-key SAML tokens of any kind. (Well, that's not totally true since we support implicit holder-of-key SAML tokens bound to trusted end-entity certificates, such as those issued by the GridShib CA.) To support VOMS-SAML, GridShib for GT must be made to support explicit holder-of-key SAML tokens bound to proxy certificates. As I mentioned earlier, such SAML tokens MUST include a ds:X509SubjectName element. (Somebody else will have to comment whether or not VOMS-SAML supports this type of subject confirmation.) Tom
Re: [gt-user] SAML based VOMS Server
On Fri, Jan 30, 2009 at 11:21 AM, Benjamin Henne he...@rvs.uni-hannover.de wrote: Can you elaborate how exactly you combine both attributes and do a authorization based on those attributes? Looking at the current setup and upcoming extension of our grid infrastructure we have * user attributes from VOMS * attributes as attribute certificates in proxy certificates for Globus and gLite, VOMS attributes as SAML assertions for UNICORE 6 * concerning Globus, it will be an attribute push via the proxies At the moment we will not use GridShib (CA/ST) because of the version mismatch: VOMS SAML asserting SAML2 vs. GridShib supporting SAML1. Assuming all the stars align with respect to Google Summer of Code, we should be able to provide this capability by the end of summer 2009. It would be nice to integrated VOMS and Shibboleth SAML assertions into the proxy and push them to the resources, but here again is the SAML version problem. Shibboleth-issued SAML tokens are altogether different. The use of VOMS requires an X.509-based PKI, which leads to certain types of SAML tokens (containing ds:X509SubjectName elements). Shibboleth knows nothing of X.509-based PKI, so the SAML tokens obtained from a Shibboleth Attribute Authority would look very different. Moreover, in the GridShib model, Shibboleth-issued SSO assertions (yet another type of SAML token) are nested in the Advice element of another SAML assertion (as you, Benjamin, know very well :). As it turns out, a SAML V2.0 assertion can be nested in the Advice element of a SAML V1.1 assertion, and that is probably how this feature will be implemented at first (because it's simplest). No promises when this feature might appear, however. Tom
Re: [gt-user] SAML based VOMS Server
On Fri, Jan 30, 2009 at 7:21 AM, Ralf Groeper groe...@rvs.uni-hannover.de wrote: If I am not wrong you also meant that currently one cannot combine VOMS SAML assertions and GridShib for GT attributes? Yes, as far as I know this is currently not possible due to the lack of support for SAML2 assertions. Yes, it is true that GridShib does not currently support SAML V2.0. Assuming Google still plans on going ahead with Google Summer of Code 2009, and Globus will be involved in GSoC this year, and I win a slot among those projects allocated to Globus, this is my top priority for Google Summer of Code 2009. Tom
Re: [gt-user] SAML based VOMS Server
Hi Alan, Thanks for posting Gabriele's response. My question involves only item 2. Specifically, what does the saml:SubjectConfirmation element on the X.509-bound VOMS-SAML token look like? It's a very important question that impacts the relying party's ability to confirm the subject. For example, the following saml:Subject element is analogous to what's found in an attribute certificate: saml:Subject saml:NameID Format=urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName cn=trsc...@uiuc.edu,OU=User,O=NCSA-TEST,C=US /saml:NameID saml:SubjectConfirmation Method=urn:oasis:names:tc:SAML:2.0:cm:holder-of-key saml:SubjectConfirmationData ds:KeyInfo ds:X509Data ds:X509SubjectName cn=trsc...@uiuc.edu,OU=User,O=NCSA-TEST,C=US /ds:X509SubjectName /ds:X509Data /ds:KeyInfo /saml:SubjectConfirmationData /saml:SubjectConfirmation /saml:Subject That is, the value of the saml:NameID element is equivalent to the subject DN of the AC while the ds:X509SubjectName element describes a form of holder-of-key subject confirmation equivalent to what a VOMS relying party's does today (or so I believe). The reason I ask is that we (in the OGSA Authz WG) originally profiled a VOMS-SAML token containing a ds:X509Certificate element, which is fine for UNICORE (which doesn't rely on proxies), but clearly ds:X509Certificate leads to circular reasoning at the RP (since the SAML token is bound to a proxy). Thanks, Tom On Tue, Feb 3, 2009 at 5:28 PM, Alan Sill alan.s...@ttu.edu wrote: More information from one of the VO Project managers is below. Alan - Hi Alan, there are 2 distinct things here 1) using the SAML v2 profile of XACML v2 to convey authorization assertions from a PEP to a PDP. This is the authorization interoperability effort, a collaboration between Globus, EGEE / INFN, OSG / VO Services, and Condor: http://listserv.fnal.gov/scripts/wa.exe?A2=ind0901eL=privilege_projectT=0X=2B9777238D431DBE31Y=garzogli%40fnal.govP=1906 2) embedding SAML v2 assertions in certificate proxies to convey user attributes, instead of using VOMS attribute certificates. This effort is led by INFN / VOMS. In principle, a natural extension of (1) would be using the SAML assertions in the proxies from (2) to obtain authorization decisions. That would work almost immediately with XACML-based PDPs, such as GPBox and gJAF. For non-XACML-based PDP, such as GUMS or SAZ, it would require integration work. Hope this helps Cheers Gabriele Alan Sill wrote: Hi gents, Can you comment on the following interchange currently taking place in the glite-discuss and gt-user lists, please? What is the current state of SAML2 with respect to the joint authorization project and specifically VOMS? Thanks! Alan
Re: [gt-user] VOMS Cookbook for Protecting GT4 Services!
On Thu, Jan 29, 2009 at 12:09 PM, Jan Muhammad j...@dcs.gla.ac.uk wrote: I download the source (http://workspace.globus.org/downloads/globus_voms_interceptors_0.2.tar.gz), build the gar and deployed to container successfully. 1. But after deploying the service I don't see any additional service in the container after deploying. We (Globus) don't distribute a VOMS service (if that's what you're looking for). For that you need to explore the links that Alan posted earlier. The VOMS incubator project supports a pair of VOMS interceptors for the Globus container. These interceptors are *consumers* of VOMS attribute certificates. 2. If you look at that document Configuration section, its not clear which service's security-config.xml file to edit (http://dev.globus.org/wiki/Incubator/VOMS/Installing#Configuring_the_authorization_chain) Well, you apply those configuration changes to whatever service you want to VOMS-enable. In principle, any service running in the Java WS Core container will do. I will assume that it is talking about the service that I want to protect. Correct. 3. Then at the Setting Configuration parameters section it has not mentioned about PIP configuration parameters and PDP configuration parameters that where and in which files these will go? That depends on the GT version you're running (technically, only Java WS Core is required). In theory, the VOMS interceptors work with both 4.0 and 4.2, but I suspect you'll have trouble with 4.2 initially. Others have reported problems with the latest versions of GT 4.2, unfortunately. http://bugzilla.globus.org/globus/buglist.cgi?query_format=specificorder=relevance+descbug_status=__open__product=VOMScontent= So I think the first thing you should do (if it doesn't say this in the documentation, it should) is read the documentation regarding the authorization framework for the version of GT you're interested in. Tom
Re: [gt-user] deploying a GAR file
On Wed, Jan 28, 2009 at 1:58 PM, Tom Howe turtleben...@gmail.com wrote:
What version of gt are you using?
GT 4.0.8
Thanks for asking, Tom.
Tom
PS. Ignore the last paragraph below, that is, out of the box there are
no executables in $GLOBUS_LOCATION/bin that have the wrong
permissions. AFAIK, the problem occurs only when deploying a GAR
file.
On Sat, Jan 24, 2009 at 3:14 PM, Tom Scavo trsc...@gmail.com wrote:
On Sat, Jan 24, 2009 at 2:47 PM, Tom Scavo trsc...@gmail.com wrote:
After deploying a GAR file with 'globus-deploy-gar', any executables
deployed in ${abs.deploy.dir}/bin do not have the correct permissions
(755). Instead they end up with permissions (664). Is this a bug?
I think I figured out what's going on. After executing
'globus-deploy-gar', some of the executables in ${abs.deploy.dir}/bin
have the correct permissions and some do not. The ones that don't
have the correct permissions have incorrect EOL characters (i.e., CRLF
instead of LF). After correcting the faulty EOL characters in the GAR
and redeploying, the permissions on all files are correct.
So it looks like the chmod task fails on files with incorrect EOL
characters (at least on CentOS 4.7 X86_64). Why not invoke task
fixcrlf before changing permissions in build-packages.xml? Let me
know if you want me to create a bug for this.
By the way, this may explain why other executables in
$GLOBUS_LOCATION/bin have the wrong permissions. I haven't verified
this, however.
Tom
Re: [gt-user] deploying a GAR file
On Wed, Jan 28, 2009 at 2:03 PM, Tom Howe turtleben...@gmail.com wrote:
So, now my question is, which files have the wrong permissions? I'll try to
fix up all of them, but if you can point to some which aren't working, that
would help.
I created this bug in bugzilla
http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=6629
but perhaps I didn't explain the problem very well. Let me try again
(without looking at what I wrote in the bug :)
If a GAR file contains a file to deployed into $GLOBUS_LOCATION/bin on
a UNIX system, and that file has non-UNIX EOL characters (e.g., CRLF),
then that file will have the wrong permissions when deployed into
$GLOBUS_LOCATION/bin. (I neglected to record the wrong permissions,
but I claim they are *not* 755 as they should be.)
Does that make sense?
Are you asking me to provide such a GAR file? I can do that. All I
have to do is change the EOL characters on an executable destined for
$GLOBUS_LOCATION/bin.
Tom
On Wed, Jan 28, 2009 at 1:01 PM, Tom Scavo trsc...@gmail.com wrote:
On Wed, Jan 28, 2009 at 1:58 PM, Tom Howe turtleben...@gmail.com wrote:
What version of gt are you using?
GT 4.0.8
Thanks for asking, Tom.
Tom
PS. Ignore the last paragraph below, that is, out of the box there are
no executables in $GLOBUS_LOCATION/bin that have the wrong
permissions. AFAIK, the problem occurs only when deploying a GAR
file.
On Sat, Jan 24, 2009 at 3:14 PM, Tom Scavo trsc...@gmail.com wrote:
On Sat, Jan 24, 2009 at 2:47 PM, Tom Scavo trsc...@gmail.com wrote:
After deploying a GAR file with 'globus-deploy-gar', any executables
deployed in ${abs.deploy.dir}/bin do not have the correct permissions
(755). Instead they end up with permissions (664). Is this a bug?
I think I figured out what's going on. After executing
'globus-deploy-gar', some of the executables in ${abs.deploy.dir}/bin
have the correct permissions and some do not. The ones that don't
have the correct permissions have incorrect EOL characters (i.e., CRLF
instead of LF). After correcting the faulty EOL characters in the GAR
and redeploying, the permissions on all files are correct.
So it looks like the chmod task fails on files with incorrect EOL
characters (at least on CentOS 4.7 X86_64). Why not invoke task
fixcrlf before changing permissions in build-packages.xml? Let me
know if you want me to create a bug for this.
By the way, this may explain why other executables in
$GLOBUS_LOCATION/bin have the wrong permissions. I haven't verified
this, however.
Tom
[gt-user] deploying a GAR file
After deploying a GAR file with 'globus-deploy-gar', any executables
deployed in ${abs.deploy.dir}/bin do not have the correct permissions
(755). Instead they end up with permissions (664). Is this a bug?
Tom
Re: [gt-user] deploying a GAR file
On Sat, Jan 24, 2009 at 2:47 PM, Tom Scavo trsc...@gmail.com wrote:
After deploying a GAR file with 'globus-deploy-gar', any executables
deployed in ${abs.deploy.dir}/bin do not have the correct permissions
(755). Instead they end up with permissions (664). Is this a bug?
I think I figured out what's going on. After executing
'globus-deploy-gar', some of the executables in ${abs.deploy.dir}/bin
have the correct permissions and some do not. The ones that don't
have the correct permissions have incorrect EOL characters (i.e., CRLF
instead of LF). After correcting the faulty EOL characters in the GAR
and redeploying, the permissions on all files are correct.
So it looks like the chmod task fails on files with incorrect EOL
characters (at least on CentOS 4.7 X86_64). Why not invoke task
fixcrlf before changing permissions in build-packages.xml? Let me
know if you want me to create a bug for this.
By the way, this may explain why other executables in
$GLOBUS_LOCATION/bin have the wrong permissions. I haven't verified
this, however.
Tom
Re: [gt-user] Certificates from multiple CA
Please see last week's thread Globus-Container-Start Error Messages! On Wed, Jan 21, 2009 at 11:42 AM, Sardar Hussain salarzi_...@yahoo.com wrote: --- On Wed, 1/21/09, Sardar Hussain salarzi_...@yahoo.com wrote: Hi, I have a problem with certificates from multiple CA's. My scenario is as following. I have my globus container using UK e-Science certificates at location /etc/grid-security/ and its CA and signing policy at /etc/grid-security/certificates/. Globus is running fine with no errors. I have a user permistest who is using certificates from some other CA (not e-Science) and its certificates at /home/permistest/.globus/ and its CA and signing policy at /home/permistest/.globus/certificates/ I can generate a proxy for permistest successfully and can verify against its CA as well. Now when I try to access a service through this permistest user I get the unknown CA error as following [permist...@salarzai .globus]$ globus-stop-container Error: ; nested exception is: org.globus.common.ChainedIOException: Authentication failed [Caused by: Failure unspecified at GSS-API level [Caused by: Unknown CA]] Here I think globus is using e-Science CA for this user to authenticate. Alternatively when I put the CA and its signing policy for permistest in the /etc/grid-security/certificates and then try to access a service from the container through permistest it generates the same above error. I then put the CA and signing policy for the permistest user in the /home/globus/.globus/certificates directory as well but now I even can't start my container throwing the above error: [glo...@salarzai globus-4.0.4]$ globus-start-container Failed to obtain a list of services from 'https://130.209.58.35:8443/wsrf/services/ContainerRegistryService' service: ; nested exception is: org.globus.common.ChainedIOException: Authentication failed [Caused by: Failure unspecified at GSS-API level [Caused by: Unknown CA]] Can someone help me out here plz. Regards, S.Hussain
Re: [gt-user] Protecting GT4 Services with VOMS!
Hi Jan, On Mon, Jan 19, 2009 at 10:31 AM, Jan Muhammad j...@dcs.gla.ac.uk wrote: Can someone send me any use case document showing how to protect Globus Toolkit 4.0.x services using VOMS. I came through some papers regarding GridShib project, but wonder if I can get some use case scenarios (including any example code and/or architecture). The primary VOMS use case is depicted here: http://www.globus.org/grid_software/security/voms.php In the figure, the blue cloud represents a Globus service protected with the VOMS interceptors for GT4: http://dev.globus.org/wiki/Incubator/VOMS Recently, VOMS has implemented a SAML interface: http://repository.omii-europe.org/downloads/project.jsp?projectid=7 So there is interest in a generic attribute-based security context in GT4: http://dev.globus.org/wiki/GridShib_Security_Table At that point, the source of attributes (VOMS, Shibboleth, GridShib, etc.) wouldn't matter. Hope this helps, Tom
Re: [gt-user] Globus-Container-Start Error Messages!
)
at
org.globus.gsi.gssapi.net.GssSocket.authenticateClient(GssSocket.java:102)
at
org.globus.gsi.gssapi.net.GssSocket.startHandshake(GssSocket.java:140)
at
org.globus.gsi.gssapi.net.GssSocket.getOutputStream(GssSocket.java:161)
at
org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:433)
at
org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:135)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:
32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2727)
at org.apache.axis.client.Call.invoke(Call.java:2710)
at org.apache.axis.client.Call.invoke(Call.java:2386)
at org.apache.axis.client.Call.invoke(Call.java:2309)
at org.apache.axis.client.Call.invoke(Call.java:1766)
at
org.oasis.wsrf.properties.GetResourcePropertySOAPBindingStub.getResourceProp
erty(GetResourcePropertySOAPBindingStub.java:397)
at
org.globus.wsrf.container.ServiceContainer.listServices(ServiceContainer.jav
a:492)
at
org.globus.wsrf.container.ServiceContainer.main(ServiceContainer.java:424)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.globus.bootstrap.BootstrapBase.launch(BootstrapBase.java:95)
at org.globus.bootstrap.Bootstrap.main(Bootstrap.java:37)
{http://xml.apache.org/axis/}hostname:callisto.nesc.gla.ac.uk
org.globus.common.ChainedIOException: Authentication failed [Caused by:
Failure unspecified at GSS-API level [Caused by: Unknown CA]]
at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
at
org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:144)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:
32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2727)
at org.apache.axis.client.Call.invoke(Call.java:2710)
at org.apache.axis.client.Call.invoke(Call.java:2386)
at org.apache.axis.client.Call.invoke(Call.java:2309)
at org.apache.axis.client.Call.invoke(Call.java:1766)
at
org.oasis.wsrf.properties.GetResourcePropertySOAPBindingStub.getResourceProp
erty(GetResourcePropertySOAPBindingStub.java:397)
at
org.globus.wsrf.container.ServiceContainer.listServices(ServiceContainer.jav
a:492)
at
org.globus.wsrf.container.ServiceContainer.main(ServiceContainer.java:424)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.globus.bootstrap.BootstrapBase.launch(BootstrapBase.java:95)
at org.globus.bootstrap.Bootstrap.main(Bootstrap.java:37)
Caused by: org.globus.common.ChainedIOException: Authentication failed
[Caused by: Failure unspecified at GSS-API level [Caused by: Unknown CA]]
at
org.globus.gsi.gssapi.net.GssSocket.startHandshake(GssSocket.java:145)
at
org.globus.gsi.gssapi.net.GssSocket.getOutputStream(GssSocket.java:161)
at
org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:433)
at
org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:135)
... 18 more
Failed to obtain a list of services from
'https://130.209.58.58:8443/wsrf/services/ContainerRegistryService' service:
; nested exception is:
org.globus.common.ChainedIOException: Authentication failed [Caused
by: Failure unspecified at GSS-API level [Caused by: Unknown CA]]
Regards
Jan Muhammad
-Original Message-
From: Rachana Ananthakrishnan [mailto:ranan...@mcs.anl.gov]
Sent: Wed 14/01/2009 19:39
To: Jan Muhammad; 'Tom Scavo'
Cc: gt-u...@globus.org
Subject: RE: [gt-user] Globus-Container-Start Error Messages![MESSAGE NOT
SCANNED]
1. Are there any environment variables (X509_*) configured on this machine?
2. Is there a ~/.globus/certificates directory on either machine for the
user running the container? If there is, that location is used as trusted
certificate
Re: [gt-user] Globus-Container-Start Error Messages!
On Wed, Jan 14, 2009 at 10:32 AM, Jan Muhammad j...@dcs.gla.ac.uk wrote: One thing more, I use the same user-certificates on another machine, there is no any problem and containers running fine. Are the trusted certificate stores on the two systems identical? Tom
Re: [gt-user] Globus-Container-Start Error Messages!
On Wed, Jan 14, 2009 at 12:47 PM, Jan Muhammad j...@dcs.gla.ac.uk wrote: Yes the certificate I have for user and host are both identical and at the same locations e.g /home/jan/.globus /etc/grid-security/certificates respectively on my desktop and laptop machines. Do you mean /home/jan/.globus/certificates on the desktop system? If so, then the next step would be to make sure the container is actually using the trusted certificate store that you think it is. Try setting X509_CERT_DIR explicitly and see if that changes anything. Tom
Re: [gt-user] Fw: Error when start Container
Hmm, I can find no reference to X509_HOST_CERT and X509_HOST_KEY environment variables. A google search over the entire globus.org site shows a single obscure reference to these env vars in an old globus-discuss message, other than that I can find nothing. Tom On Thu, Dec 18, 2008 at 5:27 PM, Rachana Ananthakrishnan ranan...@mcs.anl.gov wrote: http://www.globus.org/toolkit/docs/4.2/4.2.0/security/wsaajava/admin/wsaajav a-configuring.html#id2486488 describes the options Tom has mentioned here. -Original Message- From: gt-user-boun...@lists.globus.org [mailto:gt-user-boun...@lists.globus.org] On Behalf Of Tom Scavo Sent: Thursday, December 18, 2008 1:27 PM To: Tom Howe Cc: gt-user@lists.globus.org Subject: Re: [gt-user] Fw: Error when start Container On Thu, Dec 18, 2008 at 9:56 AM, Tom Howe turtleben...@gmail.com wrote: Even if you start with no security, you still need to have your certificates set up correctly. You can specify the location of your host cert and key using the X509_HOST_CERT and X509_HOST_KEY environment variables. Tom, is this an undocumented feature? I can't find it anywhere in the Globus documentation. Tom
[gt-user] myproxy command
Hi, I'm looking for documentation for the myproxy command-line tool distributed with Java WS Core 4.2.1. I've checked all the usual places but haven't found anything. Can someone provide a pointer? Thanks, Tom
[gt-user] derby in globus distribution
As far as I can tell, Derby is not distributed with Java WS Core (4.0 or 4.2). Is Derby included with any Globus distribution? Thanks, Tom
Re: [gt-user] derby in globus distribution
On Thu, Dec 11, 2008 at 12:45 PM, Tom Howe turtleben...@gmail.com wrote: It is in the databases module. Sorry, Tom, I don't understand. I don't find derby.jar in a binary or source distribution of Java WS Core. Am I missing something? Thanks, Tom On Thu, Dec 11, 2008 at 11:44 AM, Tom Scavo trsc...@gmail.com wrote: As far as I can tell, Derby is not distributed with Java WS Core (4.0 or 4.2). Is Derby included with any Globus distribution? Thanks, Tom
Re: [gt-user] authzChain combining algorithms in GT 4.2.1
On Tue, Dec 9, 2008 at 9:01 AM, Benjamin Henne [EMAIL PROTECTED] wrote: is there a way to combine different user mappings from different interceptos and let users choose which mapping to use? I think one cannot do this with current combining algorithms, can one? AFAIK, this is not possible using out-of-the-box GT4.2 authz configuration. When I tried combining VOMS interceptor with gridmap authz I realized that the current algorithms do not work as I expected them to work. Am I right? * PermitOverride uses _first_ permit decision and its mapping * DenyOverride denies based on _first_ deny decision * both do not evaluate following decisions * FirstApplicable returns first deny or permit decision Yes, that's right. What about following scenario: One wants to check VOMS credentials and DN-based user mapping. The user shall be capabale to choose the mapping (localUserId for GRAM) if there are more than one, independent of the user got only mappings from grid-mapfile, VOMS interceptor, or both. The user doesn't choose the mapping, the PDP on the server-side decides what local account to use. The user can influence the PDP's decision by presenting a different certificate (containing different attributes). This scenario is not possible to realize, is it? DenyOverride and FirstApplicable are not applicable. Using PermitOverride, if the user has both credentials (DN is in grid-mapfile and he has valid VOMS credentials), always the mapping of the first PDP is used. That's correct. If you want different behavior, you need to implement a custom combined interceptor.that implements that behavior. The user can only influence decision by changing his proxy (include and exclude VOMS credentials). I think that will always be true, regardless of the authz configuration on the server-side. The current implementation of the GridShibPDP does gridmap short-circuiting, that is, if the user's DN is in the gridmap file, the local account is obtained from the gridmap file regardless of any other information in the certificate. On the other hand, if the user's DN is NOT in the gridmap file, the local account is obtained by consulting an attribute mapping policy file that maps (SAML) attributes to accounts. A future implementation of the GridShibPDP will alter this behavior: http://bugzilla.globus.org/globus/show_bug.cgi?id=6497 The new GridShibPDP does not do gridmap short-circuiting. Instead the user's DN must be in the gridmap file *and* the SAML attributes (if any) must satisfy policy. I'm not sure how to handle account mapping in this case, however. How does the PDP decide which of multiple accounts is chosen? First-come, first-served? Tom
Re: [gt-user] authzChain combining algorithms in GT 4.2.1
On Tue, Dec 9, 2008 at 11:43 AM, Rachana Ananthakrishnan [EMAIL PROTECTED] wrote: One way I can see this being used is if you configure things as follows: - Gridmap PIP (not a PDP), which just obtains a mapping if present and adds it to peer subject - VOMS PIP, which extracts mapping if present and adds it to peer subject - Custom PDP, which looks for atleast one mapping in peer subject and returns a permit or deny This is essentially what the new GridShibPDP does, but how does the account mapper choose from potentially multiple mappings? First-come, first-served is all I can think of. Tom
Re: [gt-user] Problem with certifcate
On Tue, Nov 11, 2008 at 9:17 AM, Tom Scavo [EMAIL PROTECTED] wrote: There were a number of bugs related to signing policy files fixed recently: http://www.globus.org/toolkit/advisories.html?version=4.0 Apparently the problems weren't reported until GT 4.0.7, but maybe the issue exists in GT 4.0.5 as well? Nope. Signing policy files were ignored prior to GT 4.0.7 so that isn't your problem. Sorry. Tom
Re: [gt-user] questions re security descriptors
On Mon, Nov 10, 2008 at 11:26 AM, Rachana Ananthakrishnan [EMAIL PROTECTED] wrote: Updated doc: http://www.globus.org/toolkit/docs/latest-stable/security/wsaajava/developer /#id2483308. The document describing framework explains it some more. It is mostly relevant where the combining algorithm does not use all the PIPs in the order specified, but needs a subset to set up request context. Thanks, that helps. This org.globus.security.authorization.BootstrapPIP exists in authorization module. Found it, thanks. In section 2.1.1 of the above document, it doesn't say what to do if the admin authz chain returns INDETERMINATE (which it can, because first-applicable is used)? Likewise, if the resource, service, or container authz chains are configured with the first-applicable combining algorithm, what happens if the corresponding authz chain returns INDETERMINATE? Also, sections 2.1.1 and 2.1.2 don't agree. AFAICT, items 2b and 3b in section 2.1.2 don't agree with the text in section 2.1.1. Tom
Re: [gt-user] Error while running RFT with VOMS interceptors.
On Fri, Nov 7, 2008 at 4:48 AM, Kakoli Sen [EMAIL PROTECTED] wrote: According to the link below, http://www.globus.org/toolkit/docs/4.0/security/authzframe/security_descript or.html#s-authzframe-secdesc-configAuthz prefix can be different for different PDP's. (Hmm, I would have swore that the documentation used the word scope, rather than prefix, the last time I looked.) Yes, the prefix can be different because the prefix is used to allow multiple instances of the same PDP/PIP to exist in the same authorization chain, but you don't have multiple instances of the same PDP/PIP so you don't need different prefixes. I don't think that's your problem, however. rantThe prefix mechanism is error-prone and should be removed if possible./rant In our case, VomsPDP has prefix 'bscope', which has to be prefixed with PDP configuration parameters like 'vomsAttrAuthzFile' and 'vomsAttrMapFile' in wsdd file. Yes, this looks good, thanks. Also, similar thing is working for RFT service. Only in Delegation service, the PDPConfig does not have the required parameters. I see that. I don't know what to say...everything looks good to me. Maybe there's some assumption of gridmap in the delegation service code. Tom
Re: [gt-user] questions re security descriptors
11. Trusted Certificates The text says the values are comma-separated but the example shows space-separated values. On Fri, Nov 7, 2008 at 4:35 PM, Tom Scavo [EMAIL PROTECTED] wrote: Some questions about the Java WS AA Security Descriptor Framework documented here: http://www.globus.org/toolkit/docs/4.2/4.2.1/security/wsaajava/descriptor/ 4. Administrator Authorization Chain The decision returned by this chain overrides subsequent authorization decisions. That is, if the administrator's authorization chain returns a deny, the rest of the configured authorization (at container/service/resource) is not evaluated and the operation is denied. If the administrator's chain returns the permit, the rest of the configuration is evaluated to see if the operation is allowed. The above combining algorithm doesn't sound like any combining algorithm I know. If the Administrator Authorization Chain overrides subsequent authorization decisions, why doesn't permit override the rest of the configured authorization (at container/service/resource)? Does the adminAuthz element take a combiningAlg attribute? 5. Authorization What are possible values of the combiningAlg attribute? Are other elements besides param:nameValueParam supported out of the box? For example, are multi-valued parameters supported? Thanks, Tom
