There are a few 3rd party libraries from Google required for the connector. It appears that Google has updated its libraries already from what we’ve published in the doc. If you hit the problem described in http://code.google.com/p/googleappengine/issues/detail?id=3008, you probably have a “too current” version of the Google jars.
Here’s the documentation gotcha: In section 2.2.2, there is a note that states:
“Before you run the Connector Installer, you must ensure that all third party jars must be in targetsystems-lib/googleapps-18.104.22.168.0.”
The point that is intended here is that the folder structure must match the structure of the connector that is deployed. The distribution is “Google_Apps_22.214.171.124.0”, so if you take the docs literally and don’t change the name, things won’t line up. What is happening is that OIM is packaging the necessary 3rd party jars and importing them into the database. It’s important to get this right before installing the connector, or you get to go through a process of removing the jar from the database with scripts, repackaging, and re-importing.
Another confusing point is that the doc references the Java Connector Server. This might be a forthcoming solution, but for the time being, you can just substitute the OIM server anywhere it references the JCS. (This article didn’t have enough three letter acronyms (TLAs)).
Bottom line, what I think the packaging should be before the connector is deployed :
/Oracle_IAM1/server/ConnectorDefaultDirectory/targetsystems-lib/Google_Apps_126.96.36.199.0/<3rd party jars>
/Oracle_IAM1/server/lib/<3rd party jars>
Deploying the connector from that point is standard fare. Here’s how I configured my IT Resource:
Once I assigned a resource and provisioned it, the user appeared in Google apps and I was able to SSO with that user via OIF immediately. I was also able to de-provision the user from Google by removing the resource entitlement from the user.