I’m new with the marketplace and I’m developing an application to replace google's login with my app, which uses strong authentication.
To use it you don’t need to install anything, it’s only a matter of configuration of your google app. When you try to access mail.google.com/a/yourdomain.com it will redirect to our application where the validation process occurs, and after validating it will return to google web site.
Same happens with logout and password change, you will be redirected to my app.
When a user needs to change the account password, we use google admin api to change it, of course, it requieres a previous authorization from a domain user with administration privileges.
Question is, how to publish an application like this on the market place?, I don’t see how to do it according to the new regulations from november 19th, for example, the application type and the fact that it should be an installable listing.
Someone who can give me a hint or example.
Thanks in advance.
Fernando.
--- EDITED --- to answer to Koma
The thing is, we already have the application, what we're doing now is to do some changes to make it ready to use it with google apps.
There’s an option in the security section called “set up single sign-on (SSO)” where you configure 3 URL’s for:
Sign-in page URL (URL for signing in to your system and Google Apps)
Sign-out page URL (URL to redirect users to when they sign out)
Change password URL (URL to let users change their password in your system; when defined here, this URL is shown even when Single Sign-on is not enabled)
When you a user needs to change your account’s password you will be redirected to our application (because google have delegated that responsibility to Us). There, through OAUTH and Google Admin API, we will change the password for your google user.
We want to be listed in google’s marketplace as a solution for strong authentication delegating that functionality to our application, but we don’t see how because the user that will use our solution doesn’t need to install anything, and according to what I understand we are forced to upload something to be listed
Does that make sense to you?
From what I read, you want to replace authentication with your own. That's not feasible with a market place app.
You need to implement a SAML identity provider
https://developers.google.com/google-apps/sso/saml_reference_implementation
Related
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.
I am considering developing an application for the Apps for Business Marketplace. I see that new rules takes affect on November 19th. Referring to the new documentation (https://developers.google.com/apps-marketplace/) I do not see that any SSO requirement exists. There is allot of talk about migrating to new sign on methods, but I see no mention of sign on requirements.
What are the sign on requirements as of November 19th?
If SSO continues to be required or if I publish before Nov. 19th, my application requires security token from my API, in order to carry out API exchanges. To get this token a user/pass exchange is required one time. They would never need to enter a user/pass for my app after that. Will a one time exchange for the security token be denied under a SSO requirement?
For example the statement regarding SSO that an app cannot do is:
The end user should not be required to enter a username and password when invoking an application from within Google Apps. (https://developers.google.com/google-apps/marketplace/sso)
In my case it would not be required for the user to enter every time, just on the initial creation of the account. After that I would retain the token from my site, encrypted with the Installed App.
Would my app be denied for requiring this one time exchange under the SSO policy?
Mark
You will have to use SSO (or should if at all possible) -- see this part of the documentation: Besides, that is a better practice and should make your users feel more trust for your application.
From what I gather (note that I'm building my first marketplace app) you should not prompt users to enter username/password on your site. I am creating user record & storing token behind the scenes. So the user sees Google authorization screen, agrees to let my app use some data, accepts and sign-in right away without any prompt to create an account. After this, user will not be prompted in the future because I have their google id linked to a user record.
From their site - https://developers.google.com/google-apps/marketplace/sso#user_experience
As long as you don't have any intermediate screen, your app should be approved.
I am providing my Google Apps Domain users content via Google Sites.
Furthermore I have 3rd party content which I would like to integrate. This content needs to be secure and available only to the Google Apps Domain users.
I have implemented openid which authenticates that the users are from my domain. I consider the users to be "stupid" so I wish to avoid any access request pages, which also makes my site look rather unprofessional / unpolished.
I can see the security setting under my personal account here:
https://www.google.com/settings/security
Is there anything in the SDK which will allow me upon user creation to add the necessary account permissions?
Hypothetically if you can host your 3rd party content on Google app Engine (GAE) and all your users reside in your Google Apps Domain it is possible to set Authentication Type to "Google apps Domain" More about GAE authentication can be found here
Do not forget to deploy GAE under same Google apps Domain account
Authorization protocols like OpenID and OAuth have been deliberately designed to require explicit user confirmation of access privileges. Any mechanism that bypassed user intervention would effectively be a security exploit. I'd recommend you save yourself time and frustration by accepting that you're not going to get around that interstitial authorization page.
For better or worse, scope authorization pages have become a well-established part of the modern web application landscape. Users these days routinely confirm authorization dialogs for Facebook, Google+, LinkedIn, and Twitter access without batting an eyelash. Your less savvy users may not recognize it as such, but using existing security mechanisms is a sign of greater professionalism than rolling your own.
I am building a WP7 Twitter client. The normal OAuth 1.0 flow involves obtaining a request token by navigating a web browser to https://api.twitter.com/1/oauth/authenticate with my app's consumer key; this page will show a login prompt and ask the user to authorize my app to perform actions on their behalf. Upon completion, this page will redirect to a callback URL supplied by my app, with the request token supplied as a parameter.
For web apps this makes sense. I don't understand how this is supposed to work for a standalone mobile/desktop app, though. The Twitter API documentation seems to imply that this should be a feasible option. They do offer an alternative xAuth mechanism that allows an app to gather username/password itself and then supply that directly to obtain an access token. The API documentation points out that this is an inferior option (as it requires the user to trust the app, not just Twitter, with their password), but I don't see how I have any reasonable alternative?
(there is also a PIN-based option, but that's a pretty burdensome solution for the user)
I just want to make sure I'm not missing anything obvious.
"For web apps this makes sense. I don't understand how this is
supposed to work for a standalone mobile/desktop app, though."
Just embed a web browser control in your app, and navigate to the twitter authentication page. Then detect the redirection to the callback url (using the Navigating event) and retrieve the parameter. Many twitter apps do that, it's basically the same as asking the user for the login and password, except that instead of your own controls you're displaying twitter's page.
Nope, you're correct. The option for a mobile/desktop application is either a pin-based option or to use xAuth. Once you have an xAuth application has an access token it is indistinguishable from OAuth (it only changes the authorisation workflow). One thing it does change, and this is very specific to Twitter, is that if you do use xAuth then your application will not be allowed to read or write Direct Messages. See Twitter's The Application Permission Model page for more information.
Our company has a web application that is only used internally by our employees. We also have Google Apps Premier Edition. We would like to make it so our employees can log into our private web application using the Google Apps account that they already have.
Requirements: We want to display our own login form. We don't want to pass the email/password in plain text through the internet.
Which authentication mechanism should we use to achieve this?
Note: our application is written in PHP using Zend Framework (if that matters).
I would look into some combination of OpenID and your domain users (i.e. only let those at domain.com can log in).
Google API
They also have libraries for PHP and other languages that you can leverage to make this happen.
EDIT:
Some more info
When it comes to integrate Google Apps and an internally used private system, we simply have two options.
Use Google as the authentication center. Modify the private system to authenticate at Google's server. We could use OpenID or AuthSub. Check http://code.google.com/apis/accounts/docs/OpenID.html and http://code.google.com/apis/accounts/docs/AuthSub.html for more information.
Use the private system as the authentication center. In this case, we have to implement SAML protocol in the private server and configure Google Apps's SSO settings. Check http://code.google.com/googleapps/domain/sso/saml_reference_implementation.html for more information.
It is easier to accomplish SSO with the first method since there's already bunch of OpenID libraries out there. But, as you described in the requirements, you want to use your own login form. So I guess you have to go with the second method.
BTW, if your private system has to get or set information from Google, you may want to use OAuth for authorization. See http://code.google.com/apis/accounts/docs/OAuth.html for more information.
Use the ClientLogin API, it does exactly what you're after: allow you to verify username and password. (the link goes to provisioning API doco but that is not relevant here)
Pro's:
you get to use you own login form
Cons:
you don't get SSO with Google Apps, i.e. users already in Apps will be prompted to login again (you didn't mention that as a requirement, but it seems a reasonable thing to want)
Google won't like you (they're trying to discourage ProgrammaticLogin.
you will get occasional CAPTCHA tests you'll need to show your users.
OpenID specifically prevents you from displaying your own login page, so if that's a hard requirements, Programmatic Login is really your only choice.
Going the SSO route let's you do pretty much anything, but may be a bit of overkill to take on authentication for the whole domain to make one app authenticate in a nicer fashion? If you really want to go down this route, check out SimpleSAMLphp.