My team is in the process of developing an Office 365 add-in, specifically to enable interaction with a hosted web application, and we're encountering a "Permission needed / Bad Request" error that we can't seem to pin down.
Context:
Developing and testing the add-in involves configuring an Azure Active Directory v2 application via the management portal as well as (for development purposes) creating an xml manifest file (which is for v1 apps as opposed to the json format for v2) that can be side-loaded via the O365 interface to provide access to our hosted app (currently only xml manifests can be side-loaded). We're still very much in the process of figuring things out in Office 365, as well as Azure/Active Directory and Microsoft Graph, and the documentation is fairly broad and doesn't always seem to be up to date.
Problem Description:
One of the problems that we're run into occasionally is encountering a "Bad Request" dialog message (in a browser dialog titled 'Permission needed') that is displayed when clicking the toolbar icon for our add-in. The actual URL being requested is similar to https://store.office.com/client/consentnotification.aspx with a number of parameters representing our application and it's required permissions. This results in an HTTP 400 with "Bad Request" being the only response content.
This is happening when the user clicks on our add-in in the O365 application toolbar and is occurring at the point where the user would have to authorize permission for the add-in.
This error seems to be related to the application configuration, but we can't seem to sort out how specifically (ie, some developers are encountering it, and others are not. Sometimes it'll show up if we recreate the Azure Active Directory application using one version of portal or another (there are currently two, with the v2 version being in preview).
Can anyone offer suggestions as to what might be causing this or provide information on why this might be occurring? We're not blocked, but it is rather annoying to deal with in development. I've done a fair bit of research trying to sort out why this is happening and I've gone through a number of tutorials/introductions on configuring Azure apps without success.
This turned out to be related to the Azure Active Directory Application configuration.
For the applications where this was occuring, the AADv2 application manifest was using a "signInAudience" value of "AzureADMyOrg". For cases where it was working as expected (ie, properly populating the permission request dialog) the "signInAudience" was set to "AzureADandPersonalMicrosoftAccount".
After some testing, the solution for our particular problem seemed to be either manually editting the AADv2 application manifest (json) to have "signInAudience": "AzureADandPersonalMicrosoftAccount", or via the Portal by setting the Application's Authentication Supported Account Types setting to be "Accounts in any organizational directory" (this results in a manifest setting of "signInAudience": "AzureADMultipleOrgs" which also seems to work).
Related
I need Azure AD users to be synced into my application, so I've been researching how to implement SCIM and configure Azure AD to work with it. My end goal is to have my application listed as the ones here: https://learn.microsoft.com/en-gb/azure/active-directory/saas-apps/tutorial-list, and to do this, it should support SSO + User provisioning.
The implementation is kind of straightforward as SCIM is a standard and I just need to implement a bunch of APIs complying with a specific contract, so this should work.
The problem I'm having, though, is I cannot find how to enable the "Provisioning" feature for my application. I've been reading the articles and watching the videos Microsoft provided (https://learn.microsoft.com/en-gb/azure/active-directory/app-provisioning/configure-automatic-user-provisioning-portal for instance) and it seems that when I click the Provisioning section in my app, I should be able to configure it. Unfortunately, I don't see the UI shown in the tutorials, so I suppose I've been missing some step that is not explained in the docs. Also, I'd expect to have somewhere to configure the base URL that should contain all endpoints required for the SCIM standard. I don't see this either, which confirms my feeling I'm missing something essential.
Here are the steps I've been taking:
Open the Azure portal
Create an enterprise app - Click on Enterprise applications, Create your own application, and Integrate any other application you don't find in the gallery (Non-gallery)
Once the application gets created, I can't see anything in the "Provisioning" settings
I found a solution to the problem I've described above. Unfortunately, I somehow the big blue "Get Started" button in the middle of the screen. When you click this button, the configuration I've been looking for appears and it is all good.
I'm working on build Office add-in with Adal.js for AAD integration. And my add-in requires some permissions.
When I open add-in in OneNote and try to call login from adal.js, it request login.microsoftonline.com and gives X-Frame-Option Deny error.
I think it's because office add-in running in iFrame, how can I workaround this?
login.microsoftonline.com/common/oauth2/authorize?response_type=id_token&cl…nt-SKU=Js&x-client-Ver=1.0.13&nonce=ced03385-f1ca-4206-bb23-6c3e8338a0d2:1 Refused to display 'https://login.microsoftonline.com/common/oauth2/authorize?response_type=id_…ient-SKU=Js&x-client-Ver=1.0.13&nonce=ced03385-f1ca-4206-bb23-6c3e8338a0d2' in a frame because it set 'X-Frame-Options' to 'DENY'.
Authenticating with OAUTH flow within an office web add-ins is a known issue.The better explanation of the problem can be found here.
Due to the popularity of clickjacking on the internet, it is common to
prevent login pages from being display inside frames. The
X-FRAME-Options meta tag in HTML makes it easy for providers to
implement this safeguard on a widespread or domain/origin-specific
basis. Pages that are not “frameable” will not load consistently in an
Office add-in
Therefore you need to rely on a popup mechanism. In one word, the authentication flow will be made on a popup to avoid iFraming problems.
The link above is a little bit outdated because it states that popup is a necessary evil. Microsoft awares of this problem proposed recently the dialogAPI to overcome this problem.
Let us get back to our Adal.js problem. I believe that you should stop using adal.js because it was not meant to be used in our add-in web context. Even if they implemented a popup technique. They do not use the dialogAPI when available.
You should try to take benefit of this dialogAPI when available otherwise you will hit many problems (deactivated popup, security regions etc.).
Your best option is to implement your own flow mechanism or use Office-js-helpers as explained in this response
I have a project including a problem.
After I enabled Datastore Admin, I clicked "Open Datastore Admin" button.
However, I faced an error of "500 Internal Server Error".
An error message is as follows.
The server has either erred or is incapable of performing the requested operation.
In other project, I can open Datastore Admin normally.
I deployed the program of correct project to GAE by eclipse, but same error has occurred.
I cannot find a solution, please help me.
There is a bug report for this issue:
https://code.google.com/p/googleappengine/issues/detail?id=10150&q=%22datastore%20admin%22&colspec=ID%20Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20Log
"This looks to be a problem because you are using non-default authentication scheme.
Are you using user service/Google Accounts API for authentication of users inside your application? If not, consider changing your authentication method.
If you are, then you'll need to setup a custom domain and access the datastore admin via:
https://ah-builtin-python-bundle-dot-
so that the correct authentication cookies can be used."
I have the same issue, I'm using simpleauth for authentication and I suspect that is the problem... but I haven't solved it yet, changing my authentication scheme is not an option.
OK, this used to work, but it appears to have stopped working on January 1st.
We have a .NET page that is displaying some data to our internal mobile users. This page is set up with Anonymous Authentication in IIS7. (Windows Server 2008 R2 is the OS of the web server.) When accessing via our intranet, the page displays fine. When attempting to access via our Blackberries, we get the following error message:
"Error: Page cannot be displayed. Please contact your service provider for more details. (1)"
Is this an IIS error, an AT&T issue, or a Blackberry issue? My Director is on my case about it, and I'm not experienced enough in IIS to know of anything else that would cause this functionality...
You should check with your network ops team. I'm guessing that the blackberries are accessing the server from the external intranet (that's just a guess though) ... so have them double check that the domain/ip is accessible externally. That could be why you can access it from in the network.
Or if your blackberries are configured to access the network via VPN, I would double check that connectivity.
Forgot to post the resolution to this.
It turned out to be a Blackberry issue. With the latest OS, RIM combined the internal and external browsers into one browser. Said browser attempts to determine if a given site is an intranet or internet site. Even though the BES (sp?) was set up correctly, our service was still spotty. Some people could enter our intranet homepage address and get the intranet; others got the web squatter site on the internet. Since the page we were trying to access was nested fairly deeply in the directory structure, the web squatters didn't have a page with that name in their site. That's why we were getting the error shown above.
Our resolution - we created a different BES alias to point to our intranet, and rolled that out to all applicable users. Utilizing this, the browser didn't have to determine if we wanted our intranet site or the page on the internet; it correctly displayed the intranet page.
We currently have a Silverlight application which is hosted in a SharePoint 2010 page. The Silverlight app makes web service calls to a another server on our domain, which has a clientaccesspolicy file in place. We are experiencing cross-domain issues in our production environment.
Users in the farm admin group can use the Silverlight application without any issues. However, all other users recieve the generic cross domain exception when they try to use this app. We have attached Fiddler to the process and noticed that the farm admins are served the clientaccesspolicy file, but that non-admin users are not. In fact, Fiddler does not ever show an attempt to load this file for non-admins.
This only happens in our production environment, which leads me to believe there is a web config or permission setting causing the issue. Unfortunately, I cannot find anything that backs this up.
Has anyone else run into this issue or know if such a setting exists?
See comments above. I had to change the URL to use the full machine name i.e. from webserver/service.svc to webserver.domain.com/service.svc. It solved the problem but doesn't answer the question about why the farm admins could access it. vorrtex's response is the best possible explanation I have seen so far.