We´ve created a sharepoint-hosted Addin and want to authenticate to our enterprise Azure Active Directory. We tried to migrate the AADTokenProvider from the sharepoint webpart, to get our AccesToken from our AAD.
Following is the dependency which provides the AADTokenProvider
- microsoft/sp-http
Unfortunately the dependencies aren´t standalone packages.
What´s the correct way to accomplish the authentication from sharepoint addin to a Azure AD?
SharePoint Add-in is an identity principal just like a user, and it must be authenticated and authorized to use SharePoint resources. There are three authorization systems that an add-in can use. They are not mutually exclusive.
Three authorization systems and when to use them
Low trust-
A provider-hosted SharePoint Add-in can register with Microsoft Azure Access Control Service (ACS), which issues an access token to the add-in that allows the add-in access to the resources in the SharePoint tenancy or farm on which the add-in is installed. Azure ACS is the trusted token issuer in an OAuth 2.0 Framework "flow" that includes SharePoint and the remote components of the add-in. Add-ins that use this system can be sold in the Office Store. The low-trust system is primarily intended for add-ins whose remote components are hosted in the cloud.
For more information about creating a SharePoint Add-in that uses the low-trust system, see Creating SharePoint Add-ins that use low-trust authorization.
High trust - A provider-hosted add-in can establish trust with SharePoint by using digital certificates. The high-trust system is primarily intended for add-ins whose remote components are hosted on-premises. The add-in can be installed to a SharePoint farm that is not connected to the Internet. The add-in cannot be installed on SharePoint Online or sold in the Office Store.
For more information about creating a SharePoint Add-in that uses the high-trust system, see Creating SharePoint Add-ins that use high-trust authorization.
Cross Domain Library - When the add-in's business logic is in JavaScript, you have the option of using the SharePoint cross-domain library either in place of, or as a supplement to, the low-trust and high-trust systems. The library is also intended for scenarios where the add-in has cloud-hosted components, but the customer's corporate firewall makes it difficult to use the low-trust system. The user's browser blocks scripts from other domains, but the library encapsulates a secure system for working around this restriction. Add-ins that use the library can be sold in the Office Store and can be installed to either SharePoint Online or on-premises SharePoint.
For more information about creating a SharePoint Add-in that uses the cross-domain library, see:
Creating SharePoint Add-ins that use the cross-domain library
Solving cross-domain problems in SharePoint Add-ins (blog post)
Hope it helps.
Related
We have a client that uses SCCM to deploy Excel to their users and according to them, they package other add-ins with Excel so that when it's installed they have access to these add-ins.
We have an Office Add-in (specifically Excel), not the VSTO or COM add-ins, a web Office Add-in.
I've done some research and I'm struggling to find a solid answer as to if it's possible to deploy the add-in with SCCM? So far my deduction is no, but I thought let me confirm with the professionals.
And then is there any other solution on how to deploy the add-in otherwise?
Please note the following restrictions on their end
Locked the Office store, users cannot install an add-in from the Office store
Don't have access to the Admin Center to deploy the add-in
What I have tried ?
I have tried using Power Shell to upload office add-in by referring following link,
Use the Centralized Deployment PowerShell cmdlets to manage add-ins
but I ended up receiving,
PS C:\WINDOWS\system32> New-OrganizationAddIn -ManifestPath 'D:\Manifest\manifest.xml' -Locale 'en-US'
Extracting Add-In's manifest...
**The Add-In you are trying to upload supports Single Sign On and to upload the Add-In you need to use Office 365 Admin Center.
Press Enter to consent to the Add-In in Office 365 Admin Center.**
If there are any issues you can go to
https://portal.office.com/adminportal/home?assetid=lob&mktcmpid=powershell#/Settings/ServicesAndAddIns
And go to Settings > Services & Add-Ins
Also, the URL mentioned in above message, which is, https://portal.office.com/adminportal/home?assetid=lob&mktcmpid=powershell#/Settings/ServicesAndAddIns is old. We no longer upload add-in from this endpoint.
Additionally, I do have referred,
Deploy and publish Office Add-ins
As, since it is an Outlook add-in, it cancelled out uploading it via SharePoint app catalog.
Is there any other way that I can do it using command shell or rest APIs ?
Additionally, is there any restriction to upload add-in which supports Single sign on via PowerShell ?
We created multiple powershell scripts that read from word document and extract required information.
Locally on laptop all works fine, but when we deployed on production server.... they dont work.
We run powershell scripts through asp.net web app... that's where any powershell scripts that refers to WORD.APPLICATION are not working
Components we deployed on production server:
operating system: Windows Server 2012
Powershell: Version 5
MsOffice 2010 installed
Asp.net 4.5 all components installed
We have created web application in ASP.NET 4.5 Core where user upload documents and based on certain criteria documents will be searched for specific keyterms. if keyterms found, values will be displayed.
Asp.net invokes powershell script which has all document library code to search through. Everything gets executed in PS script, except where WORD-APPLICATION code is referred.
Has anyone faced any issues while deploying them on server?
Required reading:
https://support.microsoft.com/en-us/help/257757/considerations-for-server-side-automation-of-office
All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.
...
Besides the technical problems, you must also consider licensing issues. Current licensing guidelines prevent Office applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA).
As you can see, the scenario you're trying is officially unsupported, and license wise very expensive, as you officially require an Office license for each user invoking your functionality or for whom you're invoking the functionality.
There is an official Open XML SDK, which will allow server-side processing of the XML-based office documents:
https://learn.microsoft.com/en-us/office/open-xml/word-processing
If that isn't enough, there are a number of 3rd party libraries that provide server-side execution and don't require office licensing, some commercial, some open source:
Aspose: https://www.aspose.com/
NPIO: https://github.com/dotnetcore/NPOI
There are ways to get your code working on the server from an ASP.NET Application. They are officially unsupported, they open up your server to a number of extra security issues, they are very expensive from a licensing perspective and there is no guarantee they will remain working.
I developed an add-in for Word.
The Microsoft docs state that
To sell Office Add-ins to organizations, you need to create a licensing database. This is necessary because:
...
Centralized deployment does not allow users to buy add-ins from AppSource and deploy them. AppSource paid add-ins today only work with personal identities (Microsoft accounts), not work or school accounts.
So, if I want an organization to adopt my Office Add-in I have to handle the licensing workflow myself. And if I understand this correctly, an organizational user would not download/install my add-in thorough the AppSource(AS). So...
How does an organizational user actually get the add-in? They don't purchase it from the AS—their organization already purchased the add-in. So how does the user "find" the add-in and install it in their Office instance?
When an add-in uses Centralized Deployment, the add-in is automatically installed for all users. For example, if it has ribbon buttons, they will automatically appear on the ribbons of the users for whom the add-in has been deployed. So, the user doesn't do anything to install the add-in. For details about how this works, see Centralized Deployment.
First post here. Facing a problem where on Windows 10 an Oracle Identity Access Management (IAM) Windows Native Authentication (WNA) protocol fallback to a form-based logon page always fails whenever the Microsoft Online Services Sign-In Assistant (SIA) is installed. Whenever we remove the SIA, the WNA fallback to a form-based logon page always succeeds. This error is reproducible 100% of the time. We have not tested on Windows 8 or Windows 7. I've researched it, and there is not much out there to read about the SIA; it does not look to be configurable on the client end. Really want to avoid changing up code on the IAM WNA side.
Anyone out there seen this before? This is a large enterprise network, using all Windows 10 computers, which has both Oracle IAM running for some applications as well as Microsoft Windows 2008 R2 Active Directory, to which all the Windows 10 computers are joined. We are also standardized with Office 2016 with all back-end servers supporting Office apps such as Outlook, Lync, etc. in the cloud (Office 365).
Please let me know if I need to show the Oracle IAM/WNA SSO fallback code.
The Microsoft Online Services Sign-In Assistant is not configurable. But, if all your computers are running Office 2016 you do not need it anyway and it can be safely uninstalled, which as you said will make the fallback to form-based logon page work. If you were running Office 2013 you would need it however. Office 2016 apps such as Outlook and Lync can go direct with ADFS whereas previous versions could not do this. I don't have a URL reference for you, this is based on my experience.