Bugzilla – Bug 4350
Framework does not support independent authz scheme for GSI Transport and GSI Secure Conversation
Last modified: 2006-04-20 08:49:52
You need to log in before you can comment on or make changes to this bug.
Container settings (container started with https enabled): -Container credentials (identity: /O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=paolinux.eng.it) Service settings (Web service Security Descriptor file): -Service Credentials (identity: /O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=authorizationService) -GSISecureConversation Client Side: -GSISecureConversation -Identity Authorization (set to Service Identity, required to perform delegation) -full (or limited) delegation When I perform a request to the service I get this fault: AxisFault faultCode: {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}General faultSubcode: faultString: ; nested exception is: org.globus.common.ChainedIOException: Authentication failed [Caused by: Operation unauthorized (Mechanism level: Authorization failed. Expected "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=authorizationService" target but received "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=paolinux.eng.it")] faultActor: faultNode: faultDetail: {http://xml.apache.org/axis/}stackTrace:AxisFault faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException faultSubcode: faultString: org.globus.common.ChainedIOException: Authentication failed [Caused by: Operation unauthorized (Mechanism level: Authorization failed. Expected "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=authorizationService" target but received "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=paolinux.eng.it")] faultActor: faultNode: faultDetail: {http://xml.apache.org/axis/}stackTrace:Authentication failed. Caused by GSSException: Operation unauthorized (Mechanism level: Authorization failed. Expected "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=authorizationService" target but received "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=paolinux.eng.it") at org.globus.gsi.gssapi.GlobusGSSContextImpl.initSecContext(GlobusGSSContextImpl.java:509) 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:160) 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) .... I supposed this exception is generated by the GSITransport handshake in the https protocol. I'm wrong? Browsing the ws-core documentation I found that GSITransport always uses container credentials (regarless of service credentials settings). If I set identity authorization (on client) to host identity (/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=paolinux.eng.it) I get the opposite error during the GSISecureConversation handshake.... AxisFault faultCode: {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}General faultSubcode: faultString: Operation unauthorized (Mechanism level: Authorization failed. Expected "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=paolinux.eng.it" target but received "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=authorizationService") faultActor: faultNode: faultDetail: {http://xml.apache.org/axis/}stackTrace:GSSException: Operation unauthorized (Mechanism level: Authorization failed. Expected "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=paolinux.eng.it" target but received "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=authorizationService") at org.globus.gsi.gssapi.GlobusGSSContextImpl.initSecContext(GlobusGSSContextImpl.java:509) at org.globus.wsrf.impl.security.authentication.secureconv.Authenticator.authenticate(Authenticator.java:64) at org.globus.wsrf.impl.security.authentication.secureconv.SecContextHandler.handleRequest(SecContextHandler.java:259) at org.apache.axis.handlers.HandlerChainImpl.handleRequest(HandlerChainImpl.java:105) at org.apache.axis.handlers.JAXRPCHandler.invoke(JAXRPCHandler.java:52) 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:127) 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) .... If I'm not wrong, Is there a way to succesfully perform delegation to a service (running with its own identity) using GSISecureConversation over HTTPS?
> BTW, why do you need to do both of these on the same method invocation ? I need to perform delegation for some service methods. The service runs with its own credentials in a secure container (https enabled). For these methods the container itself perform both the https and GSISecureConversation handshakes, generating this issue. If I disable https (with the option -nosec at container startup) any other service in the same container that uses GSITransport does not work. Moreover the service I'm developing uses GSITransport authentication for methods do not requires delegation...
Have you looked into Delegation Service ? The service can be used to provide a service access to a delegated credential, irrespective of the authentication scheme used. Also, using it you'll be able to delegate once and reuse the delegated credentail across multiple invocations to any service that runs in the same container. But you will not be able to authorize the specific service (i.e the service's credential will not be used, only container credentials will be used).
I took a look at the DelegationService documentation. It seems a good solution to solve delegation issues, but I didn't understood how it works, particularly about rules that allows registration of listeners. (I don't like to delegate my credentials to all services running in the container) Is there any complete example about that?
There are no complete examples. GRAM and RFT use this service for delegated credentials. http://www.globus.org/toolkit/docs/4.0/security/delegation/developer-index.html#id2521230 describes the authorization step when a service tries to add a listener. Esssentially the delegated credential DN should match the peer subject associated with the current message context or the Subject object set by the service should have the delegated credential DN. The idea is that any service would be able to add a listener and access the credential when the delegator accessing it. So credentials are not pushed to all services by default. As such attempting to do both GSI Secure Transport and GSI Secure Conversation is not going be performance freindly.
Yes, GSISecureConversation over HTTPS is about three to five times slower than "plain" HTTPS. But that's not a big concern for us, because only some service methods requires delegation, and the most part could use "plain" GSITransport (HTTPS). A strong requirement, instead, is that any service must have their own credentials, enabling it to (autonomously) operate in the infrastructure. This is why I discovered this issue...