I'm developing an application that incorporates the Skype for Business Online Web SDK. I've noticed that it is not possible to access information about the signed in user's Skype account/profile (via Skype's mePerson object).
The only way that I see to do this now is by having yourself as a contact and accessing information about that account/profile, via the Skype person object. This doesn't seem possible to me as it isn't feasible to set a requirement upon every client using my application to have themselves added as a contact on Skype for Business.
This issue is related to the one posted here, on the GitHub Skype Web SDK Samples page: https://github.com/OfficeDev/skype-web-sdk-samples/issues/1
My question: Are there plans to add the User.ReadWrite Permissions in Azure AD for an application extending Skype for Business? Or, is there a known workaround to retrieve the signed in user's profile/account information, which includes status, activity, or avatar/avatarUrl?
I've also posted this on the Microsoft Azure forums:
https://social.msdn.microsoft.com/Forums/azure/en-US/27d6ebdc-f023-4829-96dd-eefb9e1aaeaf/userreadwrite-permissions-in-azure-ad?forum=SkypeWebSDK
However, I've had no response so I'm also posting here in hopes of anybody having any input. Thank you in advance.
As you might have noticed from the issue link in GitHub, the permissions for the information you're trying to grab have been turned on in Azure AD.
You can plug in your Azure AD settings into the Interactive Web SDK to see it in action: https://ucwa.skype.com/websdk
Before you sign in, you'll need to do the following in the Azure AD management console:
Update your app to use the permissions in the image
Change your app's reply URL to this: https://ucwa.skype.com/websdk
Make sure you turn on OAuth implicit flow by modifying your app's manifest. Steps here https://msdn.microsoft.com/en-us/library/office/mt622687%28v=office.16%29.aspx?f=255&MSPPError=-2147217396 under "Configure your app for OAuth implicit grant flow"
Paste your app's Azure client ID into the "Client id" field on https://ucwa.skype.com/websdk
After you sign in, you'll notice one of the examples in the left hand navigation will let you view the signed-in user's presence, ID, etc.
I've also created a forked version of the Web SDK samples that you can easily update with your own Azure AD settings and deploy to your localhost. You might find this more useful for playing around than the hosted Interactive Web SDK.
https://github.com/tamhinsf/skype-web-sdk-samples
Related
I have been following the Microsoft tutorial/guide for setting up SSO between two Azure bots which is found here: https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-authentication-sso?view=azure-bot-service-4.0&tabs=csharp%2Ceml. I am doing all of the bot testing in the latest version of the Bot Framework Emulator with ngrok.
I have managed to get this working correctly via Azure AD (AAD), however as part of a proof-of-concept, I want to get this working via Azure B2C. Unfortunately, there doesn't seem to be much documentation around about how to set something like this up with B2C, and so far I have not been able to get it working. I have left everything set up the same as was asked in that tutorial/demo where possible (see section below for highlighted differences).
Currently, I am able to log into each bot individually via the above tutorial/demo, but when the SSO is attempted into the skill (child) bot, (via watching the traffic in Fiddler) I see that an error of "consent required" is returned. This tells me there must be some sort of relationship/configuration breakdown between the two bots which is preventing the SSO from succeeded. As mentioned, once this fails, I then get the option in the demo to manually log into the skill bot, which does succeed.
The main differences in terms of configuration capability in AAD vs B2C seem to be:
When configuring the Azure AD app registration for the skill (child) bot, you do not have the capability to set an Authorized client application. Also on this screen, you do not have the option to set the consent for both Admins and users, therefore the consent is set to Admins only
When setting up the API permissions, the delegated permissions available for the Microsoft Graph API are much more limited (only offering openid and profile whereas in the tutorial above more permissions has been asked for)
Thus far I have tried the following to get it to work:
In the app registration for the skill bot, in the API permissions section, I added an API which points to the app registration for my main (root) bot
Manually modified the Manifest for both app registrations changing oauth2Permissions.type from Admin to User to try and relax the scope added in the Expose an API screen (as changing this does change the 'who can consent' column from 'Admins Only' to 'Admins and Users'
Different tenant combinations for the app registration (note that both app registrations are current set up as multi-tenant)
Other things of note:
For the OAuth connection strings, these are set up the same way as the tutorial/demo above, including the Token Exchange URL just pointing to the skill bot scope
I am working under the assumption here that if Azure AD works, then B2C should equally be able to work without any code changes to the demo project, except for different values in the appsettings.json files for each of the two bots.
I am also assuming that B2C SSO in this way is actually a supported feature - there doesn't seem to be a definitive answer either way.
Can someone please provide some suggestions for why this may not be working and what may be required in order to get it working? If I haven't provided sufficient information in any area, let me know and I would be more than happy to provide it.
Many thanks!
How do I create a service account, grant the necessary permissions, and use the Azure billing APIs (usage and rate card) from the server-side of a website?
I'm looking to show expected bill on 6/7/2018 is $123.45 on an internal dashboard, mirroring the data in the billing usage graph on the Azure portal.
https://github.com/Azure-Samples/billing-dotnet-usage-api and https://github.com/Azure-Samples/billing-dotnet-ratecard-api are the samples all posts reference. The setup for each references the legacy Azure portal, and the setup instructions make assumptions I don't understand. I've not found any more recent setup instructions for using the billing APIs. In all my experiments, I've received an OAuth token, but I receive 401 Unauthorized responses when calling the actual API. (Obviously I shouldn't include my guids in this question.)
The samples identify that when creating the app, I must choose a "native application", but Scott Allen notes that "native application" requires a live OAuthed user, but my users don't have permission to the Azure portal, so I must pre-authenticate with configured settings. He recommends "Web apps / API".
The samples are vague in the permissions required. They note I should "make sure the sample app will have permissions to access the Windows Azure Service Management APIs", but from the new portal, I don't find Windows Azure Service Management APIs nor any other permissions that sound like Billing management.
When crafting the AAD App in the portal, and when starting https://github.com/Azure-Samples/billing-dotnet-usage-api/blob/master/ConsoleApp-Billing-Usage/ConsoleProj/Program.cs, each references settings such as "Client ID" and "DirectoryId" that are named differently in different places. Though I feel confident in my mapping guesses, the sample doesn't work for me, so I'm confident I've done it wrong.
I've even tried making requests directly to the REST endpoint at https://management.azure.com/subscriptions/{subscription-Id}/providers/Microsoft.Commerce/UsageAggregates?api-version={api-version}&reportedStartTime={dateTimeOffset-value}&reportedEndTime={dateTimeOffset-value}&aggregationGranularity={granularity-value}&showDetails={showdetail-boolean-Value}&continuationToken={token-value} passing in the OAuth token without success.
What did I do wrong here? How do I configure an AAD app to use the Billing APIs using pre-configured auth and subscription settings to show Azure usage details on a web page?
According to the error log, it seems you don't give your app correct subscription role. You could check this link:Assign application to role.
Note: You could give your app Owner role.
You also check this link:Authentication flow for native application to API.
Also, you also could create a web app. But you need use different way to get the token, see different check this link.
I'd like to add an Office365/Graph Calendar integration to an existing Node.js app (hosted on AWS). I've already done a similar integration with Google's Calendar, and it was trivial to get set up. I'm not having nearly as much luck with the Microsoft version of things.
I've found at least 4 different ways to register an app (get a clientId and clientSecret), and I seem to get different errors for each of them, but can't get any to work properly.
I think a large part of my problem is that I've never had to work in the MS ecosystem before, so I don't have a lot of the baseline knowledge that the documentation assumes.
I'm not looking to host anything with Microsoft - do I even need an Azure account?
I'd like to allow any user with an Office365 account to connect it to my app - do I need to learn about Active Directory to do this? Does this part of it require Azure?
I've found instructions for using both https://login.microsoftonline.com/common/oauth2 and https://login.microsoftonline.com/common/oauth2/v2.0 for this, do I need to worry about which version I use depending on how I registered my app?
Microsoft Graph leverage Azure AD to authenticate and authorize users. The doc refers as:
To get your app authorized, you must get the user authenticated first. You do this by redirecting the user to the Azure Active Directory (Azure AD) authorization endpoint, along with your app information, to sign in to their Office 365 account. Once the user is signed in, and consents to the permissions requested by your app (if the user has not done so already), your app will receive an authorization code required to acquire an OAuth access token.
So you need to register an Azure account for configure the Azure AD service. Refer https://graph.microsoft.io/en-us/docs/authorization/app_authorization for more info.
Meanwhile, to implement Microsoft Graph in node.js application, you can refer the following code sample for your information.
Microsoft Graph service app sample using Node.js
An Office 365 API sample app using Node, Express and Ejs
Office 365 Node.js Connect sample using Microsoft Graph
Matt, you can do this without an Azure account if you use the oauth2/v2.0 auth endpoint. When you do that, you can register on apps.dev.microsoft.com using a Microsoft account.
See this tutorial for doing it with the Outlook REST API, which is similar to the Graph (in fact, for Calendar operations the calls and entities are identical).
I'm creating a Node app that uses OAuth2 to login a user and use the Office365 API to send and receive email, and possibly contacts and calendar events.
I have no need for Azure Active Directory that I know of. However, I am unsure of whether or not I need to register the app with Azure for the OAuth flow.
At first I followed this tutorial, which involves registering the app in the "Application Registration Portal." The OAuth token I receive currently works with the REST API for Outlook. No Azure.
Then I saw this tutorial, which seems to suggest that any app using the Office365 APIs should register an app with Azure. I don't want to do this if I don't have to, mainly because of the cost.
It is not clear to me why I need to sign up for one or the other, and my main concern is that the first tutorial is dated to the point that my app's registration with the "Application Registration Portal" will become deprecated and I will need to switch over to registration with Azure at some point. I have seen plenty of outdated tutorials and information from MS that are not clearly marked as deprecated. Can anyone help clear this up?
Sorry for the confusion. The short answer is that both these methods are still relevant, so none of them are deprecated yet.
Firstly, you're right that you need to register your app to call the Office 365 APIs.
And, you're also right that there are currently two different places to register an app: the App Registration Portal and the Active Directory section under the Azure Management Portal.
Registering on either one of these is enough to get you to a comfortable state where you can call the Office 365 APIs.
However, the convergence of the Outlook.com stack with the Exchange stack means that you are now also able to use the Office 365 Mail, Calendar and Contacts API against consumer Outlook.com accounts in addition to Office 365 accounts. If you wish to take advantage of this, you should register your app in the Application Registration Portal and NOT the Azure Management Portal.
Another advantage of registering through the Application Registration Portal is the support of dynamic permissions scopes. You don't have to specify upfront when you register your app what permissions it requires; rather, you can request permissions at runtime using the scopes parameter.
This new v2 app model for apps registered in the Application Registration Portal is currently in preview. A reason not to register apps in the Application Registration Portal is if they will be using more than just the Mail, Calendar and Contacts APIs. e.g. if your app is also using the OneDrive for Business Files API, you wouldn't be able to request tokens using the v2 app model's endpoint. In that case, you should register your app in the Active Directory section under the Azure Management Portal.
I have created an Azure AD native client application and have given delegated permissions to Azure Service Management API. Now, I'm able to invoke the service management API using my id from a Windows Phone 8.1 app using ADAL library. However, another user can't invoke operations on their subscription even though I add them as co-administrator in my directory. I get the token for the user but when I try to make an API call, I get 'Invalid token:A security token exception occurred for the JWT token'. Is there a way to allow another user to access details about his subscriptions using ADAL authentication from an AD app hosted in someone else's AD? I have searched for any related information for quite some time and I'd gladly take any help.
Here is what I interpret what you are doing.
You have a native app and it is connected to your tenant and it works fine for accessing service management APIs in your tenant/subscription.
You gave the app to a friend and they are trying to use it to access service management APIs in their tenant/subscription.
The suggestion above in the comment is on the right track, but you need to look at the steps for making your native application multi-tenant. This way, the AD service will know to look for the tenant for the authenticated user. Changing the url to use 'common' instead of the tenant id is one of the steps required. Here are a couple of posts to help with that transition.
http://www.cloudidentity.com/blog/2013/04/09/walkthrough-3-developing-multi-tenant-web-applications-with-windows-azure-ad/
This is a native client example of multi-tenant for a windows store app. I could not find one in the repo for a phone app. Hopefully, this gets you on the right track.
https://github.com/AzureADSamples/NativeClient-WebAPI-MultiTenant-WindowsStore