I am looking for best practices for registering App in Azure AD for different environments like DEV, TEST, UAT and PROD
I have an PROD subscription and non PROD subscription both of which are tied to our Corporate Azure AD
Now to have an application in different environments and have Corporate users have access to it during Development as well has end users, what are the best practices?
I am thinking of creating of Directories for different envs and then have the app registration in each of these directory and add corporate users as guest users to this. So app registration is in this Directory while the workloads are in the Corporate Directory
Is it a good practice?
I have confirmed with Azure support engineer that we can not restrict users to access the apps, the apps will be visible to all users. But only the owners and admin can edit the apps.
If the user is not the owner of the app(also not the admin), he/she will be unable to edit the app.
Related
My company uses a single tenant azure active directory. How do i keep app registrations organized such that i classify app registrations per business unit or prod and non-prod etc.?
In my experience, AAD doesn't provide such a feature that allows you to classify app registrations.
You can manually set their names to the same format to distinguish them. Or add the same type of apps to the same security group.
If you want to restrict different users from using different apps, you need to Configure an application to require user assignment and Assign or unassign users, and groups, for an app using the Azure portal.
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.
Registered an app in v2 portal apps.dev.microsoft.com, it says 'This application will be registered in the Azure Active Directory instance used to manage your account', now 3 hours passed, when I go to 'enterprise applications' tab in azure portal-active directory, i still didnt see it there, why? how long will it take?
The enterprise applications blade represents Service Principals, rather than applications. Here's an excellent doc that walks through details of the difference between an application & service principal.
A Service Principal can be thought of as an instantiation of your application into the tenant. In the example of multi-tenancy, you as an app developer may register an application, then have multiple tenants sign in & consent to the app. At that point, each of those tenants will get a Service Principal provisioned into their tenant and it will show up in the Enterprise Apps section.
To prompt a Service Principal to be provisioned in the same tenant as the app registration, you simply need to complete a sign in request and consent to the application. It should show up after that.
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.
I have build a web application based on Azure. I have a web api service as backend and angularjs as frontend hostet in Azure.
I want to create a login page with individual user accounts. After some reading I found different user authentification strategies. Some use SQL database for managing user accounts. Some use Azure Active Directory. When I have to use Azure AD and when SQL databese?
my opinion is to compare what the benefits you will get
Azure AD:
https://azure.microsoft.com/en-us/documentation/articles/active-directory-whatis/
For IT Admins, Azure AD provides an affordable, easy to use solution
to give employees and business partners single sign-on (SSO) access to
thousands of cloud SaaS Applications like Office365, Salesforce.com,
DropBox, and Concur.
For application developers, Azure AD lets you focus on building your
application by making it fast and simple to integrate with a world
class identity management solution used by millions of organizations
around the world.
Azure AD also includes a full suite of identity management
capabilities including multi-factor authentication, device
registration, self-service password management, self-service group
management, privileged account management, role based access control,
application usage monitoring, rich auditing and security monitoring
and alerting. These capabilities can help secure cloud based
applications, streamline IT processes, cut costs and help assure
corporate compliance goals are met.
Do it yourself with your database,you will have to do all above yourself e.g SSO with Office365
So you have to ask yourself what your app does? and choose the approach fits your needs
The application managing its own user accounts in SQL is called forms based authentication. It's how most internet applications used to work, but it came with a lot of downsides.
Users had to remember a password for each site, but often reused passwords across multiple sites. If one site got hacked and lots the password database, user's accounts on other sites could become compromised.
To prevent this, sites had to make sure that they stored passwords correctly (salted and hashed with a slow algorithm) and apply other kinds of operational security to protected the database.
Then token based authentication came along which let applications delegate the authentication piece to an external 3rd party. This allows users to log in to multiple apps with the same username and password.
Most of these 3rd party login providers like Google, Microsoft, Facebook etc. have specialist working on these services and are therefore more likely to be secure than anything you create yourself.
So, unless you have really good reasons not to, I would recommend using a 3rd party login provider like Azure AD and possibly others.