20.12.2011 WP8 Conference Call

From IMarine Wiki

Jump to: navigation, search



Time: Tuesday December 20, 2011, 10:30 - 13:15 Europe/Rome

Conference call agenda:

-) Defining the roles of the scope in the gCube system (both primary and secondary roles)

-) How to propagate scope information in WS calls

-) How to perform scope checks with standard security mechanisms

-) Hiding scope for libraries, non-WS component and non-gCube components


Manuele Simi (CNR)

Andrea Manzi (CERN)

George Kakaletris (NKUA)

Fabio Simeoni (FAO)

Ciro Formisano (ENG)

Main Discussions and Actions

Defining the roles of the scope in the gCube system

A resource joining the D4Science Ecosystem may be shared in different virtual environments (composed by both static and dynamic information). We scope resources because we want to control their sharing. This has the following consequences:

  • requires that we know the scope of resources that we create dynamically
  • requires that we block access to resources which is attempted from outside their scopes (authorization)
  • suggests that, before we block access, we should hide resources outside their scopes (reduction of visibility)

All these requirements mean that, as well as scoping resources in general, we must scope calls to service resources too (including queries to the IS).

In the rest of the conference, we focused about how to mark invocations to services.

Scope propagation

We long discussed if scope propagation is needed or not. Surely there exist scenarios where it is not need. However, we ended up with the agreement that a marker on the current context in each call is a MUST to have. Even if there could be services that can ignore the scope in which they are invoked, they cannot know if services in the downstream calls (called after them) need it or not. Therefore, we decided to always mark an invocation to a service instance with a context information.

comment (fabio): The issue of scope propagation is perhaps more appropriately described as the issue call scoping. We debated whether, instead of scoping calls, we may attach scopes to clients. This may support requirements for limited visibility and access. We noticed, however, that the scenario in which we create resource dynamically may only be served by scoping calls themselves. And this pointed us to the fact that scope support may not be provided by standard security models (though a solution may be implemented in terms of standard security mechanisms).

Another important requirement is that propagation has to be as transparent as possible. Services that want to ignore scope will also ignore its propagation. Transparency does not mean hiddenness: services that want to manipulate it must be able to access and change such information.

How to propagate

