So, I need to provide Single Sign On access to an existing Drupal 7 site for users of a second site built with Google Sites. The Drupal site has an existing user base which is separate from that of the Google Site’s users. The Google Site will have its own users, which should have access to both their site and the google site. I will be provided with Oauth2.0 configuration details to allow the Google Sites users to login authenticating against the Google Site as an IDP. So, the D7 site should only be accessible to the Drupal users and the google sites uses, not anyone with a google account.
I am assuming since the backend is google, that the site's users will be ultimately Google Users. The site uses "Oauth2.0 to Authenticate" other apps. Drupal has on OpenID connect module and I was wondering if the OpenID protocol would be used on top of the oauth2 credentials provided by the site admin? In essence, can I use this module to provide SSO access for the Google Sites users?
Related
I read this page: https://cloud.google.com/appengine/docs/ssl
What I'm wondering: When you create a Google Apps for Work account to get a certificate, does the same user need to 'own' the Google Cloud Platform account where the appengine is running?
And who should be the 'owner' of Cloud DNS?
In many cases, the programmer is not part of the company, so he doesn't have a google apps user account. Or is sharing access of the Cloud Platform enough to get SSL.
Regards, Peter
Note: GAE SSL on custom domains is about to break free of Google Apps, which may significantly change the context for your question and answer(s). See https://support.google.com/a/answer/2644334:
Currently the Google Apps SSL configs only map certificates to the custom domain URLs, regardless of those URLs being served by GAE apps or not, so app ownership identity shouldn't matter. But this needs to be done by a Google Apps Admin.
For now Google Apps Admins can still map custom domain URLs to GAE apps (unclear if they need to own the apps, the above note suggest they might not need to) - which will change after the migration to the Developer Console.
Both the Google Apps Admin or the GAE app owner can perform the app mapping to a custom domain URL (via the Apps Admin console or the Developer Console, respectively) provided they pass the domain ownership verification (the actual Cloud DNS owner doesn't matter technically).
The page you read links to a more detailed documentation for Google Apps, where you can find this :
To add your application to the Google Apps account, the account
administrator’s sign-in account (email address) should be an owner of
the app. This is set in the Google Cloud Platform documentation under
Permissions.
So the admin user who enables SSL on Google Apps must also be an owner of the Google Cloud Platform project.
Who owns the DNS settings (be it Google Cloud DNS or any other DNS service) is independent : it doesn't have to be the same person.
We are migrating out applications from OpenID using UserService to OAuth2 / OpenID Connect to move our apps to the new Google Apps Marketplace.
We are using UserService.isAdmin() to check if a user is registered as admin for the GAE application.
How can we keep this functionality when moving to OAuth2 for login?
I don't think you can explicitly check who the admin is any other way.
It is rare that you would need to know the App Engine admin in a publicly-listed app. If the app is a general solution app, than aren't you the admin? Most developers care about the Domain Admin, which can be determined with the Admin SDK. If these is just for your own use, set the visibility options to your domain in the Chrome Webstore Developer Dashboard.
I am really fed up. All I see the Google App Engine tutorial was just making the example on how to authenticate without password. What if I want to authenticate directly from my gmail account, how can I do it???
User the google provided users service which can use your google account for auth.
https://developers.google.com/appengine/docs/python/gettingstarted/usingusers
Google App Engine provides several useful services based on Google infrastructure, accessible by applications using libraries included with the SDK. One such service is the Users service, which lets your application integrate with Google user accounts. With the Users service, your users can use the Google accounts they already have to sign in to your application.
So now Google released the multi-tenant feature for gae.
Assuming i am going to implement a google app engine application and put it on google apps market place.
suppose www.doma.com and www.domb.com bought the application.
can usera from doma and userb from domb authenticate to this application with their google apps domain username (in other words) can usera#doma and userb#domb use authenticate with gae?
Thanks in advance
Google does not limit users when they go through OpenID or Google Accounts authentication procedure, your code should do this. After user is authenticated control is handed back to your code - at this point you should check users data and decide to pass the request through or not.
Also, if you want to use doma.com and domb.com as your domain names on GAE you need to own this domains and create separate Google Apps account for each of them. This means that random user cannot have user#doma.com email address (unless you manually created an account for them on Google Apps).
I have successfully followed the examples to gain an AuthSub token to authorize my GAE application to have access to the user's Google Calendar.
I have added the domain parameter to the method gdata.auth.generate_auth_sub_url so that the application is authenticated against a Google Apps Domain user. The app is then installed in one of our test domains.
This is working fine, however, each user in the domain has to go through the process of authorizing the app to use the calendar. In other Marketplace Apps that I have tried, this authorization is done once for the whole domain when the app is installed.
How is this achieved?
This page describes how Marketplace apps can access the gdata APIs on a user's behalf.