The cloud solution I am working with requires a multi-tenant app registration to be created and used for service-to-service authentication in a SaaS like pattern. The security team expressed concerns that a multi-tenant identity could be assign resources by another tenant (or external entity) without the security team's visibility or control. Assuming the App Registration is only used to configure the solution and its not used in the organization for any other purpose and it's fully protected in Azure Key Vault and not shared with any external entity, is this a legitimate concern? Could there be a way, just because it's a multi-tenant App Registration for it to be discovered and used in a harmful fashion?
As long as you use key vault to store the client secrets properly malicious entities won't have access to the tenant. In fact, an even better mechanism will be to use a certificate in place of a secret.
Related
I am reading this docs that talks about security for a multi tenant application. https://learn.microsoft.com/en-us/azure/architecture/multitenant-identity/.
Let's say that my application is Tailspin. At least 2 companies, Contoso and Fabrikam, decide to use my application.
Those are my questions
Do I need to create a tenant for each customer that decide to start using my service?
Let's say Fabrikam already use a provider other than Azure Active Directory. If Fabrikam wants to use Tailspin, am I going force them to create a tenant?
EDIT
This short video shows how to start using Slack.
The first person to join Slack will enter all the information to create the space.
After that, that person will enter emails, inviting people to join the organization in Slack.
What I have noticed is that, they invitees don't need to belong to an organization [tenant] as they can have gmail, yahoo, etc. Yet, when user is logged in a space, he/she only sees what's in user's space.
I don't know how slack works, but if you have to implement something similar using Azure Active Directory as Identity provider:
Are you going to create a tenant for each customer [you said I shouldn't do that]
Should I create a security group for each customer that join so that its members can be part of that group?
Thanks for helping
You shouldn’t create a separate tenant for these companies. if in case those companies are hosted on different Identity provider. You can federate those Companies identity provider with your application IDP, and you will be accessing the application from their company’s identity itself.
Note: Your application should have capabilities to Federate with other IDP.
You can refer this document how to Microsoft federate with other IDP.
Note: For multi-Tenant, tenants share physical resources (such as VMs or storage), each tenant gets its own logical instance of the app.
For Single Tenant Architecture where each tenant has a dedicated physical instance
I'm getting up to speed with Azure and trying to follow best practices for securing my WPF and Xamarin.Forms apps.
I'm using Azure AD for authentication and Key Vault for my secrets.
What about my Client Id and Tenant settings? These are required to make the initial connection to Azure to log in.
The endpoint URI is also required to make a call to the Key Vault.
Are the Client Id, Tenant, Key Vault endpoint considered secrets or am I over thinking this. I understand without authenticating, no one can access or make use of these.
What about checking these into Source Control? Is this Ok?
Greatly appreciate your thoughts and insights.
Karl
TenantId is hardly a secret. You can get the tenant metadata of any Azure AD tenant using the following Url
https://login.microsoftonline.com/{tenantID/domain}/.well-known/openid-configuration
For example
https://login.microsoftonline.com/microsoft.onmicrosoft.com/.well-known/openid-configuration
ClientId also travels in http Urls and thus is not that hard to find out. That's why the focus should be to effectively protect access to the app using either token validation or user assignment.
Managed identities for Azure resources is available to help avoid checking in any credentials in source control and is specially useful with KeyVault.
I have successfully configured qn Azure AD App Registration, allowing a client_credentials based OAuth 2.0 flow to work. This allows a third party application to access Microsoft Graph API. The app has "Calendar.Read" permission. Meaning the app can pretty much read any of the calendars (including CEO's).
I now have a conversation with security. What is out there in the Microsoft world, that I can use to lock down usage of API access via this Application Permission? Is there ability to do things like:
Restrict IP ranges the App can be accessed from?
Restrict users that can access the App? (However in Client_credentials, there is no user context)
Log traffic / activity happening via the App?
The only thing i can think of now is to say the Redirect URL configuration on the app means, no other application can get an access token using the Client_credentials, even if the application id & passkey get compromised
Any advice on further security controls that can be put in place?
Restricting access: You would need to do this in your application. The Client Credential flow doesn't allow for restricting what users as you point out. However there is nothing stopping you from adding user authentication to your application, possibly using a delegated graph auth flow to determine who they are.
IP Ranges: This is not possible currently.
Logging Traffic: This is not possible on the graph side currently, however you could/should log traffic on your applications side.
Redirect urls will not help you because they are not used int eh client credential flow.
In general application only auth (client credential flow) + a broad authorization scope is very powerful, but must be managed correctly. You don't inadvertently want to build a totally new users/permissions model over the top of the graph :)
There are very few options available currently available to offer these controls at token issuance (in Azure AD) or at API access (in Microsoft Graph). However, you can achieve similar results by carefully managing access to the app's credentials. Here are a couple steps you can take (not exhaustive):
App credentials: keep them secret, keep them safe
Use Key Vault. You can configure many of the restrictions you mention for access to data in Key Vault, including IP ranges and which users access. Key Vault also offers auditing of access to secrets. Don't forget to also be careful about which users have management access to the Key Vault (e.g. other users with access to the same Azure subscription).
Use certificates (public/private key pair), rather than client secrets (passwords), to authenticate the app. People tend to manage certificates much more carefully than they manage shared passwords, and developers are much less likely to hard-code the secret into scripts/code.
Be careful and deliberate about which users can manage the app's credentials
This is often overlooked. A user (or another app) who can access existing credentials, or add a new authorized credential to an app can act as the app and (mis)use all the permissions the app has been granted. This includes:
Users (and apps) in the "Company Administrator", "Application Administrator" and "Cloud Application Administrator" directory roles.
Users who are set as owners of the app registration (Application object) and enterprise app (ServicePrincipal object) for the app.
Users (or systems) who have access to the server or service the application resides on (which will have, or have access to, the credentials).
For all of these cases, ensure this is the smallest possible number of users, and they actually have a legitimate need. For users who do need access, wherever possible enforce just-in-time, time-limited access (not persistent access), such as with Azure AD Privileged Identity Management, for time-bound, just-in-time access for Azure AD directory roles and Azure resources.
I'd like to use IdentityServer4 for authentication in my ASP.NET Core MVC web application, but the user registration process seems awkward. Most web sites that require user registration don't redirect you do a separate site (e.g. Facebook, Twitter, etc.) to sign up if you're using local user accounts.
One solution is to host IdentityServer4 in the same process as my MVC client, but that is discouraged.
Are there any good real world examples of local user registration with IdentityServer4?
IdentityServer is for authenticating existing users, not really creating new users.
In our use-case, we have 3 projects playing a part:
The identity server
A protected API
An identity provider (aspnet core identity) project
Users are created by a call to the API, which creates the appropriate structures in the identity provider.
Our identity server makes calls to the identity provider when validating requests for tokens.
Our API uses identity server to protect the resources, and our identity provider to retrieve information we may need about that user that aren't contained as claims (permissions, for example).
In this way our identity provider can be shared across projects (one user base with different roles), and the Identity Server is purely for authenticating users. All user management functions belong elsewhere.
EDIT:
#peyman We're not doing anything particular ground-breaking: just using the aspnet core identity framework (http://odetocode.com/blogs/scott/archive/2013/11/25/asp-net-core-identity.aspx).
The IUserStore and UserManager are the main drivers of this. When a user is created they are assigned a role, which for us is based on which application requested the creation of that user. Our implementation of IUserStore is what will ultimately be called by IdentityServer when verifying identity, and the data provided is used by IdentityServer to build up claims. Our resource API is relatively simply protected using Policies for claim based authorisation (https://learn.microsoft.com/en-us/aspnet/core/security/authorization/claims)
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.