I am following this tutorial:
It mentions that I should get the IssuerName and IssuerKey from the properties of my ServiceBus. There are no properties called IssuerName and IssuerKey when using VS2012 Server Explorer to examine my ServiceBus. When I use the online Azure management console and I click on Connection Information I only get a Connection string not the expected IssuerName and IssuerKey.
Where are these values? I am on the free trial, does that matter?
This is what I see.
http://lh3.googleusercontent.com/-Fj9_XtqozFU/VAX4tBSSBZI/AAAAAAACCcY/zpaGo5EPx9Y/w667-h519-no/Azure.jpg
Go to the CONFIGURE tab and you will see the Shared Access Policies. For the sake of a demo/sample, you can just use the RootManageSharedAccessKey. However, that is not a best practice. You should create shared access policies appropriate for the application, whether it be a client with Send permissions, a service with Send and Listen permissions, etc.
The sample/tutorial also has a bug in it (dated content for an older SDK). In the QueueConnector.cs file, the CreateNamespaceManager should call the CreateSharedAccessSignatureTokenProvider instead of the CreateSharedSecretTokenProvider.
BTW, you can also get these values from your connection string. You just have to extract them from the other values in the connection string.
EDIT
I checked that Microsoft Azure is moving authentication method from ACS to SAS for better performance and manageability, so removed ACS things from dialog for newly created servicebus. Seems that documentation is not yet changed.
To use with SAS, good reference is http://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-queues/ and more low-level approach is described in http://msdn.microsoft.com/en-us/library/dn205161.aspx page.
For more information about SAS (and old ACS), please see http://msdn.microsoft.com/en-us/library/dn170478.aspx
ORIGINAL BELOW
Please go to Azure Portal by web browser. You may find it.
There was a change recently where the associated ACS namespace is not automatically created for a new service bus namespace created via the portal. If you need ACS authentication, you need to create the namespace either via the Management API or Azure PowerShell. I have written up some explanation of this at: http://brentdacodemonkey.wordpress.com/2014/08/27/shared-access-signatures-with-azure-service-bus/
Related
We'd like to create some C# services to intereact with the Microsoft Common Data services.
We are not using Microsoft Dynamics (we might in the future, but that's maybe and not now), so https://<organization-name>.crm.dynamics.com does not seem applicable.
Is there somewhere I should be able to find the Service Uri?
And what do I need to put for most of the other properties? Which ones are required?
Working the Azure Portal, I can usually click around to find Connection Strings.
Is there someway I can do that within Power Apps?
Actually it IS the same as dynamics, since Dynamics in the cloud is built on the PowerPlatform.
checkout here for connection string info examples:
https://learn.microsoft.com/en-us/powerapps/developer/data-platform/xrm-tooling/use-connection-strings-xrm-tooling-connect
I have a c#-based program that can send messages and files to our SlackWorkspace via my SlackApp (I'm using HttpClient to communicate with Slack).
Now, to distribute this program in my workspace and to make it so that every user will have his own identity, it says that I have to use OAuth and create verification-tokens, specific for each user.
It says in the Slack-documentation I have to use a redirect-URL (as per docs) to my own server.
We have a server that I potentially could use for this. But I have never done anything like this before and I am unclear on what "answer" I have to provide from our server. I thought the verification-process would be handled by Slack.
Anyone has an idea on how to approach this?
And before anyone asks - yes we need to install it for everyone and make them identifiable as themselves. We can't use the "SlackApp" as user. :)
I would be very grateful for code examples(in c#) and explanations on how this whole redirect-thing is working.
Slack uses the standard Oauth 2.0 protocol to authenticate apps, similar to Google and Facebook.
So the "verification-process" is indeed mostly handled by Slack (as outlined here), but your Slack app needs to initiate it and handle the responses properly. Also its a multi-step process and includes the user having to login into Slack with their credentials. This why you need a web app to handle the whole process.
To enable a Slack app to generate tokens via Oauth a web app is needed:
can be reached from the Internet
able to handle HTTP requests like a web server
has persistent storage for the newly generated tokens
This is probably easier to implement with ASP.NET Web Pages, which can utilize many functions from an existing web server.
But for this answer, lets look on an implementation in .NET Core. For that we need to create our own web server and some rudimentary session handling. Main concepts include:
HttpListener class for providing fundamental ability to listen and respond to HTTP requests
Handle multiple requests in parallel
Cookies / Session handling
MD5 hashes
The details go a bit beyond the scope of one answer. But I am happy to share a working example implementation on this GitHubGist.
Btw: For the local development of such a web app its recommend to use a VPN tunnel like ngrok, that allows one to expose a local machine securely to the Internet and Slack.
I've to develop a WPF application in an intranet environment with no internet access for security reason. I was wondering if it's possible to collect data locally (on a server) then to FTP them or even better to have the application insight alternative installed on a Server.
Has anyone faced a similar situation and have been able to solve it?
You could do something like that yourself if you really needed to. Instead of using the built in InMemoryChannel or ServerChannel classes to send telemetry, you'd create your own implementation to store them somewhere else. (or you could change the endpoint that the default channels point to to a web service inside the intranet.
you could then collect those files up and ftp them outside, and write another service to read those files and send the telemetry to app insights. Though it seems less like a good idea given the intranet with no internet for security reasons.
Or, better yet, you could simply write internal service to parse and store all that telemetry and show it on that web service inside the intranet and use appinsights only as an sdk and schema, and don't send any of your data outside your intranet at all.
More likely: upvote adding AI to azure stack, (https://feedback.azure.com/forums/357324-application-insights/suggestions/11683746-bring-application-insights-to-azure-stack) and then get an azure stack implementation inside your intranet? then you get all the other goodies of Azure from Azure stack as well.
I'm trying to find a full tutorial on creating your own extent authentication service. Similar to the ones you see that say "Login with Google" or Facebook or Twitter... How do I create my own version of those? Including allowing creation of "apps", creating their app key and secret.
Maybe I'm searching for the wrong terms when looking, I'm not sure.
Ive have a need for a central login service where applications will be able to login a user and receive their information if they have sufficient permissions.
I'm using c# and web api 2 if this helps.
Thanks
IdentityServer (3 or 4 depending on your .Net preference) would be a good place to start. It is an open source project that supports the OAuth2 / Open ID protocols and is very well documented to show you where to plug in your app into the pipeline. https://identityserver4.readthedocs.io/en/release/index.html
We are in the process of rolling out a major application to members of staff, it has been setup to use Azure AD/SSO and we currently have to manually set each user to have access to the application through Azure AD -> Applications -> Users. We have a small c# web application that we use to manage AD users are looking to use the new Microsoft Graph API to set users to allowed access when they are created but can't find the correct endpoint/api call to use.
We have tried the following but the documentation/errors returned are quite lacking.
https://graph.microsoft.com/beta/servicePrincipals
https://graph.microsoft.com/beta/groups/{id}/members
Which endpoint/api call should we use to accomplish this?
It looks like you are looking to try and set appRoleAssignments. This is currently only exposed on the Microsoft Graph /beta version. The /beta documentation needs a little love and attention as you've discovered. However this pretty much should work as it does in AAD Graph (so you could reference the AAD Graph API reference), but with the different root of https://graph.microsoft.com/beta. This blog post also has some examples https://blogs.msdn.microsoft.com/aadgraphteam/2014/12/12/announcing-the-new-version-of-graph-api-api-version1-5/.
Are there any specific challenges that you are facing? What operations and errors are you seeing?
Hope this helps,