Article

Problem

A Forum reader recently asked:

"I'm looking to use the IDM SOAP driver to synchronize users into Google Applications using Google Provisioning API - as documented here:
http://code.google.com/apis/apps/gdata_provisioning_api_v2.0_reference.html#Authentication

I need to be able to dynamically set the Authorization header in the http request to allow the providing of the auth token as required.

Looking at the SOAP driver docs, I can set a value for this HTTP header in the driver config. But the problem is that the Google-provided auth token is set dynamically - and it expires after 24 hours. Looking further in the SOAP driver docs, I see I can provide HTTP header values for "url", "method" and "soap-action" in the operation-data within each event. Can I also specify other HTTP header values in the operation-data with each event?

I'm planning to use calls to the Google Java classes to dynamically generate the authorization token into a local variable. Then I would write this into the operation-data with each event, so that the HTTP/XML request to Google has all the required headers. Any ideas on this?"

And here's the response from Johann Akerstrom ...

Solution

Recently I finished the last lines of code to a Google Apps Connector. Have a look at http://www.cosmoskey.com/products. It has been submitted to the Google Enterprise Solutions Gallery. It should show up on http://www.google.com/enterprise/gallery/apps/admin.html soon. The Google Enterprise guys are doing weekly runs to generate the solution list.

If you venture down the path of calling the Google apps' provisioning Java code directly, it will fail. That's because the Google Apps provisioning API is based on Java 1.5. Calling Java 1.5 classes from Java 1.4 (IDM's version) will fail with runtime exceptions - Google uses a lot of the new Java 1.5 features in the API. I investigated the option of using some of the tools out there that convert Java 1.5 code/classes to 1.4. This failed miserably, since the Google code uses some java 1.5 internationalization code, which the converters had problems converting.

The options you're left with are either of the following:

1. Follow the RSS/ATOM provisioning method published by Google. In the Connector I've built, this is in fact what I've done. I've built a Java 1.4-compatible provisioning API that is called by a Java driver shim.

2. Build a client/server architecture using RMI, XML-RPC, SOAP or something similar, where you use a lightweight Java 1.4-based client to call a service running Java 1.5.