I am not sure how to correctly handle Google domain application access/revoke. Situation is quite standard:
domain admin installs an application through marketplace workflow (scopes, setup url, ...)
application is than listed in admin console for domain (https://admin.google.com/AdminHome?fral=1#AppsList:serviceType=MARKETPLACE)
everything works fine, users can access app
at some moment, for some reason admin revokes application data access through the admin console for whatever reason (application is not deleted, only "disabled")
since than, as there is no privilege granted for app in domain, every user who accesses the application is redirected to error page
And here comes the question - how to properly detect and handle this. As some Google docs say, app should re-request required privileges through consent screen (approval force param).
But as my tests show - when user (admin or non-admin) accepts scopes needed on consent screen, application on admin console is still displayed with no data access.
But the same application is instead listed in user's connected apps (https://security.google.com/settings/security/permissions), even it is domain-installable app!
So do I programmatically handle this situation. Is there a way, or should I just redirect (admin)user to admin console to manually turn data access for that application on?
BTW, after marketplace installation, "sometimes" another consent screen pops up first time visiting app url - which obviously requests same scopes as marketplace listing - why is that?
On that case, application is dually listed like in previous case - in domain and in user's connected apps.
Related
I am creating a windows plugin which would access Yammer data like groups user follows etc, for this i created a client application and accessed yammer rest api using client id and access token i get after user allows my app to access his data in a consent page. I am able to successfully do all this when people of my network are trying to login but this does not work when the plugin is being used by people of other networks, I am able to receive the access token after the user gives his consent in user consent page, but when i try to access his data like fetching groups using rest uRL i get an error saying "{"response":{"stat":"fail","code":17,"message":"Attempt to access a protected resource failed."}}"
please be noted the client app i created is not yet deployed into Global App directory, I really doubt if this is the actual cause of the issue, because i think if this was an issue it should not have recognized the client id itself and would not have shown the external network users the consent page too. may be if i am wrong please correct me
To access users on other networks' data, your app must be globalized (even if you don't want it to be listed in the Global App Directory). Without the user's consent, your app is not allowed to attempt to login on behalf of the user, thus they see the popup for authentication, and then the auth process fails because the app is not globalized.
Background
I have a Web API registered in Azure AD and secured using WindowsAzureActiveDirectoryBearerAuthentication (OAuth2 bearer token). This is a B2B-type scenario where there are no interactive users - the applications calling the API are daemon-like background apps. As such, I don't need any consent experience - I just want trusted applications to be able to call the API, and other applications - even if they present a valid OAuth token - to be denied.
What I've tried
This sample seemed to describe my scenario almost exactly. However, the way it determines if a caller is a trusted app or not is by comparing the clientID presented via a claim by the caller to a hard-coded value. Obviously you could store the list of trusted clientIDs externally instead of hardcoding, but it seems like I should be able to accomplish this via configuration in the AAD portal so that a) I don't have to maintain a list of clientIDs, and b) I don't have to write my own authorization logic.
It seems like I should be able to define a permission for my API, grant that permission to each calling app in AAD (or a one-time admin consent), and then in my API just check for the presence of that permission in the scp claim.
From looking at the portal it seems like this is what Application Permissions are intended for:
I can create a permission just fine via the application manifest. Unfortunately, I can't figure out how to specify that it's an Application Permission, not a Delegated Permission! I tried changing the type from User to Admin as described on MSDN, but that seemed to have no effect.
"oauth2Permissions": [
{
...
"type": "Admin",
...
}
Question
Am I correct that Application Permissions are the best solution for my scenario? If so, how do I configure it? Or, as I fear, is this yet another feature that is On The Roadmap™ but not currently functional?
Ben, Application Permissions are declared in the appRoles section of the manifest. Indeed, if you declare an appRole called say 'trusted' in your resource application's (storage broker demo) manifest - it will show up in the Application Permissions drop down there. Then, when you assign that Application Permission to the client app - the access token that the client app will receive using the client credentials OAuth flow will contain a roles claim with value 'trusted'. Other apps in the tenant will also be able to get an access token for your resource app - but they wont have the 'trusted' roles claim. See this blog post for details: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/
Finally, the above way to assign an application permission to a client app only works when both the resource and client application are declared in the same directory - if however these apps are multi-tenant and a customer will install these apps separately - a global admin from customer's directory will need to consent to the client app - which will result in the application permission getting assigned to the instance of client app in the customer's tenant. (my blog post covers this too)
Hope this helps.
ps: if you're stuck - feel free to ping me on the contact page of http://www.dushyantgill.com/blog
We are integrating our app in the new Google Marketplace.
Our marketplace config in the developer console is ok.
Our oauth2/sso flow is ok (scopes match the ones setup in the console, auth params ok)
All users, when accessing our application through the Navigation bar, don't see any consent screen. All is perfect … except the following :
when an admin user is installing our application for his domain for the first time, he is presented with the domain consent screen displaying the scopes defined in our marketplace config, which is fine, he accepts and is presented with a button "Launch app". This link hit our server and a redirection is made to google auth in order to get the email and profile of that user. The redirection happens quickly that the admin is presented with yet another consent screen displaying the exact same scopes … which is bad.
If we wait 10 - 20 seconds before clicking the 'Launch app' button and after having accepted the scopes for the domain, the redirection to google auth is done and no consent screen is presented to the admin.
Are we missing something? Some sort of pooling technique with callback? "Sleeping"?
The same happens with other apps available on Google Apps Marketplace.
I installed several apps from Marketplace (Mavenlink, Lucidchart, etc), and they showed exactly the same result. I was prompted with consent screen immediately after installing them. A bit later, and I was let in without prompting.
It seems that the information on the installed app is not immediately propagated through Google system. There is a short delay between the time the administrator installs an app to his domain, and the time that app becomes available on his domain.
Most users wouldn't mind to wait a minute after the installation. Unfortunately, a reviewer at Google is not that forgiving. If he is quick enough to start your app immediately after the installation, your app will be caught asking for consent, for which it will be rejected from Marketplace. Too bad.
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
My scenario is as follows:
We built a grade school application that was approved for the Google Marketplace. When the school Google domain administrator installed the application, he had no problems. Going to the application settings he did not expect to see the user the access panel. The application is requiring the domain admin to give access to the school application one user at a time. For a domain with over 2,000 users, giving access to each, one at a time, can become a big problem. I have seen many Google Marketplace Apps where the admin does not have to give access to each domain user, basically because the app is already accessible to all domain users.
What API (such as DIRECTORY API) did we have to include in our application? Or did we miss anything in the Application Manifest to overcome this issue?
As long as you specify the same scopes in the APIs Console as you request in your app, users will not be prompted.