Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Is there a way where I can develop a Windows Azure locally without having to create a Windows Azure account?
The reason I'm asking is because I am creating a Web API using C# and a frontend technology (I haven't decided which one yet) and I want to use AAD for my authentication using my user's Microsoft account, and want to test it first if my use case is fit for it without having to subscribe to Azure first.
Thanks!
Based on my understanding, there are two things you want to accomplish:
Build/test a WebAPI using C#.
Use AAD to authenticate your users. Your users will sign in using their Microsoft account.
For #1, you really don't need an Azure account. You could simply create a WebApi application using Visual Studio and test it locally. If the intended backend database is SQL Server, then again you can test it locally by installing SQL Express.
For #2, again you don't need to have an Azure account unless your application does something related to Azure (for example, permission to execute Azure Resource Manager API on behalf of the user). If you simply want your users to sign in using their Microsoft account, you could create an application that uses Azure AD v2 endpoint. To create such application, all you need is a Microsoft account for yourself. You can read more about Azure AD v2 here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-appmodel-v2-overview.
You would need some place to host your application once you want folks other than you to test the application. At that time you would need an Azure account if you decide to host this application in Azure.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I have an Azure tenant and the Azure portal has partner access to all my clients. My requirement is to fetch contracts of each of my partner using the Microsoft Graph API.
I created an application inside my azure instance following the documentation guide. Am able to obtain an access token using https://login.microsoftonline.com/tenantId/oauth2/token endpoint (where tenant id will be my azure tenant id) for the GraphAPI resource and am able to use the GraphAPI rest calls to fetch the contracts as well as the subscribedSkus of my tenant.
However how can i access the subscribesSkus of my clients?. Do i need the tenant id of each of my clients and obtain the access token for each client using the endpoint mentioned above? Does that means i need to create an app on all of my clients azure active directory instance?
Several references for similar scenarios like this can be found across the internet but there is no concrete documentation available in microsoft which assists me to proceed further.
Any insights into this will be really helpful.
This isn't possible, you need to have credentials and obtain a token for each of the tenants you wish to access.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am developing an Nodejs application and using AAD to secure an Azure function.
There would multiple Nodejs clients but I don't need to have a single user for each one of them (all the instances are should be treated as the same client).
How should I go about implementing this and is there any security concerns?
Edit
The protected resource is an Azure Function with a HTTP trigger.
I just want to limit the access to people who have the NodeJs client Installed. I don't want the user to enter his credentials. My question is which flow should I use and how should I go about that?
If you do not want to use the user's credentials, then please evaluate the Azure Active Directory v2.0 and the OAuth 2.0 client credentials flow.
This type of grant commonly is used for server-to-server interactions that must run in the background, without immediate interaction with a user.
While this advised solution may not look like an exact fit, you can use the admin consent and make this work for you. There are additional considerations like securing the credentials on each machine that you also have to look at.
in the client credentials flow, permissions are granted directly to the application itself. When the app presents a token to a resource, the resource enforces that the app itself has authorization to perform an action, and not that the user has authorization.
If this looks promising, then also look at the azure-activedirectory-library-for-nodejs to get you going.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
We have a set of internal testers on our corporate network that are not on the domain (and getting them there is not a possibility for me as a dev). The use case is that a walk up kiosk type device is under test.
I'd like them to be able to submit bugs to a TFS repository without them having to authenticate at all, including entering their username.
Constraints (not questions)
We have a preexisting screenshot thickclient app with the TFS API that will fill in all applicable fields (type type 'what went wrong').
Obviously I don't want to embed a hardcoded username/password in this app.
I understand that this is allowed without a TFS CAL via the Stakeholder role; all the users and devices qualify.
I understand it's possible to wrap the TFS API with a web page and log errors as the web app's login. I'd like to avoid this as the point of not creating logins and registering testers and having them log on is to avoid the administrative costs and time extensions associated with that.
My biggest problem, I guess, is that the testing effort is pretty low budget!
Question: How to I Anonymously add a bug to TFS?
It doesn't support to create/add bugs in TFS without any authentication. No matter how you connect to TFS, from web access page, Visual Studio or using TFS API, it all needs authentication. To do some actions in TFS, it also need to give these accounts permissions. https://www.visualstudio.com/en-us/docs/setup-admin/tfs/admin/setup-ad-groups
In your scenario, those testers are in other domain, you could make the 2 domains trust each other and add their account to TFS. Or if you can't want to do so, you could create some local accounts on your TFS server for those testers. And add these accounts to TFS.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am designing a system that will be running online under Microsoft Windows Azure. One component is a REST based web service which will really be a wrapper (using proxy pattern) which calls the REST web services of a business partner, which has to do with BLOB storage (note: we are not using azure storage). The majority of the functionality will be taking a request, calling our partner web service, receiving the request and then passing that back to the client.
There are a number of reasons for doing this, but one of the big ones is that we are going to support three clients: our desktop application (win and mac), mobile apps (iOS), and a web front end. Having a single API which we then send to our partner protects us if that partner ever changes.
I want our service to support both JSON and XML for the data transfer format, JSON for web and probably XML for the desktop and mobile (we already have an XML parser in those products). Our partner also supports both of these formats.
I was planning on using ASP.NET MVC 4 with the Web API. As I design this, the thing that concerns me is the static type checking of C#. What if the partner adds or removes elements from the data? We can probably defensively code for that, but I still feel some concern. Also, we have to do a fair amount of tedious coding, to setup our API and then to turn around and call our partner’s API. There probably is not much choice on it though. But, in the back of my mind I wonder if maybe a more dynamic language would be a better choice.
I want to reach out and see if anybody has had to do this before, what technology solutions they have used to (I am not attached to this one, these days Azure can host other technologies), and if anybody who has done something like this can point out any issues that came up. Thanks!
Researching the issue seems to only find solutions which focus on connecting a SOAP web service over a proxy server, and not what I am referring to here.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am starting to migrate a couple of applications to Azure. Seems very straightforward and all I have to do is add an addiitonal Azure project to my solution and point it at my web project.
However what concerns me is that the team starts contaminating my applications with Azure specific functionality and relying on it. For example File uploads would be to Azure storage, azure caching etc. All well and good if we stay Azure and all clients are happy to use Azure. If we find a client isn't happy with Azure I'd like not be into a lot of work removing Azure functionality.
Just wondering if anyone had experience similar issues. I guess ideally I'd like to be able to have the project right publish to Azure and it uses Azure features, Azure Code etc and a second publish that just allows me to use IIS with non Azure features.
I assume I just need to be careful use interfaces correctly and DI etc. FileUpload vs AzureFileUpload. What about issues like resources coming from Azure storage for CSS/scripts etc rather than local? Should I look at using Azure Cloud Drive to simulate just standard NTFS environment
Is there any advice/patterns/practices? Has anyone experiences with similar? How about separating projects up and project structure etc? I guess a lot of is it just standard design. Just wondering how other people were approaching avoiding lock in with Azure.
There's a couple things you can do if you're concerned:
Stick to the core technologies like asp.net, ado.net, sql which also exist outside of Azure.
Abstract away code which uses Azure specific services.
For the first one, simply scan your code to ensure the runtime services don't include Azure namespaces.
But, to be a cloud like service and get it's benefit, you should look into adopting azure services.
For the second, you can create a cloud services layer abstracted away by an interface. Only that layer communicates with azure specific services. If you need to work outside of azure, you just need a plug-in for that layer.
If you want the app to be able to run on IIS or Azure, and those are your only 2 targets, my only advice is don't overdo the abstracting / interfaces. There are some differences that can be handled in web.config and WebRole.OnStart(), such as using cache as a session provider or logging diagnostics to table storage.
Some things it will help to create interfaces for, and then inject those interfaces in the config depending on your deploy target (web config transform is what we use). For example in IIS you might want to send an email in a separate thread, whereas in Azure you might use a worker role and a queue. You can set up a web.config transform with 1 implementation of ISendEmails for IIS, and different one for Azure.
Another thing you could do, depending on how much file data you have, is store files as blob columns in the db. I'm sure someone will tell me this isn't good for performance, and can get expensive with GB of file data in sql sever, and they have a point. It may be worth considering though if having IIS/Azure flexibility is of high concern.
I would design a cloud interface (as an abstraction of an actual cloud/network) that your applications can use, together with an Azure implementation of that interface.
Then later, when needed, you can make other cloud implementations that your apps can use using the same interface.
When designing the interface, the challenge is to include only generic methods that are relevant on every kind of cloud/network. So this will prevent using any Azure specific features directly by your applications, but that is exactly the purpose.