Is it possible for us to create an app on our azure and can be shared with others to use? - azure-active-directory

We are trying to integrate Onedrive with a WebApplication. Intent is to get the content from Onedrive into WebApplication on any event.
We are able to integrate and using the "APP Register" in Azure Active Directory and configuring with Graph API for delegation and then using the client id, client secret and tenant id from WebApplication.
Here, I would like to understand, Is it possible for us to create an app on our azure subscription and have a way for others (other companies/clients) to install it on their azure system using OAuth process in order to avoid any creation of app and sharing other details.
Please let me know if the query is clear or not. If not, I will explain more in detail.
Thanks
Sakti

Yes, you can share your application with other organizations, you only need to change your application to a multi-tenant application, because changing the application to multi-tenant application allows any tenant to log in.
Next, you need to request the consent of the administrators of other organization tenants. You can send the login request URL: https://login.microsoftonline.com/{Other company tenant_id}/adminconsent?client_id={client-id}. After the administrator consent, it will be added to other organization tenants as an enterprise application in.
However, you need to note that after sharing your application, the permissions granted to it in the original tenant will not exist. If you need the application to access the resources of other company tenants, you must request the other company's IT to grant similar access permissions.

Related

Why does Microsoft Dynamics 365 ask for delegated admin in Azure app registration

I'm following a guide online to generate an access token to access Microsoft Dynamics 365 Customer Engagement: https://eax360.com/dynamics-365-online-connect-using-postman/.
All of it works fine, however I am wondering why delegated Admin permissions need to be supplied in Azure Active directory during app registration. I have seen a lot of guides explain that permissions must be delegated but the above site documents the process well. As a general rule, I thought that starting with the lowest security permissions was the norm. I am new to Azure AD so thoughts are very much welcome.
If your app will be a client which allows the authenticated user to perform operations, you must configure the application to have the Access Dynamics 365 as organization users delegated permission.
Application permission means that you want your app to access Common Data Service without a user.
So whether to use delegated permission in Azure app registration depends on your needs. It is not mandatory.
But we can see that the Application permissions in Azure app registration is gray out. This is because Microsoft provides a different way to implement it.
We need to create a Common Data Service application user an then bound it to the registered app. After that, we could connect using the application secret. See the details here: Connect as an app.

Multi-tenant app in Azure AD (Active Directory) fails with AADSTS50020

