I was trying to create an outlook add-in and saw Single sign on is required. However, Appsource does not allow Single sign on add-in.
I need to know if Single sign on add-in is an requirement for an outlook add-in?
Single sign on is not mandatory for submission to AppSource. You can check out Authentication options in Outlook add-ins
Related
I am trying to use Graph API in my outlook Addin.
What is the best way for an Office Add-in to get authorized access to Microsoft Graph using the credentials from the user's Office sign-on without needing the user to sign in a second time?
The below link explains the process, but I don't find any examples for the same.
https://learn.microsoft.com/en-us/office/dev/add-ins/develop/authorize-to-microsoft-graph
Any help is appreciated.
I am new to Azure and Office Add in. I want to migrate one of my Office add in authentication mechanism. currently the authentication is implemented using Office-JS-helpers. I want to replace this library with any other alternative. Could anyone share the best way to migrate.
Application : Office Add in (Word and Outlook)
Add in is written using React 16+ version
App hosted on service fabric in azure
Authentication enabled using Azure AD
Note : I am Looking for SSO Authentication mechanism.
The Overview of authentication and authorization in Office Add-ins section in MSDN explains how to build and configure Office Add-ins to successfully implement authentication and authorization. You are interested in the following - Enable single sign-on (SSO) in an Office Add-in.
Is possible to use Microsoft graph toolkit in Office add-ins?
I'm using React in Office add-in for Outlook.
Are there any examples of this?
Regards
Yes, it is possible. But make sense to use SSO from the add-in to acquire a token. Read more about SSO in Outlook add-ins in the Enable single sign-on (SSO) in an Office Add-in article.
My Azure AD web app fails validation in AppSource with the following errors:
7.9 Your add-in’s packages must be correctly formatted and conform to the current manifest schema. For Office Add-ins, this is manifest
schema version 1.1.
For detailed manifest schema information, see Schema reference for
Office Add-ins manifests (v1.1) and Schema reference for manifests of
SharePoint Add-ins. Also see What are some common errors to avoid when
submitting my add-in to AppSource? in AppSource submission FAQ.
10.3 The version number you specify for your add-in on the Seller Dashboard submission form must exactly match the version number in the
add-in manifest.
How should I resolve this? The app is indeed registered as an Azure AD web app. The errors are however referring to the schema for Office- and SharePoint Add-ins which does not apply to my case. The schema for Azure AD applications does not specify a field for version number.
When you submit an Azure Web app to AppSource using the Seller Dashboard, you are prompted to complete the 'Version' field in the first page of the listing.
The version number for Web Apps using Azure AD should follow the below structure:
n.n
n.n.n
We are planning to create two sharepoint web applications using SharePoint 2010 Enterprise Edition.
All Users that have access to web app 1, should also be able to access web app 2.
This authentication shall be powered by server 2003 active directory.
--> do I need to use claims based authentication?
If so --> can I use Windows Based Authentication with NTLM for that?
The only thing I really want is that users navigating from web app 1 to web app 2 (and vice versa) do not have to authenticate twice.
I do NOT want to configure Kerberos if it is not absolutely necessare though...
Can you give me any hints?
Thanks!
EDIT:
ok - I'll try to be more precise:
In our SharePoint 2010 environment, we've got two web applications running
http(s)://humanresources.domain.com
http(s)://sales.domain.com
Both are running on the same IIS and have host headers configured (with wildcard domain certificate for HTTPS).
Both apps provide a link to the other web application (sales -> humanresources and humanresources -> sales)
Now whenever someone logged in to sales navigates to humaresources, I do not want that that person needs to login again. Therefore I thought I would need claims based authentication???...
Please enlight my brain! :D
EDIT 2:
Thank you for your answers!
#Panagiotis Kanavos - yes we have Users accessing the site from outside our environment: 1) Users which have an AD accound and are working on their laptops outside of our building (e.g.: they have been all day at a customer and are working at home for the remaining hours) 2) We plan to have users without an AD Accound --> Forms Based Authentication: (e.g.: customers accessing our TFS 2010 project protals to get an overview of the project). As far as I know, if you want FBA and WIN-Auth you need to configure Claims Based Authentication...
However configuring a Web Application with Claims Based Authentication did not work. I chose "Enable Windows Authentication" together with "Integrated Windows authentication -> NTLM" as we do not have Kerberos configured (and I'd love to leave it like that ;-)).
However the Users could not login to that application sometimes, and five minutes afterwards it worked. Additionally, when I added permissions to an AD user, SharePoint seemed to save the Token instead of the Group-/Account Id:
e.g.: Instead of MyDomain\user1 it saved something like "0|=MyDomain\user1" and for groups it even only saved weird character strings "022-12.3"
Could it be the case, that my 2003 windows AD does not support that?
IF you are using Active Directory and running both sites within your domain you should not be challenged when users go to either site. It just becomes an implementation issue about who has access to what, either via AD Groups or SharePoint groups.
Claims based authentication is a bit of a different animal. You need to have a security token which contains a number of "claims" about the user, for example UserA is a member of HR and UserB is a member of Sales. Based on these claims you can then have your site/application respond correspondingly. Claims based auth is relatively new for SharePoint and Microsoft and is a bit of steeper learning curve. It may make more sense if you have a mixed mode environment, with both AD and Forms Based Users getting access. However with your described heterogeneous environment it doesn't seem like it's needed.
More info on SharePoint 2010 Authentication is available here.
John
The easiest solution is to create an AD group with the users of both sites and add the group as a user to the Members Sharepoint group of each site. This way users will not have to login at all since Sharepoint will detect the identity of the logged-in user automatically.
Why are you asking about login, claims, and why are you using certificates? None of this is necessary in an intranet scenario where the farm and users are in the same domain or if the farm's domain trusts the user's domain. Do you have users accessing the site from outside your domain?