Hello Max,
You are right that User Provisioning API is used to update the password for
the users in the Google Apps domain.
Lets go through your problems one by one:
- Only read access is possible by 2-legged OAuth in the Provisioning API.
- You don't need to use ClientLogin. Infact, we recommend not to use
ClientLogin.
Please use 3-legged OAuth with the Provisioning API. But then you
will require to get the new passwords and save them before you run a script
to update passwords from your end.
As 3-legged OAuth requires the admin to authorize the request,
the script must be executed by the admin as it requires admin to be logged
in.
The other way that you can implement this application is by using
the Apps Script.
You can get the passwords for users in a spreadsheet and associate
a script with it. The script will take entries from the spreadsheet and
update the passwords for all users listed.
You can refer the Apps Script documentation for Domain
Services<http://code.google.com/googleapps/appsscript/service_domain.html>.
This blog
post<http://googleappsdeveloper.blogspot.com/2011/12/domain-user-management-with-apps-script.html>explains
how you can use the Domain service with Apps Script.
- CAPTCHA challenge usually occurs in ClientLogin if you authorize the
service multiple times. Authorize the service just once and use the
authorized service in all your methods.
- The passwords must be a minimum of 8 characters in length and maximum
100. The Limits
section<http://code.google.com/googleapps/domain/provisioning_API_v2_developers_guide.html#Limits>of
the Provisioning API Developers Guide lists these limits. In your
application, you can add a precondition for the passwords entered and only
accept the correct length passwords.
We recommend the use of 3-legged authorization for your application. Feel
free to post again for any other queries.
Thank you,
Shraddha Gupta
Developer Programs Engineer
Hyderabad, Google India.
On Wed, Jan 18, 2012 at 2:53 AM, Max Noel <[email protected]> wrote:
> Hi,
>
> I'm currently working on an internal web application (and a script or two)
> to allow our employees to change their password for both Google Apps and
> our own internal services (which rely on LDAP for authentication -- so each
> user has one common password across everything). The user will choose their
> new password from this web app, and the app will, in turn, change the
> password in Google Apps and other services.
>
> Now, to do that on the GApps side, we're looking at using the user
> provisioning API (if there's a better way we're not aware of, don't
> hesitate to tell me). However, we're running into the following problems:
>
> - Using 2-legged OAuth with the domain's consumer key (
> http://code.google.com/apis/gdata/docs/auth/oauth.html#2LeggedOAuth),
> I can read, but not change, user data.
> http://support.google.com/a/bin/answer.py?hl=en&answer=162105 does
> indeed give the https://apps-apis.google.com/a/feeds/user/#readonlyscope
> for read-only user data access (which works fine), but nothing for
> read/write access (removing the #readonly doesn't work). Is read-write user
> data access at all possible with 2-legged OAuth, and if so, how?
> - Assuming 2-legged OAuth isn't possible, our fallback is to use
> ClientLogin and create a special user with a very specific set of admin
> privileges: that is, change the passwords of other, non-admin, users (we've
> found that using ClientLogin, we can't use a normal user's credentials to
> change that user's own password). However, using the control panel's
> "Organization & Users > Privileges" screen, the only way of allowing a
> user (user_a) to change (not reset, force to a specific value) another
> user's (user_b's) password is to grant user_a super-admin privileges.
> Which, as you can imagine, we're fairly reluctant to do for a user whose
> credentials will be used by automated scripts. Is there another way?
> -
>
> http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html#AuthProcess
> mentions
> that ClientLogin may respond with a CAPTCHA challenge. Under which
> conditions does it do that?
> - Testing shows that the gdata.apps.client.AppsClient.UpdateUser
> method rejects passwords that are considered too weak (e.g. "aaa") with
> error code 1402 (InvalidPassword). Is there an API somewhere that allows us
> to determine whether a password is strong enough without attempting to
> change it?
>
> Thanks for your attention,
>
> -- Max
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Apps Domain Information and Management APIs" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-apps-mgmt-apis/-/zalim9blG6EJ.
> To post to this group, send email to
> [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/google-apps-mgmt-apis?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Google Apps Domain Information and Management APIs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-apps-mgmt-apis?hl=en.