I created a "Web app / API" app in our organization's "xxx.onmicrosoft.com" Azure Active Directory. The app's "Multi-tenanted" property has been set to "Yes".
We configured OpenID Connect (we use https://github.com/mitreid-connect/) to use the following URLs:
https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token
Please note that we used "common" in the URLs and we didn't use "xxx.onmicrosoft.com" because we want people from outside "xxx.onmicrosoft.com" to be able to authenticate and access our app.
With those settings, the people from xxx.onmicrosoft.com can properly authenticate and access the app.
However, when I use my personal live.com account (with username xxx#gmail.com) to access the app, I get AADSTS50020 error. I am able to properly authenticate with my xxx#gmail.com account, but I do not get redirected to the Reply URL. I'm stuck on Microsoft's Web page with the following error msg:
AADSTS50020: User account 'xxx#gmail.com' from identity provider
'live.com' does not exist in tenant 'xxx.onmicrosoft.com' and cannot
access the application '391e7103-ZZZZ-zz87-xxxx-7xxxxxd5xxxx' in that
tenant. The account needs to be added as an external user in the
tenant first. Sign out and sign in again with a different Azure Active
Directory user account.
What configuration do I need to change if I want people from any identity provider to be able to access my app ?
Like it has been stated here, I expected that people from anywhere could access my app without requiring more configuration on my side.
I'm asking this question because I'm in the process of getting certified for AppSource and this currently blocks me from being able to do so.
AppSource only requires work accounts to sign-in. You are using an #gmail account - which is a personal account - and because you are using the Azure Active Directory v1 endpoint in addition to common (https://login.microsoftonline.com/common), it can't accept personal accounts to sign-in directly - only work accounts.
You have three options:
If sign-in personal accounts is not a requirement for your application, then you can continue using the v1 endpoint and use a work account to sign-in/test your application. This will make you ready for AppSource certification.
If you need/ want to allow personal accounts in your application in addition to work accounts, then you can consider using the v2 endpoint (https://login.microsoftonline.com/common/v2.0) for Azure Active Directory. The v2 endpoint allow both personal accounts and work accounts to sign-in with no effort.A note is the v2 endpoint has some limitations: if you can live with these limitations (for example, your application only needs to sign-in users and eventually make queries against Graph API), then in general it should be fine to use, but if you need extra features like protecting your own Web API with scopes, then this feature is not released at this point (as November 2017). Please read this document for an updated list of limitations of the v2 endpoint.
A third (but less recommended option for AppSource) is to keep using the v1 endpoint and make your application to be single tenant - which is to change the endpoint from https://login.microsoftonline.com/common to https://login.microsoftonline.com/{yourtenantid}, and then use B2B invitations API to invite every external users (including work and personal accounts) to be part of your Azure AD tenant/organization. More information about B2B here as well.
The option '3' above have some consequences for management as well for AppSource: by using this option, you are required to have one Azure Active Directory tenant (if you don't have a tenant already, you can get one using these instructions), and the users being invited will be guests accounts of this tenant - this mean that you need to invite every external user to your application/ tenant. A multi-tenant application allows any user from any organization to sign-in to your application with less management on your side. In general for SaaS applications, multi-tenant configuration is recommended.
For AppSource, also the option '3' leads to a less-immersive user experience (Partner led trial), where the end user won't be able to access your application's demo right away - mainly because that they have to wait for the invitation's email and accept it (user has to accept being guest of your tenant) so that they can access your application.
For more information about AppSource requirements and trial options - please see this article.

Multi tenant Daemon office 365 app registration on consumer AAD by granting admin consent, Does it also require separate registration on consumer?

I am developing a multi-tenant Office 365 daemon that requires access to user calendars.
I have successfully registered in the company tenant (Tenant1) that has deployed this app using certificates and I am able to get access tokens.
Now I created a separate AAD tenant (Tenant 2) and logged in to daemon app using administrator account of Tenant 2, it prompted the Admin Consent screen and I provided consent. There was no errors returned.
When I tried to get an app token however, I am able to get a token but with blank permissions. If I call the Office 365 API using this token, I get a 401.
I was of the view that service principal objects should be created. Also I am unable to see this app in Tenant 2 app registrations.
Do all my consumers have to register this app manually in their AD tenant and modify application manifest file to add certificate details?
I am not sure about the benefit of multi tenancy if that's the case.
I found the follow in the Azure Active Directory documentation:
The following diagram illustrates the relationship between an application's application object and corresponding service principal objects, in the context of a sample multi-tenant application called HR app. There are three Azure AD tenants in this scenario:
Adatum - the tenant used by the company that developed the HR app
Contoso - the tenant used by the Contoso organization, which is a consumer of the HR app
Fabrikam - the tenant used by the Fabrikam organization, which also consumes the HR app
You do not need to have each tenant register your application. In fact, you shouldn't since having dozens (or hundreds) of unique App IDs floating around would only create headaches for you.
Each tenant does however need to execute the Admin Consent workflow. This will authorize the App ID you've registered on your end to access the scopes you've requested.
Generally, I recommend using the v2 Endpoint and the apps.dev.microsoft.com portal for registering your app. While you can also register your app in your own Active Directory, the portal makes it a lot easier to manage.
The general process is:
Register you application in the Registration Portal
Populate the "Application Permissions" in the Microsoft Graph Permissions section.
Launch the Admin Consent workload using https://login.microsoftonline.com/common/adminconsent?client_id=[APPLICATION ID]&redirect_uri=[REDIRECT URI]
Get a beer
A couple of tips:
The Registration Portal only supports MSA (i.e. personal) accounts at the moment. I'd suggest creating a new Outlook.com account for this purpose so you can easily share the credentials with folks who need them internally.
If you create a shared Outlook.com account, you should also set up forwarding rules for all of the interested parties internally. This is in case something should every go wrong or change down the road and you need to recover the account.
I wrote a v2 Endpoint and Admin Consent primer that you might find helpful. They assume you're using the Authorization Code flow but the concepts remain the same for Client Credentials.

How can I transfer or share apps, created in Microsoft app registration portal. I'm using Azure Active Directory and v2.0 endpoint

I'm using passport-azure-ad library to authenticate people into our app. We are using v2.0 endpoint. I have created multiple applications in Microsoft app registration portal. And have a lot of redirect url's because we have a lot of different environment apps. It was registered under my Microsoft employee account. Now I need to transfer ownership to another developer. How can I do it? Do I need to recreate all this apps in another account? I assume that this will create a new app id's and thus will ask for permissions for all users again. Is there a way to transfer ownership and not recreate all apps again?
Assuming you created your applications using your Azure Active Directory account (like your Microsoft Employee Account) you will have access to an "Owners" field where you can add new owners to the application which are in the same tenant as you.
If you are trying to transfer an application to a user from a different Tenant or using an MSA account, that is not currently supported, but something that is being considered for the future.
If you need to create a new application id, you will not be able to transfer the consent that you had from the first app over to this second one. That is just not really possible nor something we would look to support due to the security implications.

Querying a tenants Azure AD from a multi-tenant Application

We have a multi-tenant Saas application providing sign in using our username/pwd authentication system and using Azure AD (OAuth 2.0 flows). When a user signs in using Azure AD, we can get the user's profile using https://graph.windows.net/{tenantid}/me. We want however to get more information using the memberOf or getMemberGroups operations to retrieve the user's groups in the tenants directory, to map specific groups from the tenant to an organizational structure in our application. However these operations always fail with a Forbidden statuscode. Are we missing required permissions or is it just not possible to query for the groups and roles of another tenant.
Thanks in advance
This is totally possible, but today requires that you request the "Read Directory" permission. This permission does require and admin of the tenant to consent. We are looking at adding some additional fine grained permissions for Graph API that will allow users to consent (to get group membership information).
Another option for you is to configure your application to request group membership claims (which should appear in any user or JWT token). You can do this by going to the azure management portal and getting to your app's config page. From there download the application manifest file and update the groupMembershipClaims property. You can see most of the properties in the application manifest described here: https://msdn.microsoft.com/en-us/library/azure/dn151677.aspx. Once updated, you can upload this app manifest file, and this will configure your application accordingly. Once done, AAD will issue group membership claims in the token. Dushyant has written a nice blog about authorizing access to a web app, using group membership claims or app roles. You can find it via Alex Simons blog post here: http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx
HTHs

Resources