hughpyle

GWS Security

Access to a Groove workstation is controlled by the account passphrase;  once the account is unlocked, you can create workspaces, and read and modify data within all your workspaces (according to the permissions you have in those workspaces).  Similarly, the web services interface doesn't introduce any additional access control restrictions.  The Groove Web Services APIs allow essentially unrestricted access to everything within an account.

The secret key to unlock GWS access, however, is not the account passphrase.  (Your account passphrase is never stored on disk, and we don't want to send it over a TCP port either; it's not just secret, it's personal too).  So the GWS designers needed to create something else for authentication -- authentication of an application (a process running on the local machine, usually) which wants access to your Groove data.  (The account must also be logged in, by the user typing their passphrase, because the passphrase really does key the cryptographic stuff of the account.  If a GWS application requests access to a workspace when the account is not logged in, Groove will pop up the login dialog).

The solution is implemented using a registry key in the HKCU hive.   When Groove starts, it creates a strong random secret, and writes that to a "current user" registry location (HKCU\Software\Groove Networks, Inc.\Groove\WebServices\LocalRequestKey).  Local web services requests must provide that key value, which they can obtain by reading the registry (ie. by having a certain level of access to the local system).  The key value may change at any time.

To avoid man-in-the-middle attacks on web services accesses, Groove also provides a LocalResponseKey in its SOAP responses, which again can be validated against the local registry if you want.  Groove also writes its process ID to HKCU\Software\Groove Networks, Inc.\Groove\GrooveLocalHTTPServerPID.

Remote access -- usually only deployed for EDB servers where an integration application is running on a separate server in the data center -- uses a slightly different method;  there's a different registry key (HKCU\...\RemoteRequestKey), but this one can be set to any value and remain constant, if appropriate.  Confidentiality of the remote key and the network traffic is not done by Groove, so for remote applications you probably want a dedicated LAN segment and IPSEC, or some other mechanism, to secure the SOAP access.  (Remote access is also disabled by default, and you need policy settings to switch it on.  WS-Security: not yet.)

The other missing piece from my first code was the GWS HTTP port (which defaults to 9080).  Again, there's a local registry key (HKCU\Software\Groove Networks, Inc.\Groove\GrooveLocalHTTPPort) updated by Groove when it starts listening.

To write an application calling local Groove web services, then, we need a few helper routines to provide access to these values.  Each SOAP request sent to Groove must include the request key in the SOAP header, and the call must be targeted at the appropriate TCP port.

Here's my (static) util class which implements this.  (Note: there's no dependency on the Groove WSDL web references):