I am integrating my SAAS application to Microsoft Teams. Right now integrated as Tab in teams. I am using my own API endpoint to authenticate and authorize the user. I have got some specific information about the user I am getting from API. How can I store it in Team context? Right now I used local storage in the web app. In Teams web app it seems working but I don't think it is working in Desktop app. Is there some API available in teams which helps to maintain the user state with Tabs? similar to userstate in Bots? Please help.
I would think local storage would be troublesome across devices anyway, perhaps consider server-side storage instead.
Related
I have a Teams application (Tab). I am an ISV provider, and provide a multi-tenant application that is installed by customers via Teams App Store in their organizations.
How do I save settings for my application organization-wide for the customers? For example, CustomerA has installed the app and then CustomerB. I want some storage that would be unique for CustomerA and CustomerB and the app, and located in customer's environment. The settings I want to save are not per-user, but per-organization (tenant).
Somewhat similar to "App Data" folder you have in Windows Desktop for example.
Does such a storage exist? Does API for this storage exist?
A tab app is a simply a web application that you render inside of Teams. As a result, what the app does, and where and how it does it, is totally up to you. This includes any data storage you choose to have behind the scenes. For example, your tab could be built in PHP and use MySQL, or built in ASP.Net and use SQL Azure or CosmosDB. It's totally up to you, but you need to implement it yourself, as an ISV.
The important piece to differentiate clients, however, is being aware of the TenantId for each user, so you can look up which client's settings you need from the database. The most simple way to do this is simply the tid property on the Teams tab context. You can read more about that here. Unfortunately, because it's just accessed via Javascript, it's not entirely secure - for a more secure mechanism, you should be creating an Azure Application, and generating jwt tokens that you can authenticate against in your backend. It's a much more complex topic, but hopefully this answer at least gives the background you need. For more info on the security aspects (validating the token etc.), please see this question: How to restrict access to Azure Function to only allow requests from a custom Microsoft Teams App?.
I am quite new to Teams and to building bots for it.
Using NodeJS, I built a simple prototype one that can receive notifications and send requests to my software.
However, my software is installed on-premises, which means all users using it have a different domain name for it (xxx.com, abc.com…). To be able to use it, the app needs to know what is the endpoint of the requests.
I wonder how I can build my bot app in those conditions and have it in the Teams Marketplace.
My question is :
I assume I want a team admin to set the domain name in some app settings before installing it for a team and users to use.
Is that possible somehow? Is it even possible to build such an bot app?
I suppose it is possible to achieve that by having the users install a custom app, but then the app cannot be in the Marketplace.
I also suppose I can ask individual users to first enter the name of the domain, it sounds repetitive and the info would then be stored in some userData.
Isn't there some teamData instead? Could it mean having one user set those information and have them stored for everyone?
My enterprise application is developed in .net framework 4.5 and is using windows authentication. In which case, as we all understand, it is the underlying AD(active directory) that authenticates the user.
I have to replace windows authentication with token based authentication, keeping the .net framework 4.6 and AD(active directory). I guess oAuth is a possible solution, could you please share some thoughts on other possible solutions and as how could I get started.
HISTORY
It was common some years ago for apps to be developed for a corporate intranet, in which case Windows Authentication was a good solution. When token based authentication came along the benefits typically were:
Extend reach so that apps could be used over the internet
Support cross domain scenarios, eg APIs in a different domain
Support multiple authentication methods / policies depending on user location and device type
Write less security code and make new security features available to multiple apps
IMPLEMENTATION
An OAuth migration is a major architectural change and needs to be managed in terms of costs and benefits, though once done your apps will be quite cutting edge. Here is how Windows Authentication typically works in an OAuth 2.0 / Open Id Connect world, which requires a more complex setup:
Your UI redirects to a Cloud Authorization Server (AS), such as Azure Access Control
The AS redirects to an identity provider - such as an on premise version of ADFS (Active Directory Federation Services) - that is configured to use Windows authentication
When in the corporate intranet the user is automatically signed in and ADFS posts tokens to the AS
The AS posts different tokens to your UI
Your UI calls the API with the AS token and the API validates it
GETTING STARTED
If you decide that the effort is worthwhile then there are 2 parts to the job. Note that your application code will only ever interact with the AS and doesn't need to know or care about the authentication method:
Infrastructure migration
Updating the code in your UIs and APIs
If it helps, my blog and code samples are designed to help people deal with some of the challenges of OAuth tech. Maybe have a look at my first tutorial to get set up.
I have implemented an application which accesses calendars in an Office 356 E3 tenant. I've used the client_credentials flow and obtained Admin Consent. So far everything seems to work as expected.
Now I have a customer how wants to use my application with an Exchange 2016 on-premise setup. Is there a way to use the same application in this setup as well? Or do I have to implement a new application using EWS?
The graph API is not available on on-prem Exchange, so yes, you have to replace the graph API code with EWS code.
Depending on your use case, it is probably possible to abstract it such that your application can use either one or the other.
We had a similar issue.
You can change from Office365 Api to the MsGraph Api which supports many of the same features as the Office365 Api does. Your on premise customer needs to put his Exchange servers into hybrit mode for this. MS explained the necessary steps here.
The only problem we had is that you cant subscribe onto on premise calendars.
Here is the MsGraph Api doc
https://learn.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0
You can also consider switching from Office365 to MsGraph entirely as this should also work for you Office365 customers. As I understand it MS is gonna expand the MsGraph Api in the future giving us a single point of contact for interaction with the Office suite and authentication.
#Marc LaFleur pls correct me if I'm wrong on this
I'm looking at using the Bot Framework (https://docs.botframework.com) is it possible to register a bot programmatically e.g via service? I see there are Azure bots but still don't see a way to register via service?
At the moment you have to manually log into the portal to register the bot and obtain your keys. There has not been any indication from Microsoft that this will change in future.
from what I know about the goals of the dev team, since this is a highly requested feature, we will probably see this in action in future version of the bot framework.
But no kind of timeline yet for this feature.