Synchronizing Users into Google Apps with IDM



By: Johan Akerstrom

September 19, 2007 6:12 am

Reads: 356

Comments:5

Rating:0

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.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: ,
Categories: Identity Manager, Technical Solutions

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

5 Comments

  1. By:klasen

    IDM 3.5 uses Java 1.5 – except on Netware. There it is still 1.4.

  2. By:pmckeith

    TUT179 Google Apps: Using Novell Products to Federate and Control Access in a Hosted Application Environment

    The practice of outsourcing through Application Service Providers (ASP) has been growing. The ASP model can offer advantages such as reduced costs and administrative burden, but it can also raise questions about identity and access controls. In this session we will show how Novell Access Manager and Novell Identity Manager address issues such as the following:
    - How does an organization manage accounts in a hosted system?
    - How can terminated employees be prevented from accessing company data?
    - How can new users be provisioned quickly with access to the hosted system?
    - Will users need to remember additional credentials in order to log in?

    This session will answer these questions by demonstrating the integration of the Google Apps productivity and collaboration suite—a free or low-cost solution for individuals, academic institutions and businesses. We will demonstrate single sign-on between your existing directory (Novell eDirectory, Active Directory or LDAP) and Google Apps using the OASIS SAML (Secure Assertion Markup Language), an open standard language supported by Novell Access Manager. Novell Identity Manager, with the Novell Identity Manager Connector for Google Apps (from CosmosKey), will be used to demonstrate provisioning and deprovisioning of accounts in Google Apps.

  3. By:ScorpionSting

    I’ve already implemented this for a University consisting of about 50,000 student accounts which has been generally successful.

    Nice and easy…

    • By:ssalgy

      We’d love to see more details about how you did that? How did you approach the project? Did you run into any obstacles? Was your management team worried about any potential issues? We crave info!

      • By:ScorpionSting

        The customer had already decided on utilising Google Apps and their onsite consultant had already located CosmosKey.

        Because Google Apps is “flat” with minimal user information, there is no need to worry about placement or issues with matching criteria.

        Google Apps was initially populated via a scripting tool run by another 3rd Party, Cloudbreak and then IDM just had to match and update from the source directory. With Google’s API exposed over SSL and login required to the specific domain, security was a minimum issue, especially being unidirectional.

        I tweeked the default CosmosKey user driver and placed in my own entitlement policies and business rules, this allowed for easy switching between a POC of 6000 odd students to the final 50k.

        The biggest concern was not IDM or the CosmosKey shim, but rather Google Apps and whether or not it could cope with the initial sync load. There were very few errors and it held up pretty well. It did take some time, but that was expected being so far away with our paper cups and string to talk to the Google API interface.

Comment