Bug 4350 - Framework does not support independent authz scheme for GSI Transport and GSI Secure Conversation
: Framework does not support independent authz scheme for GSI Transport and GSI...
Status: ASSIGNED
: Java WS Security
Authorization
: development
: PC Windows XP
: P3 normal
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2006-04-17 08:36 by
Modified: 2006-04-20 08:49 (History)


Attachments


Note

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


Description From 2006-04-17 08:36:30
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?
------- Comment #1 From 2006-04-19 02:52:41 -------
> 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...
------- Comment #2 From 2006-04-19 09:25:00 -------
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).
------- Comment #3 From 2006-04-20 02:44:35 -------
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?
------- Comment #4 From 2006-04-20 08:13:27 -------
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.
------- Comment #5 From 2006-04-20 08:49:52 -------
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...