Passing auth certificates to EcoGrid services
Currently the get and query operation in EcoGridQueryInterfaceLevelOne doesn't
has any authentication. It works as anonymous user, e.g. in metacat it is user
- public. It is impossible for the anonymous user to get some private records.
Now we already have authentication interface in ecogrid and it is time to add
two new operation - get and query with sessionid (which obtained from
authentication interface). By those two methods, client can access some private
records in ecogrid node.
Those two method will base on current ones and add a new parameter - sessionid.
Do the two operations will be added to EcoGridQueryInterfaceLevelOne interface?
#1 Updated by Matt Jones over 15 years ago
Yes, I think we should modify the level I interface. I also think we should
modify the get and query operations to take a sessionId, rather than creating
two new operations. In this case, if a client wanted to query anonomously, they
would pass a 'null' value for a sesssionId. Or I suppose they could be required
to login using a reserved username that symbolizes 'anonymous' (e.g., 'public')
and that doesn't require a password, then use the resulting sessionId. This
would be nice because it would mean a valid session is available for every
EcoGrid connection, whether anonymous or authenticated, which makes for a nice
place to store and cache things about the session (such as query results) on the
server side. I think there are arguments for having anonymous get(id) be
separate from authenticated get(id, sessionid), but I think its better to only
have one method.
#2 Updated by Matt Jones over 14 years ago
An alternative approach is to pass the GSI credentials in the HTTP header or in
the SOAP envelope using e.g. WS-Security standards. This would be an
alternative to modifying the individual data access methods. However, we need
to remember that at least some of the methods will have only HTTP bindings (not
SOAP bindings) for use when transferring large data sets. I'm not sure if
WS-Security would meet our needs in this context, but a modified HTTP header
might work for all scenarios.
#4 Updated by ben leinfelder over 12 years ago
We've decided to make an entirely NEW service to handle the authenticated versions of the get and query operations: