Is there a way to mimic powershell's Get-AzureADUser to read AD properties on given users without having to register the C# console app I am trying to build with Azure?
I know you can run powershell in C# but I am wondering if there is a different route I can take to achieve the same thing WITHOUT registering the app?
Short Answer: No. You will need to register an application with Azure AD to be able to authenticate.
Longer Answer:
AFAIK all of the OAuth 2.0 grants for authentication supported by Azure AD will require some information about the client (i.e. registered application) that is being used to make the authentication call. This would be true whether you use ADAL Libraries or directly hit the relevant token/authorization endpoints.
You may already know but it's worth mentioning that the simplest and recommended way to do authentication/query user data with right privileges will be to register your application with Azure AD.
In fact default setup for Azure AD, is such that it promotes the use case of developers being able to register applications and consent to applications on their own behalf. Read here.. Who has permission to add applications to my Azure AD instance? and at the end it mentions that Microsoft itself uses the same configuration internally.
Full Disclosure: I know that some very knowledgeable people (Microsoft MVP's, Microsoft Azure AD team members) follow the azure-active-directory tag. So even though I think this is the right answer, your question is such that it would make sense to wait for more answers/comments to see if there is anything else possible.
Possible workaround if it suits your scenario:
In case you don't want to register your application just because you don't have permissions to a specific Azure Active Directory tenant, there may be a workaround possible.
You would still need to register your application but with a different Azure AD tenant or with Azure AD B2C, and then make your application as a multi-tenant. See this SO post for more details.
Related
Is it possible to pull work items from the DevOps API without needing a user to be logged in to get an access token every time?
I am trying to create a back-end service that pulls work items from the API every so often to generate a report. Can I just generate a one-time access key to use with that back-end service?
I've looked around the documentation, but it seemed like it all requires either a PAT or Azure Active Directory authorization/authentication.
Here's the docs for the API: Link
you can do something like this https://learn.microsoft.com/en-us/azure/devops/organizations/settings/manage-authorizations?toc=%2Fazure%2Fdevops%2Forganizations%2Ftoc.json&bc=%2Fazure%2Fdevops%2Forganizations%2Fbreadcrumb%2Ftoc.json&view=azure-devops
and
https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops
Basically authorize applications to use devops based on your credentials using oauth. similar to an app registration.
Thats the only way I can see without PAT and manual login each time.
Instead of your personal account, you could create a fake AAD user then add it to your Azure DevOps Service.
Use that account to create a Personal Access Token. Similar to Build Service account to pull source code/work items. This should be a easy way to track everything.
But the limitation here is also obvious: this needs involvement of IT department, and also causes additional costs, since every user is billed.
Allow personal access tokens that do not expire is not supported right now. There is a related user voice.
As an alternatively way you could use OAuth just as alphaz18 suggested. Details please refer-- Authorize access to REST APIs with OAuth 2.0
I am not quite sure how to properly phrase this question so I will do my best to explain my issue.
I have a .Net website that works using Active Directory. It works great. No issues. However I have a need to stand-up a new copy of the website for an office that won't have access to Active Directory.
I am trying to come up with any possible solutions that will allow me to accomplish this without having to rewrite large portions of our user code base.
I might have to accept the fact this might take a lot of work but I figured I would try to explore any possible options before I jump into that.
Depending how the site is built, you might be able to set up an AD LDS instance on the web server that would mimic some of the services AD provides. OpenLDAP might do something similar.
You still probably need to change some things on the site, but this might let you get by with changing a lot less.
Does the user :
-Access an IIS hosted site via windows authentication (like on an Intranet) ?
-Access an IIS hosted site using Azure AD (user signs into azure ad or office 365 via browser)?
-Access an azure hosted site using Azure AD (user signs into azure ad or office 365 via browser)?
You might consider some refactoring your application to use Microsoft's Identity framework which will allow you to easily plug and play how your application authenticates.
For .NET framework
Take a look at using ASP.NET Identity
https://learn.microsoft.com/en-us/aspnet/identity/overview/getting-started/introduction-to-aspnet-identity
For .NET Core
Take a look at using Identity on ASP.NET Core
https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity-configuration?view=aspnetcore-2.1&tabs=aspnetcore2x
By using these frameworks, you can keep your login code the same and change the way the user is authenticated.
Hope this helps! Cheers!
Does Azure support a programmatic way of registering an application via the users Microsoft account (Using Azure Active Directory)?
Example 1
I am unable to find anything through the Microsoft docs. Everything related to this indicate a manual application registration has to be done, then manually entered. However, I want my application to support multiple tenants without having to manually input all the information into environment variables.
I would like my application to register itself after a user has signed into their Microsoft account and allow access to my application (similar to Github integration). With that registration, it can then pull down the users tenant information and generate a key for itself.
Edit: I have found some other answers on StackOverflow that mentions using GraphAPI after obtaining a bearer token from Microsoft
Is this still the best way of doing this?
I'm building a .net backend for my Azure Mobile Service.
I would like to execute code whenever someone authenticates with one of the default providers (i.e. Microsoft, Google, Facebook etc.).
Some examples of what I would like to do during authentication:
Associate their MS/Google/FB Account ID with my own user accounts
Add claims to the ServiceUser
To sum it up: is there any way to hook into the server side execution of MobileService.LoginAsync(provider) in a .net backend?
Yes, you should look at the custom authentication feature of Mobile Services, which should be flexible enough for your use case: https://azure.microsoft.com/en-us/documentation/articles/mobile-services-dotnet-backend-get-started-custom-authentication/
You might also be interested in the new AAD B2C offering, which has a lot of features that might fit your scenario: https://azure.microsoft.com/en-us/documentation/services/active-directory-b2c/
I am trying to use Google shopping API. In order to use the API, my application should be authenticated using OAuth2.0. Looks like this method involves user interaction (where user allows the application to access the resource)
Is it possible to do OAuth authorization in non web applications with no user interaction?
This may be a good case for using a Service Account. This would mean that your application isn't running as a user but as itself. That is, as a made up account corresponding to your APIs Console project.
Various official client libraries support the Service Account flow as described in the link above, but C# is not listed among them, so you may have to write it yourself. (Though this issue claims it's supported in the google-api-dotnet-client library, I couldn't find the source for this feature after a minute or two of looking).