Here is a scenario. I have a SaaS product that needs to make api calls to customer's Azure cloud account. I understand a service principal can be created on the customer's AZ account, and if I have the credentials(app id, password, etc), I can make calls using that user/principal based on the permissions to that principal. One way is that customer creates it for my product, then comes to my product portal(web ui) and punches in this information which my SaaS product can then store securely in vault and use it.
Is there a better way to achieve the creation of the principal? For example via application manifest or something and then also be able to get a Event grid notification or something with the app/principal's creds to a webhook url endpoint?
Basically, I want this to be as automated as possible but cannot think of a way if it is even possible.
Normally if you are writing a multi-tenant application, you will set up your app registration as multi-tenant, and you will call the "common" endpoint for all users to log in.
when the admin from a different tenant logs into your application, if set up properly, a consent window will appear and when they consent, the Service principal will automatically be created in their tenant.
please see here: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant#understand-user-and-admin-consent
Related
I have an app that uses graph API to get some data from Office365 from multiple customers.
At the moment, every time I have a new customer I need to log in as admin on to their azure portal, create the app, add permissions and consent for the permissions.
Is there any way I can generate a link that I send to the customer, they just click it, consent and the application ID's are returned so they can provide us?
Regards
Instead of creating a separate app registration in each customer's tenant, you could have a single app registration, controlled by you in your tenant. Then, each of your customers would grant consent to your app in their tenants, for example by going to an admin consent URL that you provide to them.
Lets say I set up and create a new Azure Account and Subscription. Azure automatically creates me an Azure AD called "somedomain.onmicrosoft.com".
Later I deploy REST API and Angular SPA app to Azure. Since I'm using Azure AD for authentication and authorization on both of the applications I register them on my Azure AD, under the domain "somedomain.onmicrosoft.com".
Everything works fine, however after some time I realize that I want to allow access to my services/apps to other organizations. After doing some research I realize that what I want to achieve is multi-tenancy.
In order to register a new tenant I do the following:
Go to Azure portal.
On the left blade menu click on "Create a resource" and search for "Azure Active Directory".
Create a new directory called "tenant-1.onmicrosoft.com".
Next, I update my registered apps (on "somedomain.onmicrosoft.com") according to this documentation - enabling multi tenancy and common endpoint.
After all of this, both users from AD "somedomain.onmicrosoft.com" and "tenant-1.onmicrosoft.com" should be able to authenticate and access my services.
Question
Is this the correct way of achieving and implementing multi tenancy?
You don't need to create a new Azure AD tenant (xyz.onmicrosoft.com). Just register the application in the existing tenant or mark the existing application as multi-tenant. Then, existing other AAD tenants will be able to signup to use your app without doing further registrations. You will need to modify your app code to accept tokens from other tenants, e.g. enter link description here This link points to a regular .NET web app, not SPA. You will need to translate it to your SPA environment.
I'm not sure of your high level use case but one thing to note about the AAD multi-tenant approach. You are assuming that person signing in has an Azure AD tenant, for example through Office365.
If they don't have an Azure AD then they won't be able to sign in.
You 'could' create an AAD for each new tenant and create a user account in there.
They would have the bob#mydomain.onmicrosoft.com address and could add their own domain later.
That way they can then take advantage of all the enterprise features of AzureAD.
It might be a use case, but I think you would need an AAD per tenant and I'm not sure of the limits or if this is best practice.
You can also look at B2C if you want social logins/other OpenIDConnect.
I am developing an application that integrates with other business' Azure accounts. My application needs read access to the Azure Monitor service in our customers' Azure accounts. What is the best way to authenticate?
After reading, here's the current solution I came up with:
Have a customer create an App registration in their account. After creating the app registration, they assign the Monitoring Reader role to the application they created. The customer then will navigate back to the App registration and create a Client Secret. The customer then provides my service the client ID, tenant ID, and a Client Secret. My service will use those to authenticate with Azure and call Azure Monitor.
Is this the recommended way to authenticate with Azure as a 3rd party?
I am not sure if it the best way, but indeed it is a feasible way. This way named client credentials flow, you need to use this way to request the access token, then use the token to call azure rest api, e.g. Alert Rules - Get.
When you request the token, you need to specify the resource with https://management.azure.com/, also, you should note v1.0 endpoint is different with v2.0, v2.0 uses scope not resource, for difference details see this link. So you should choose the correct one depends on which version app your customer created.
Besides, correct some of your understanding of azure ad tenant and azure subscription. They are not called Azure account, the Azure monitor is a service in the subscription, the subscription locates in the tenant. The AD app(app registration) also locates in the tenant. You can understand the AD app is higher than the subscription, it is not in the subscription.
iam currently researching how to implement Single Sign On for our WebService.
This is what i came up with so far.
If a customer of our WebService has an AzureActiveDirectory they can log on with their active directory user account to our WebService if we provide the nessecary interfaces for SAML, Oauth2, OpenID or whatever authorization protocoll we chose and azure supports.
The customers could also have their local network Active Directory synced to their Azure AD and use their Domain accounts to log on to our WebApplication.
Customers need to use the myapps.microsoft.com portal to "wrap" authentication.
Once everything is set up correctly the Identity Provider (AzureAD) would provide use with (e.g) an authenticated User Identity.
Here is were my problem begins.
Of course i need to somehow map the identity provided by the AzureAD to a certain Account for our WebService - we cannot simply use the provided identity.
As far as i understand it, you can grant AzureAD the right to create an Account on the target WebService in the name of the user which is currently signing in.
(Its called : enabling automatic user provisioning in the azure management portal).
However, when testing this with the Box, Canvas or Google apps i failed. Either i got an error or in the case of google apps i was just promted to login with my azure AD test account and then asked for a password and username of my google account (i set up SSO as an azure AD trust relation- so this should not happen)
Can someone provide some insights on how to accomplish the following?
Once the user is authenticated by SSO I want to create an account for our WebSerivce and then save the credentials for that user only in the Active directory of that particular user.
So if the user logs in the second time we can check wether there is an account already existing and log in the user with this account.
(I was told by microsoft that this might be possible with Azure Rights Management, but i cannot really find good documentation on that)
Storing the relationship: "Microsoft AD Identity <-> our WebServiceAccount Credentials" on our side is not desired because we cannot securly encrypt the data in a way that we DONT know whats in there. (or there is , and i dont know of it yet)
"Bonus Question":
Can i support SSO for a desktop application too? (Do i need a provide proxy web application or can the desktop app do this directly?)
Please see my answer to a similar question here: asp.net azure active directory user profile data
However - I'm trying to understand if you need something different. Are you expecting your customers to already have a directory and Azure AD accounts (maybe through having Office 365 subscriptions), and use those to sign in to your web app, or does your app scenario require creation/provisioning of user accounts into your customer's Azure AD directory? Provisioning can be done through graph API (as per your link), as long as the admin of your customer grants consent to allow your app to write to their directory. You can find some samples on github, and I recommend you look through https://msdn.microsoft.com/en-us/library/azure/dn499820.aspx and https://msdn.microsoft.com/en-us/library/azure/dn646737.aspx for code samples.
HTHs,
I think, without testing it. That using the Graph API enables me to save custom data for any Directory User effectively enabling my desired functionality.
This is the documentation i found very usefull.
https://msdn.microsoft.com/en-us/library/hh974476.aspx
We want to create a MVC web application using claims-based authentication, expecting roles as one of the claims. We want to Federate authentication providers using the Azure Access Control Service to manage this federation. One of the authentication providers is our Azure AD.
The problem is that Azure AD doesn't seem to be able to generate role (or even group) claims. What is the appropriate method to manage group or role access in Azure AD and have role claims served by Azure Access Control Service.
Thanks.
Edit:
A previous comment asked for details: We want to provide access to our cloud application to 3rd parties using their active directory (to simplify user management for them). Our application has a few levels of access to information that the 3rd parties can configure. We were hoping they could do this in their AD (based on our instructions). Groups seemed like the obvious choice, but if there is another way that works, as long as we can provide instructions, it'll work.
We want our application to get claims for a user's level of access. If we had only one partner that was using Azure AD, we could use the graph API against that endpoint, but with multiple partners changing over time, we wanted to federate them so our application only needs to trust the federation server. We were assuming that we needed Azure ACS to manage the federation.
AAD does support roles / groups and you can administer them from the Azure Portal.
Howeve, these are not passed in the "canned" set of claims.
You need to use the Graph API and then convert them e.g. Windows Azure Active Directory: Converting group memberships to role claims.
Update:
ACS requires something to federate with. You can't hook a customer AD up to ACS - you need something like ADFS on top of their AD.
I assume your cloud app. runs in Azure?
Then make your app. multi-tenanted. If your customers have their own Azure tenant, it will work. You just need to add the Graph API code to your app. ACS is not required.
Your customers then run DirSync. This keeps their Azure tenant in sync. with their AD changes.
So two options:
Customer does not have Azure tenant. They install ADFS and federate with AAD.
Customer's who do have Azure tenant use DirSync.
Good news: we have recently turned on the Application Roles and Groups Claim features in Azure AD.
Get a quick overview here: http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/authorization-cloud-applications-using-ad-groups/
Hope that helps.
Groups aren't the best choice because they are unique within each directory. Unless you get your customers to define a set of groups that have well-known names and match against the strings, that is (the object IDs of a group is different per directory even if they have the same name). I'm actually from the Azure AD team and we are seriously considering releasing a feature to allow you to define roles in your app that your customers can assign their users to. Please stay tuned on this. In the meantime, unfortunately groups are the only way to go. You would have to call "GetMemberGroups" using the Graph to retrieve the groups that the user is assigned to.
What are your timelines for releasing this application? You can contact me directly to see if we can work with your scenario.