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.
Related
This is more of an 'Is this possible' question. A developer on the team suggested using Azure AD for user management, but one of the requirements is that the app admin be able to add/manage user access through the application without having to go to the Azure Portal.
So the question is, is the Graph API (or some other mechanism) full featured enough to replace the portal (at least for basic user set up and management) and allow all actions to be done from the application UI?
Thanks.
Simple answer to your question is Yes. Graph API can be used to manage users and their access to applications instead of using Azure Portal. In fact, Azure Portal itself makes use of Graph API to perform these operations.
You may also need to use Azure REST API if you're planning on managing Azure resources as well through this custom application especially Authorization APIs if you want to manage access to Azure resources (Azure Role-based access control) through your application.
I have a little confusion about directory sync which is used for AD azure integration.
1) Can anyone let me know, whether we can integrate complete on premises AD to
windows azure AD using this? Or only users and groups?
2) If directory sync will not be helpful for complete AD integration what
method will be used?
Can anyone let me know, whether we can integrate complete on-premises AD to windows azure AD using this ? or only users and groups?
Yes, your on-premises AD can be integrated with Azure AD (AAD) with AAD Connect tool. The integration needs prerequisites you can refer here https://learn.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-prerequisites. It means not all the cases can be done. For example, if you need to use password writeback functionality, your on-premises AD domain controller must be at least Windows Server 2008. Another prerequisite is that if your on-premises is using single label domain, it is not supported. Best to check the link above before the integration.
IF directory sync will not be helpful for complete AD integartion what methord will be used ?
AAD Connect provides set of features to help you build a comprehensive hybrid identity between on-premises AD and AAD. However, if this doesn't meet your requirement, you can build some extensions programmatically to interact with AAD. I don't know your preferred programming language, but here is the Authentication Library (ADAL) which is pretty much preferred for AAD development https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-libraries
AAD not only supports user and group sync, but also for custom attributes, filtering, password sync & writeback or so on. Remember AAD Connect is purposely for synchronization. It does not offer too much for AAD interaction (saying that you need to manage, add more attributes or retrieve user attributes, 3rd integration...)
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
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'm developing a tool, similar to Visual Studio's Cloud Explorer, that performs a limited set of management and deployment tasks inside a user's Azure subscription.
I'm thrown-off by a few things relating to authenticating against Azure and how the application represents itself to Azure.
Most of the documentation about authentication with Azure is concerned with web-applications that let users authenticate themselves against an Azure Active Directory. This is not my scenario. While me application necessarily authenticates users against Azure AD (as all Azure users are), my users are administrators, not "users".
I understand previously software that performed administration tasks would be assigned a Management Certificate which is separately-registered in the web-based Azure Management Portal. I understand this fine.
...however I also understand that Management Certificates are almost deprecated and are replaced with Service Principals, which itself makes more sense from a security perspective (as it enables more granular role-based security) - however the downside is that there are a lot of manual steps and hoops to jump through in order to enable the use of Service Principals with administration software - in particular you need to pre-register your application in Azure Portal.
I don't like this because it greatly increases user-friction with the software I'm writing. I want my software to behave like the Visual Studio Cloud Explorer or Azure PowerShell in that you don't need to pre-register anything: 1. just run the program on your desktop; 2. you'll get a prompt to sign-in with your Azure administrator account credentials. 3. my softwware lists the contents of your subscriptions and lets you perform your management tasks.
So far I have actually got something that does this - I perform the following steps:
Use Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext to authenticate against https://login.microsoftonline.com/common (using AcquireTokenAsync which presents the webview to login). I use clientId: "1950a258-227b-4e31-a9cf-717495945fc2" which is the Azure PowerShell clientId.
Use the token from step 1 to enumerate Tenants and Subscriptions in the user's account.
The user is prompted to select a tenant and then a subscription from the list downloaded in step 2.
Send a new authentication request to https://login.microsoft.com/{tenantId} (where {tenantId} is retrieved from step 3), again using the same clientId.
However I don't like impersonating Azure PowerShell - Microsoft could revoke that clientId.
...but how do I register a clientId that can be used to login in step 1 (when there's no tenantId or subscription context, thus no Azure AD which contains Service Principals)?
I don't like this because it greatly increases user-friction with the software I'm writing. I want my software to behave like the Visual Studio Cloud Explorer or Azure PowerShell in that you don't need to pre-register anything: 1. just run the program on your desktop; 2. you'll get a prompt to sign-in with your Azure administrator account credentials. 3. my softwware lists the contents of your subscriptions and lets you perform your management tasks.
Actually, the Visual Studio Cloud Explorer also register the app on the Azure AD and use the Service Management REST to manage the Azure subscription. And you can caputer the request using the Fiddler when you add account to the Cloud Explorer.
...but how do I register a clientId that can be used to login in step 1 (when there's no tenantId or subscription context, thus no Azure AD which contains Service Principals)?
We need to develope a multi-tenant application which enables the users from different tenant to use the application. After that we can use the Common endpoint instead of the specific tenant id you register the app. Then users login-in with their account which associate with Azure subscription and get the access token for the Service Management REST. At last the applicaiton can manage the Azure resource with the access token. For example, we can use the REST below to list the Azure Sbuscriptions:
Get:https://management.core.windows.net/subscriptions
Authorization: Bearer {token}
x-ms-version: 2013-08-01
And more detail about the authenticating Service Management requests, you can refer here.