I have read the documentation on Microsoft.com and have only got answers about giving Applications authorization to talk to eachother but not how to implement a permission system on each different application that I have.
I basically want to know what the best practices are to implement Authorization on my .Net API and Angular Client.
I would use Azure AD to redirect external and internal users to the Microsoft Sign-In Page, I am missing a fine grained Permission system to authorise users to access different Resources on the API or on the Angular Web Application.
Wo I have to set up a DB for my API with permissions?
How do I add new users to my DB after registering them to my AD?
Im really confused here, so my questions aren´t really as clear as I wish I could write them.
Compiling comments to a proper answer:
Per-user permissions are limited to appRoles, roles that you can give in Azure AD to users. You can also use security groups to achieve a similar thing if you want. But anything finer-grained has to be implemented on the app side.
For identifying users you can use one of two claims in the user Id token / access token. oid or sub. The oid is the unique immutable object id in Azure AD. The sub claim is a unique immutable id within your app. So every app gets the same oid, but a different sub for the same user. The oid claim is also used when calling e.g. MS Graph API to identify the user.
Related
I'm designing the architecture for a college project and I don't know how to deal with the user authentication and authorization part of it. The project is a desktop Electron app which would need two types (hence the roles) of users. They both need to be authenticated in order to use the app, and depending on their identity, they will have different authorizations. Since the project is meant to be used by teachers and students as part of a laboratory class after it is done, I don't think more than 30 people will be using it at the same time.
My first thought was using a PostrgeSQL database in AWS for this and implementing the authentication myself, but this means that users will have to sign up and create a new profile, which means remembering yet another <username/email, password>. Trying to avoid this, I read a bit about OAuth 2.0 and OIDC, and how it can be used to authenticate and authorize users without implementing either of those tasks oneself, but rather delegating the task to OIDC. I created a free account with Auth0 and thought about using it for the OIDC integration but after reading about 40 pages of an "OIDC integration handbook" they offer for free, I could not know if I would be able to distinguish my user base through these roles or tags as I mentioned. I just followed the steps in the tutorial handbook and tried to understand how the auth flow worked, but that didn't give me any information on my question.
So all in all what I want to know is: is it possible to implement this with Auth0 (free account) without having to use a third-party database solution (such as PostgreSQL with AWS)? If not, what would you recommend me to look into? Preferrably a solution that will let me discriminate between the two types of users BUT at the same time taking advantage of the OIDC implementation of Google for example.
There are 2 separate solutions here:
DESKTOP AUTHENTICATION
The 2 standard requirements are:
Use Authorization Code Flow (PKCE)
Login via System Browser
You listen for a login response via one of these mechanisms (I prefer the latter):
Loopback web server
Private URI scheme OS notification
My blog has some tutorials + code samples that use Electron. You can run both of the above listening options and see what you prefer.
API AUTHORIZATION WITH ROLES
You need to make roles available to the API via claims. This can be done by either of these mechanisms (I prefer the latter):
Including roles in access tokens via Auth0
Get the API to read user roles from its own database
My Authorization blog post discusses building up a claims object in an easy to extend way. The main objective is usually for API OAuth processing to result in an object something like this:
class UserPrincipal {
// The technical user id from the access token
string sub;
// The user id from your own database
string userId;
// The user's roles
string[] roles;
}
Given that object you can do things like this:
Use role based authorization when needed
Serve up user resources after login from your application data
TO SUMMARISE
Auth0 will meet some of your requirements and may be all you need in the early days. You will probably need to manage non OAuth user data in your API at some point though.
Happy to answer any follow up questions ..
Suppose that I have a web application. Consider it like a Black-Box for now. I want to use a backend system to limit what a user can view/do on the app.
i.e. Sample users can only do three functions, Premium users can do 10 functions and see more pictures.
What is the best way to do it?
I'm trying to using WSO2 Identity Server, but it doesn't offer this functionality. So I've thought that maybe I can integrate it with the WSO2 API Manager and make an API that limits users' access to a certain resource. But really I cannot find if it's possible do it. Anyone know it?
Please refer to : https://docs.wso2.com/display/IS530/Access+Control+Concepts
1) WSO2IS can act as a coarse grained access manager. Your application will act as a fine grained access mnager.
It means that roles can be defined in WSO2IS, managed and assigned to user. From there Roles assigned to one user can be provided as clains with the identity token generated by WSO2IS and sent to the application.
The application, on the other side, will manage roles to permissions links.
Access control is then done at each request by the application, based on the roles presented in the Identity Token by the user and the Permissions grid based on roles in the application.
2) The access control at the application is a business logic you must implement (or at least configure if it a COTS). It is possible to outsource this logic to WSO2IS as policies on attribute (with Workflows).
Please look at : https://docs.wso2.com/display/IS530/XACML+Architecture
Jeff
I am working on a project that allows a user to create a user to create app keys or secrets so that specific services can be used by external clients. A user can create multiple secrets that they can choose to use across multiple clients.
For this I am planning to create a decoupled auth server that will use identityserver4.
What really holding me back is that I am not sure whether or not I should create an API layer at the auth server. The reason I am considering API at auth server is so that I can create sort of an admin portal client that will give the users a front-end for creating, renewing, and accessing their app keys/secrets. Even the admin portal is going to be a de-coupled angular application.
There are two things that are holding me back at the moment:
I am not sure if it's a good or safe idea to serve this data via
an api layer. From what I understand, identityserver will not be able to provide functionality that allows me to access a list of a user's clients through an endpoint but please correct me if I'm wrong and there's a better way to approach this.
I know we can easily create new clients and persist it into the database with identityserver4 and I am planning to use ClientCredentials grant types for user clients, but is there a link at the database and identity level between a user and a client? Or will I need to create that functionality by myself?
So far I've looked but I have not bee able to find examples that are similar to my situation with identityserver4
Sorry for the noob question, I am just getting into identityserver and web security in general so many of these concepts are still very new to me.
For number 1, I would say yes you can create an API layer to server data. If you check the IdenttiyServer4 AdminUI, Rock Solid has also use the admin API behind the UI. But you must consider encryption, TLS and other security mechanism to keep this safe.
AFIK for number 2, there are no links at identity level between a user and a client. You have to create that by yourselves.
Basically, you need a system that supports Multitenancy. I have achieved that by adding a TenantId field in the AspNetIdentity user table. And also added the tenant Id to claim list.
Please do not hesitate to correct me if i am wrong.
I'm unsure if this is a programming question or a database question
I'm making a web api, I use bearer token authentication and its working really well, I can login get resources and logout, I can added users and users can add users which ill explain next.
I have 3 main roles, CompanyAdmin (users who created the account in the first place), CompanyUser (the user company admins make) and StandardUser (users the company users make)
Everyone has a row in the users table for logging in, now when a user logs in I don't want them loading up fiddler and seeing another users data by manipulating the url, I want to make sure companys cant see other companies data, users cant see other users data from the same or another company.
I'm using WebAPI MVC, SQL azure database and the website is hosted by my hosting provider. all accounts that can log into the site and access the api have a row in the users table from which only a few tables hang off it mostly for claims, roles, profile, company data etc.
Any help, pointers in the right direction would be helpful thanks
Getting the access to the data by simply passing the request payload means, that there is no security in the broker between the client and database. There are some ways to secure the access that are exist and actively used, one of them, for example, is the simple, basic authentication where you are setting the context by passing credentials, (dis)advantages are described on the same page above. Or using token-based authentication (more detailed walkthrough).
So, please avoid the possibility to do a just pass-through the request through the Web API.
Also you may check that old but good book on creating the multitenant solution and partition your database for customers/tenants on Azure. Some titles from that are not available already (Ex.: Federations), but examples of how to partition your SQL Database and some code samples should work.
I am quite confused about one requirement that i've received and how to correctly fullfill it...i hope that someone can help me figure out something.
I have to add Authentication/Authorization to an existing MVC 5 intranet application that will be used only by the customer's intranet users. This web app hosts an AngularJs application that uses a set of WebApi (hosted inside the same intranet and used only for intranet purposes).
The application will be used by different kind of users that can have different grants (e.g: can create things, can modify things, can delete things) and those grants must be declined for different Countries (consider the Country as, conceptually, a subsite). So a User can be the "administrator" (considering the administrator as a User with all grants) for the France, but be a simple user for Germany and not authorized at all for the other countries.
The requirement is to use AD for Authentication, but not for Authorization purposes.
I am not an expert of security and i did some research to try to understand the possible solutions. The most important thing i have understood is to separate the Authentication from the Authorization.
From a simple Authentication point of view, it's easy to use AD (or Windows Auth).
What i am missing is how to perform the Authorization part.
I have seen a lot of tutorials for ASP.Net Identity with Individual Accounts, all it's clear and easy, as it's using the UserManager to perform lookups on the db for the users to verify the authentication, and from there take the roles data(saving those info in a cookie).
I need to understand what should be the correct way to handle my scenario.
The user should log in using it's domain credentials, then i should receive a response from AD, if ok i should get the corresponding user from my db and retrieve its role data...correct?
If so, how could i perform those tasks.
Is it a wrong way of solving the problem?
And if so, how can i do that?
What is the best way to "pass" the auth/entication/orization token to the WebApi in order to secure them as well?
One last question...could it be possible to fulfill the requirements by using only AD (not relying on the db for grants)?
Sorry for the (most probably) dull questions but i'm feeling like i am missing some VERY key points.