For Azure Active Directory, I created an app registration for my web app to enable SSO/OAuth 2.0 login for end users and to do AD lookups using the AD graph apis.
That requires me to use a client id and client secret and I have the requirement to not store the secret on the system when running inside of Azure VMs.
Is there a way using managed identities to either fetch the application secret or generate a token that can be used with the login.microsoftonline.com OAuth end points?
When you say "Web App" I'm making the assumption you are using something along the lines of an Azure App Service,
If the issue is with storing the client secret locally on the machine, the more secure way is to store the secrets in Azure KeyVault.
This stackoverflow post goes over why KeyVault is secure : Why is Azure Key Vault secure?
And the official docs provide a good overview/quickstart on getting started with Azure Keyvault. https://learn.microsoft.com/en-us/azure/key-vault/quick-create-portal
And this is a tutorial on using KeyVault with an Azure Web App: https://learn.microsoft.com/en-us/azure/key-vault/tutorial-net-create-vault-azure-web-app
Essentially secrets stay in Azure so that they're never exposed in code or on the development machine. And by using MSI, you won't need to keep track of credentials to access the keyvault. Keeping all important information in Azure.
Related
For my current ASP.NET Core MVC application I authenticate directly with a web app registered in Azure AD Portal. This provides me with an access token so on the backend of my web application I can use MS Graph with my users specific account (ie add files to their onedrive , email, etc). However, my organization also has Okta which a lot of applications authenticate against. So I was trying to determine to authenticate through Okta (which has a much cleaner sign in process IMO) as well as authenticate against Azure AD and get an access token. Through my research I found something in my web application registration in Azure AD called Workload Identity Federation. This led me to this useful video
https://www.youtube.com/watch?v=wZ0gCJYMUKI
and also microsofts info site:
https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation
This seems to answer what I want which is to use Okta but allow me to still use MS Graph for my users since it will authenticate against Azure AD (correct me if I am wrong and this is for something else). My issue is none of these resources really go into depth regarding how the access token is passed to my application so I can use MS Graph. My research this is called client credential flow since my application only has delegated permissions so it requires the users to log in and it basically allows my web app to act on their behalf when using MS Graph. So I am trying to understand and fill this void of information regarding how client credential flow fits into Workload Identity Federation and is this the solution to my problem.
I have implemented user authentication with cognito and Azure AD (SAML) for static app running on EC2 instance in apache server.
I want to authorize user from AD group to access specific url from static web app.
For example : for users in admin group can only access pages with path /admin/*
For authentication I used ELB authenticate action which is working fine
Now I want to provide group based access to pages for static app running in apache running in ec2 instance.
Is there any with which I can authorize users without making any changes on application side. ?
Thanks in advance !
• I would suggest you create user pools supported by Amazon Cognito and authenticate them using corporate identities of Microsoft Azure AD. Thus, for this purpose, you will have to create user pools first in Amazon Cognito which are in fact nothing but groups containing user identities. For this purpose, kindly refer to the link below for more details on its configuration: -
https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-cognito-user-pools.html
• Once you are done with the above, you can configure authentication for users using an application load balancer or elastic load balancing as you have done in case of users from Azure AD using Amazon Cognito. For configuring the user pool authentication in Amazon cognito, you will have to prepare to use an OIDC-compliant IdP, prepare to use for Amazon CloudFront and other things like user claims encoding and signature verification like that for user authentication. For this purpose, to configure the same, kindly refer to the below AWS documentation link given: -
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html
I'm working on Azure Cosmos DB Feed changer Function. My requirement is in the feed changer function I need to access Web API using AAD authentication.
How should I configure the connection between the Azure Function and Web API using AAD so that the azure function can send the change feed to Web API?
How can I call the Web API in the function code?
Thank You,
Dheeraj
Based on your requirements, I suggest you using MSI(Managed Service Identity) in your azure function app.
You could create an identity here.
Then search the identity in AAD Enterprise Application list,you could find the permissions of it.
Then please refer to this document to obtain the access token and call your web api which is using AAD authentication with that token.
In addition, you could store the secret in Azure Key Vault and get the access token from AKV to call your web api. It support you to manage multiply permissions.
More details ,please refer to this link:https://blogs.msdn.microsoft.com/benjaminperkins/2018/06/13/using-managed-service-identity-msi-with-and-azure-app-service-or-an-azure-function/
We are looking to publish an API in an Azure B2C model where customers will use our app to access API's published using Docker Swarm based Azure Container Services. Our assumption here is that this model will require Azure B2C AD as opposed to Azure AD.
All API calls will have an OAuth token issued from B2C AD.
We want to know what is the best approach to validate the token centrally before it reaches the microservices on Azure Container Service. We were using API Gateway to route the API calls to the correct microservice while also using the WAF capability in the API Gateway. However, we realize that the API Gateway does not provide a way to verify the OAuth token before it forwards the request to the microservices.
Also please note, as per the suggestions in Microsoft Documentation we have two tenants with one tenant running all services such as database and microservice and the second tenant hosting the Azure B2C AD.
Can you please suggest the best option to implement the OAuth Verification without having to implement this in each microservice.
One thing you could do is put Azure API Management Service between your clients and services, there you'd have an option to use validate-jwt policy to inspect tokens and authorize calls.
The following is a quick overview of the steps:
Register an application (backend-app) in Azure AD to represent the API.
Register another application (client-app) in Azure AD to represent a client application that needs to call the API.
In Azure AD, grant permissions to allow the client-app to call the backend-app.
Configure the Developer Console to call the API using OAuth 2.0 user authorization.
Add the validate-jwt policy to validate the OAuth token for every incoming request.
Please refer to the following document for steps in detail.
I'm currently trying to implement a multi-tenant Azure AD application that will use Microsoft Graph API's to monitor and analyze Office 365 "metadata" for members of the tenant domain. For example, the application might monitor One Drive user space over time. The architecture of the application will include an AngularJS SPA client along with a web application back-end. The idea is that the web application allows for both local registration (e.g. traditional sign up using an email address and password) in addition to Azure AD authentication. In the case of local registration, the user might be able to associate an Azure AD tenancy with the local account in the future, for example.
I'm struggling to understand how various authentication mechanisms should work. For example, I think that there should be two levels of authentication in the case of Azure AD: one authentication for the users of the client SPA, and another authentication used by the back-end for making continuous calls to the Microsoft API's, requesting refresh tokens, etc.
How might this architecture be implemented using the various Azure AD authentication scenarios Microsoft has already provided examples for?
If my initial inclination that I will have two applications registered with Azure AD (for example, the SPA registered as a native application, say, and the web application registered by itself), how will users allow access to both of them, and what would this workflow look like? In addition, what would the flow of user requests look like? The SPA would make a request to the back-end using its Azure AD token, but what will the back-end do to receive its authentication token and make calls to the Microsoft API's?
How might I best incorporate Azure AD authentication along with local registration into my application?
Generally speaking, you can associate your each user to his entity in Azure AD tenant in your backend server / database. As every user in Azure AD has several unique properties in the entity object. You can use the user's email or objectId as mentioned at Claims in Azure AD Security Tokens as the external column in your user table.
When your user authenticate your site via ADAL.JS, you can grab the access token in your backend server via the Authentication header. You can use the access token to request for the resources protected by Azure AD. And the access token is a JWT token, which you can decode directly to get the user basic claims as we mentioned before. You can retrieve the claim which you stored in your user table and match the special user registered in your server for requesting the resource protected by your self.