I have a web application deployed on Azure with the Azure Active Directory security enabled (the express setting). So, when I try to access the application, I need to be a part of the AD to have access.
I would like to add more features to the application, like displaying the current user logged in, implement a logout, managing permissions etc... I believe I can achieve all of things with Azure Graph API.
However, to do this, I will need to test some stuff locally. Is there any way to simulate Azure AD locally? It is "switched on" on Azure and everything works great there, but ain't got nothing to simulate this on my local machine.
There is no "local" or "offline" version of Azure AD available.
Your options at this time are:
Test using an actual Azure AD tenant. You can create your own test tenant to allow you to make changes as necessary, postponing the need to work with the admin of your corporate Azure AD until you're ready to go to production.
Create your own Mock STS that implements the OpenID Connect protocol and use that during development/testing. The risk here is that you'll have to make sure that this Mock STS behaves just like Azure AD does or close enough for your purposes.
As a side note, you can create a feedback entry asking for a feature on this in the Azure AD Feedback Forum
Related
We will be building a couple of non-interactive scripts and console applications which will be invoking the Azure DevOps REST API to do various tasks. These apps and scripts will be executed via a job scheduler. What authentication scheme would be the correct one to use for this scenario? It seems like a PAT would work, however, I really don't want the jobs to be tied to a specific user identity and Azure DevOps does not support service principles. Is the correct approach to establish a "fake" Azure Active Directory user and use that user as the owner of the PATs? Is there something else that I am missing here?
Looking at the Authentication Guide, it seems like all of the mechanisms referenced result in some form of interactivity.
Also, we have Conditional Access Policies being enforced in our Azure DevOps organization. One of those policies is the requirement for MFA. If we use a PAT, how will that work? According to this link, it sounds like access may be blocked.
Personal access tokens (PATs) are used for personal authentication. They are alternate passwords that you can use to authenticate into Azure DevOps.
Really don't want the jobs to be tied to a specific user identity and Azure DevOps does not support service principles.
Yes, as you have pointed out. It doesn’t support to create a PAT token with a service account in Azure DevOps Service.
That would be ok to use the public fake MFA account to login Azure DevOps Service. And then use that account to generate PAT token. When request API, others simply use that generated PAT token to authenticate.
With CAP enabled the doc is clear. For Web flows, CAP is honored 100%. That means in most of the situations, Rest API will not be affected.
The limitation is third-party client flow. Some actually due to configuration of third-party. There's nothing we can do in Azure DevOps. You have to follow the policy mentioned in that link. If users do not meet IP range, it will be blocked.
I have created an Xamarin Android App with an Azure App Service back end. When I looked at securing the connection, I don't really care about individual users, but I want to make sure that only someone running my app can access the database. Is there a way to authenticate the app itself rather than individual users? What is the best practice in this scenario?
If you don't care about user, there are a few approaches and the security level may vary. If you want to simplify integration and deployment among Azure services, you should consider using Azure AD as an identity and access management in your entirely system. That said, your back-end and Xamarin app are authorized and authenticated via Azure AD. You need to register your native app in Azure AD which you can refer here https://learn.microsoft.com/en-us/azure/active-directory/active-directory-application-proxy-native-client
Another approach is to use certificate-based authorization against Azure Active Directory, which is more controlled and security rather than client secret. In this case, persons installing your app must also install certificate before sending request to Azure App Service and retrieve database from Azure SQL Database. The level of authorization is free of choice, but the first gateway is always Azure AD.
This isn't a specific problem question but a "cry for help".
My problem is this. Our organization is in the process of implementing Office365.
Until now there were tens of applications with their own authentication and authorization but in the process most of them will be rewritten to use within O365 environment.
We are facing the problem of creating one endpoint (ASP.NET WebAPI app) which will be used to authenticate a user with his credentials from Active Directory (or B2B AD on Azure because some apps are used outside) and tell if this user is allowed to use app that asked to log him.
I'm just wondering through documentations and sample code but can't decide what will be a good practice in this scenario. Should we just build each app and use Azure Active Directory provider to authenticate. Or is it possible to setup ONE api that will hold all apps Ids and its userIds - then it will check user credentials against AD and give app token/cookie...
My best bet is to try this: http://www.tugberkugurlu.com/archive/simple-oauth-server-implementing-a-simple-oauth-server-with-katana-oauth-authorization-server-components-part-1
But create Provider for AzureAD. But then its still question about this B2B AD part.
Please help by pointing to some up to date resources..
You should register each of your B2B application within your Azure Active Directory and configure them to use AAD as the Identity Provider.
Then you can administrate everything you want (e. g. which user has access to which application) within the Azure Active Directory blade from the Azure Portal.
You are getting this backwards. If you have apps integrated with Azure AD you don't have to create endpoint which will validate users right to use apps but you are assigning right to use an app in Azure AD. This is whole point.
I am a developer working on a think client application. One of our customers wants us to provide hosting for the application and I have set up azure remote app for this. The customer is asking if it will work with single sign on.
From what I can see it can work if I have access to their directory. For example if I could join their domain or change my default directory to be their directory it should work. Is this good practice though? From what I see the only way to do this is give their administrators access to my subscription.
Is there another way?
Azure Remote App offers two deployment options
- RemoteApp cloud deployment enables user logon with Microsoft account or corporate credentials federated with Azure Active Directory
- RemoteApp hybrid deployment enables full access to on-premises network, and user logon with corporate credentials federated with Azure Active Directory
So in both cases, you may have single sign on for your customer application, provided his current identity provider (for example On premise Active Directory) is federated with Azure Active Directory
Hope this helps
Best regards
Stéphane
Is it possible to use an Azure virtual machine as an Active Directory server with ADFS 2.0 and integrate it with ACS ?
Regards ,
James Roeiter
Having AD server (with RMS also) in cloud is an ask which I have heard time to time from Azure users and it sure is a great addition to have it running in Windows Azure or any cloud. Various organization's IT is asking the same as well however As of now with current Windows Azure it is not possible.
A few might suggest that using Windows Azure VM Role however, I would say that there are concern over that as well do to persistence and other issues so I would say it is not possible with Windows Azure VM Role as well and there are other issues related with Active Directory product as well to run in Cloud scenarios.
If I answer it directly, I would say as of now it is not supported and suggested scenario to have AD on Windows Azure and will not work due to various reasons.
You can now install AD on Azure in a persistent state. Its still preview but I have just got an standalone AD on a separate network on Azure. I haven't finished wiring up ADFS and ACS but given a little time to get my head around it and I will be there.
Why would you like to put your AD server in Azure? If it just for testing - you can. However the current state of Windows Azure only allows you to have a VM Role, which is Stateless. That means, you may prepare your VM with the AD, all configured for ACS and fill up with users. However you can't rely on any changes to be persisted (including password changed, user edits). VM Role is stateless, which means you will lose your changes once the role is recycled or rebooted, or healed.
So the final answer for the current Windows Azure offering would be - don't do that now, unless you want to just play around and see if it works.
** EDIT **
I am not an AD expert, what I managed to do and have an "in-house-virtualized" lab is to have ADFS on VM integrated with ACS. Another VM running Windows 7, which is domain joined to my AD. Then a web deployed application which leverage ACS with ADFS integration. Everything works fine.
As for storing AD data on external persistent storage - I don't know if it is possible, and how to configure that (already told you I am not AD expert). But if you know how to configure the storage for AD, and if you can store it in an SQL Azure, it is worth to give it a try.
And, finally, as Sandrino mentioned read the provided link to ZDNet's blog post, which has information you might find helpful.