I am looking at the documentation of service principals , and come across these phrases
It's important to remove old service principals for the same reason that you delete old user accounts: attackers might gain access to their keys. It's best not to have credentials that aren't actively used.
You might wonder why you need to create this whole new type of object
just to authenticate a pipeline, when you have user accounts that work
perfectly well. User accounts aren't designed for unattended use. The
authentication process for a user account often checks that a human is
the entity that's trying to sign in. Increasingly, organizations use
additional security checks during authentication. These checks include
MFA, CAPTCHA checks, and inspecting the device and network that the
user is using so that they can verify the legitimacy of a request to
sign in.
It's also a bad idea to save your username and password anywhere, because someone else might get access to them and then use them to impersonate you.
In "both" theories, it seems it is not a good idea to keep / share service principals ( aka passwords ). Is it only reason that passwords are not designed for unattended use we should use service principals which offers secure measures on a case to case basis ?
As per the Official Microsoft Documentation,
When you have applications, hosted services, or automated tools that needs to access or modify resources, you can create an identity for the app. This identity is known as a service principal. Access to resources is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level.
The user accounts and passwords are not designed for unattended use. Service princpals can be used to give the access to the resources based on the Role-based access control(RBAC).
What service principal object exactly do is it sets the information about a particular app and its resources access.
If you want to avoid the need to manage the credentials you can use Managed Identity.
Reference:
https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals#service-principal-object
Related
I am working on a search service.
My Spring Boot search service stands between my internal userbase and my Amazon Elastic Search cluster.
I want to enable fine-grained access control, however I can't rely on AWS IAM as we have an in-house service to manage Authentication and authorization.
Is there any way I can enable fine-grained access control for search without mapping all the users from my system to either IAM, Cognito or Kibana internal database?
The way we addressed this challenge is:
Create roles and assign permissions to roles. This is not as
cumbersome as adding user by user and it can be easily achieved as
in general there should be just a bunch of roles to be used and
re-used. Relevant documentation can be found here.
For each role create one user and map it to that role. Here you can find how to do it.
Create service users to be used by applications
Use service users to impersonate the user (as per step 2) associated to the role we need. User impersonation docs can be found here.
Let the calling application to authenticate with the in-house service and then impersonate the relevant role.
Even if not particularly elegant, this solution works and it's secure.
I don't understand how the 'Scopes' in Azure B2C are supposed to be used. They are associated with an API, but not a user. I'm sure I'm missing something, but I see no practical use for something associated with an API. I've used and implemented Claims-based authentication based on a user's role in the database.
For example: ordinary users of an API should not have the authority to delete an object, but administrators should have the authority. Does someone have a practical example of how these B2C 'Scopes' can be used to limit a users access to the API?
They are associated with an API, but not a user.
That is correct. I like to think of the association to the API as defining the 'surface area' of the API. For example, this API defines 2 scopes
read
write
Now, you could define two applications. One application that only has read permissions and one that has read and write permissions.
For the common use case of one Web App and one Web API it adds no value. I've been using a scope of no-op for such cases.
I've used and implemented Claims-based authentication based on a user's role in the database
You can use custom attributes to assign "role(s)" to the user. You can set them via the Azure AD Graph API to keep the setting of them secure. You can also set them during sign-up (this is much more involved though).
When you request an access token for that user, the custom attirbute(s) you defined and set will be readable in the API to check permission(s).
Comment Feedback
If I promote or demote a user, I need to change the endpoints (policies) they access at the client.
No need to change the policies. You would update the custom attribute for that user via the Azure AD Graph API.
My problem is that I'm mystified at the an authentication system that authorizes endpoints ("scopes") instead of users
Yeah, me too! I think it might have to do w/ the purpose of the product. B2C is about self-service sign-up, password reset and federating w/ other IDPs (like FB, Google, etc). Maybe Azure AD is a better solution when you want to control permissions on a user. Not sure, still learning!
I still don't see the practicality of splitting your API into several different parts based on the security. An API should be a collection of functionally related services
You don't split your API. You can split your app(s) that utilize the API. See above.
Documentation Reference: Requesting access tokens, GitHub Issue to improve the documentation.
Roles and scopes provide the two halves for this user access control.
Roles -- such as Administrator, Member, and Guest -- determine whether an authenticated user is permitted to delete objects.
Scopes -- such as read, write, and delete -- determine whether an authorized application can delete objects on behalf of an authorizing/consenting user if this user, through their role assignment/s, is permitted to do so.
Azure AD B2C doesn't have any current support for managing roles and assignments of them to users.
It does, however, have support for managing scopes and assignments of them to applications.
I am the primary developer on a multi-tenant SaaS web application hosted in Microsoft Azure. We use Azure AD for all authentication. Because our application holds personal information, we and our customers want a way to restrict access to specific users. We just need a simple yes/no restriction in place so only assigned users may access the application. We've considered Application Roles, but it seems like a lot of overhead when the only needed option is "authorized".
While researching this, I came across the following "User assignment required" property in Azure AD.
User assignment required property in Azure Portal
After some testing, I found that it functioned exactly as we need it to. The customer has full control over which users may access the application, and neither party has to configure Application Roles. The only downside is that this property is configured on the customer's end. Is there a way for me, as the developer, to require this setting? Or perhaps a way to enable this setting by default?
Clarification: The end-goal is minimal configuration done by the customer. If "User assignment required" can be enabled by the developers (before customer registration), that would be ideal.
Basically you cannot specify it in advance, it is up to the customer's administrator to set up the requirement.
This is their concern, not your application's concern.
One possible way would be to set appRoleAssignmentRequired on the created Service Principal to true via a Graph API call.
But that will require quite privileged access, with their admin logged in.
Service Principal entity reference
Get SP by app Id
We have a multi-tenant single page app (and backend) that uses Azure AD for authenticating users. We'd like do queries to customer's Azure AD for retrieving groups but make it an opt-in behavior for customers (tenants). The reasoning behind that is that not all customers necessary need the functionality and would rather not grant us access to their AAD unnecessarily.
Is there some way of implementing this with Azure AD?
I've been trying to test with different OAuth /authorize calls with resource IDs and scopes but mostly I end up with "AADSTS65001: The user or administrator has not consented to use the application with ID ''. Send an interactive authorization request for this user and resource." error. Configuring the web app or backend to require the permission would surely fix the error but that will also make the approval of it mandatory for all users of the app.
Is there a way of using the authorize/consent API to request access to a new application on-demand?
An ugly work-around that should work would be to have 2 client IDs and 2 backend IDs with different permissions but ADAL.js doesn't seem to be designed to work with multiple Client IDs (it's singleton, for starters). Also Application Permissions should of course work but I'm not sure how much of those are required to search for groups.
Is there a way of using the authorize/consent API to request access to
a new application on-demand?
Do take a look at Azure AD v2.0. With their incremental & dynamic consent model, it is possible to do so though I am not sure if this specific functionality (managing groups) is available there.
I had a discussion with Azure AD team member recently about this (as we are also facing the same problem) and he suggested that we take a look at this.
Essentially the way things work in Azure AD v2.0 is that you start with basic set of permissions (like sign in, read profile etc.). Then when some tenant need specific permission, you essentially ask them to grant those permissions to your application at that time only. What this means is that different users in your application have granted different permissions to your application.
If you are using MSAL, and looking for a way to dynamically change your scopes before authenticating, have a look at this: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular/docs/v2-docs/configuration.md#msalguard---dynamic-auth-request
More here: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular/docs/v2-docs/configuration.md#platformbrowserdynamic
I want to set up a website on Azure according to the following requirements and are wondering if it is even possible?
As a internal team member, I must be able to login to the site with Windows Authentication
As a external customer, I must be able to login to the site with user name and password
As a external customer, I must not be able to access a subset of the site
As a unauthorized user, I must not be able to access anything on the site
I guess I have to set up a VPN connection between Azure and the Active Directory in my company. How do I do that?
Is it at all possible to meet my requirements?
Background Information
We are a small project with about 10 team members.
We have four large customers who need access to the site, and there are a few people in each customer who needs to have access to the site.
Customers will just have read only access to static, non-sensitive information.
The team members will have write access, and will also handle some sensitive information.
** Edit **
I have now managed to create efficient synchronization of our projects local AD to Azure, thanks user18044. Unfortunately, the accounts for the team members is located in the company's AD (corp.mycompany.com), and out AD has one-way trust with it.
We have groups in the project-AD pointing to our accounts in the company's AD, but the members in the groups is not synchronizing over to Azure.
Can this be solved?
Yes, I think what you are describing is doable.
Your first two bullet points are about authentication. As Azure Active Directory does not directly support Windows Authentication, federation is the way to go here.
When you as an internal team member log on, you land on what is called a home-realm discovery page, where you pick the realm you want to authenticate in. Picking the realm of your company, you get redirected to the STS (for example ADFS) your company has set up to authenticate you. If you are in the same Windows Active Directory network as the STS is authenticating against, you should be able to use Kerberos to be issued a token.
An external customer would be redirected to another STS that would use forms authentication against a credential store to issue security tokens.
Both security tokens are then posted back to Azure Active Directory which is configured to trust both STS's and issues a token of its own. See here for an example.
As for the second two bullets, the authorization part you can do based on roles you assign to your users. Depending on which STS authenticated your user, you assign them a certain role. Based on that role you can give access to certain parts of your website or not. How to implement this depends on what stack you are using for your web application, but a Google search should give you some leads.