The discussion moved on analyzing how Grid systems behave. Andrea reported on how the EMI software propagates runtime information: they store this information (such as VOs) as attributes inside proxy certificates. This solution implies the usage of delegation mechanisms and service's identities that we agreed won't work in our dynamic environment (as they didn't in the past when we introduced them).

comment (fabio): I'd say that Andrea confirmed that forms of dynamic resource sharing exist already in Grid systems, and that they scope calls (rather than clients) by scoping the proxy certificate of the client, which is call-specific. This is a carries which is, at least in principle, independent of protocol, which is a desideratum for us. However, we associate certificates with issues too: a) the fact that we do not use them within the system for authentication purposes (hence scoping calls in this way would have implications beyond scoping alone), b) we seem to have a bad experience in the past with performance penalties and infrastructural complexity. We surely need to substantiate further these doubts and understand if they are associated with concepts or poor implementations. We all agreed that passing the scope information in the SOAP headers is not a conventional way and cut us off from being interoperable as much as possible.

comment (fabio): But we should also realise that scoping calls is not that conventional in itself. And that we are not very clear as to the interoperation requirements at this level. We know that clients outside the system will need to call scoped services inside the system, but we have not discussed whether our scoping notion ought to be interoperable with someone else's. Even if this is the case, and we interoperate as to where we place scope in calls, we are still likely to have non-interoperable scope information in itself. I suggest that, for now, we con sider scoping as a feature of gCube and gCube alone. The conventionality we probably desire is with respect to existing tools to access call-specific info, as we do not want necessarily to promote our tools for this. But again, I am not convinced this is a really major point. I think protocol-independence discussed above is a stronger desideratum for us.

Our initial intention was to exploit the existing security mechanisms in order to circulate scope information. Ciro said that:

  • certificates cannot be used; we use host certificates that cannot be manipulated by services
  • the only place we have to store additional information is in the SAML assertions of the SOAP message; as a plus, we already have components allowing to add assertions to the outgoing calls

As we were discussing this solution, other two valuable requirements were raised on scope propagation:

  • protocol independence
  • decoupling from security for testing and development purposes

both of them are not met by the SAML assertions' solution which will bind us to the specific communication protocol and to the security library. On the other hand, using SAML brings the certainty of the sender, which is a strong point in favor of its adoption.

comment (fabio): I would like to have this last argument clarified. what kind of risks are involved here that placing scope in a SAML assertion would eliminate?

Looking around for other places where to store scope information:

  • HTTP does not offer any place
  • SOAP has headers (which is the current solution we want to drop)
  • a protocol independent way to propagate could be a certificate, but requires at least HTTPS, hence security
  • WS-Addressing (http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/) seems to be an appropriate candidate

comment (fabio): I would not that HTTP offers plenty of place, the headers (which have not considered as a generalisation of what do, btw), We noticed that there is no standard header usage for this. Since it is yet unclear as to whether we to generalise the solution beyond HTTP (e.g. TCP), a proprietary use of HTTP headers may not need to be excluded in principle.

comment (fabio): WS-Addressing may be appealing as a standard place, but afaik its scope is again SOAP-specific.

comment (fabio): Perhaps we should not insist so much in the existence of a standard place cross-protocol, as we will likely not find any. Perhaps we should consider standard places per protocol, and accept that different bridges client- and service-side will be needed. We may choose an HTTP-place which requires a single bridge, or else a SOAP place and an HTTP place and use two bridges.


→ CNR-FAO: to investigate if WS-Addressing can be used to propagate scope information

→ CNR-FAO: to investigate if the standard JAVA API for WS endpoint manipulation can be mapped onto the Axis' EndpointReference facilities

→ ENG: to investigate the cost of the SAML assertion's solution and the impact on the actual AuthZ model

→ ALL: to regroup soon to take a final decision on the scope propagation based on the outcomes of the previous actions

Scope enforcement

Scope enforcement is about granting the access to a resource when the invocation is performed in a legal scope, i.e. the same marked in the call or one of its ancestors. This is a form of authorization that should be moved under our Authorization model (at least at conceptual level). There would be cleanliness and strategical advance in interpreting:

a) service scopes as cross-op policies "service S can be contacted in scope X,Y,Z",

b) call scopes as assertions, or else roles within assertions, "this call has scope X".

Given a mapping of this sort onto standard AuthZ concepts and constructs, we need to check that scope-policies for services can be conveniently added/removed/changed (convenience is in performance, compared with the current solution, where we invoke a method of a service to do that). Consider also that WS-Resources are now also scoped in a subset of the corresponding running instances. Corresponding assignments and checks are done in gCore downstream from the gCube Handler. A policy-based mapping of this would have to stretch to these WSResources too, and I have no idea whether we can do this.


→ ENG: to look at the current implementation of the scope check and to investigate if it can be moved under the realm of the AuthZ components (focusing on re-usage of the current matching mechanisms).

Hiding scope for libraries, non-WS component and non-gCube components

Libraries, interfaces to gCube components and non-gCube components have not to be forced to deal with the notion of scope. Overloading all the methods is an overkill. Therefore, ideally, any scope object or reference must be removed from public interfaces.

The approach we have identified during the discussion is to have out-of-bound channels to pass the scope information. The main channel will be the implementation of a mediator that prepares the environment for making a scoped call to a gCube component. The mediator (that knows how to retrieve the current scope from the actual context, if any) will attach the scope information to the current thread. The target gCube component (an IS client library, a stub library, etc.) will get this information from the thread and exploit it in a proper way. This new mechanism will be used by all the actors aiming at interacting with any gCube component. gCube2gCube calls will ideally not need to use it, since the scope information is already available in the current context of the caller.

Other alternative channels could be:

  • java properties' files
  • java properties passed on the command line
  • a predefined Endpoint to contact to get back the scope to use


→ FAO: to implement the mediator facilities for marking scoped calls

Personal tools