Is it possible to use SQL's Dynamic data masking with Entity framework?
If it is possible, is there any way to combine it with Asp.Identity?
Project I'm working on requires that data is masked for certain user roles and visible to others.
We are using database first approach and Entity framework with data fields masked with:
MASKED WITH (FUNCTION = 'default()')
that need to be visible to admins and remain masked to other user roles. User roles are defined thru Asp.identity.
If it suits well your app architecture you can try approach from this blog post this blog post.
In two words you can create special db user which will represent your "other user roles". And then create two instances of DbContext: one for admin and one for the rest of your roles. So, basically, it's all about user identity provided in connection string.
Correct instance of DbContext with right connection string based on current user you can, for example, provide with dependency injection.
Related
So from what I have read on IdentityServer I should be storing details about the user such as first name and last name inside claims. How would a web application then be able to access the claim information? Since the User Info endpoint requires a valid access token representing the user, I suppose I would need to make an API that could access that returned the profile information of other users? Is this the right way to do it? (use case, web page needs to display contact details that are stored in claims of another user)
Also what would be the way for multiple language profile information be stored and retrieved in the claims? For example a user can have a name/title in multiple languages. I'm thinking of making [LanguageCode]_[ClaimType] (fr_first_name) naming convention and either adding all languages to just the profile IdentityResource or creating separate resources per language.
Your best bet is to set up a project using the IdentityServer4 QuickstartUI example and review that code to better understand how it all works. As of version 4, Identity Server is only focused on the sign-in / sign-out process and the various flows around authentication. They also provide a basic EF-driven persistence model, and they also support the ASP.NET Core Identity persistence model (also EF-driven), but both of those are not meant to be production-ready code.
Basically, persistence of user details is considered your responsibility. That being said, the cookies used for ASP.NET Core authentication greatly restricts how much data you can/should store as claims. The best model is to keep "real" identity provider (IDP) claims as claims, don't add new claims to that list, copy what you need into some other separate user-data table you manage completely, and use the unique claims identifier (almost always "subject id") as the key to your user data. This also makes it easier to migrate a user to another IDP (for example, you'll know user details for "Bob" but he can re-associate his user data away from his Facebook OIDC auth to his Google auth).
Basic persistence isn't too difficult (it's only 12 or 13 SQL statements) but it's a lot more than will fit in a Stackoverflow answer. I blogged about a non-EF approach here -- also not production-ready code (for example, it has ad-hoc SQL to keep things simple), but it should get you started.
I'm using Identity Server 4, Asp Identity, EF Core and one database.
I have 3 projects at the moment
IdentityServer - Contains all data contexts and all migrations with my app tables
Api - no context, no migrations however I need to access database somehow from here
Clinet - javascript
The question:
How do I access data context from IdentityServer project and still have all settings (db connection, etc) in one place. I understand I can reference IdentityServer from API and use data context but it seems not right to me. What is the preferred way to do this ?
Since you are interested in this option, I've decided to move my comments to this answer.
First of all, IdentityServer is not the place for your app tables. These are seperate contexts and separate migrations. The preferred way is to maintain the separation of concerns.
As I explained in my answer here, you don't need a relation between the login user and your business context. Instead create a user in the business context. The login user has a different purpose than the business user.
I don't have code for you, but you can take one of the sample apps from IdentityServer. Adjust the API to use your business context. In that context add a user table (which links to the sub claim) and the fields you need for the business context. BTW it doesn't matter if the tables are in the same database, just don't mix the contexts.
In IdentityServer: if the user may register for one website then you can extend the registration form with a drop-down of available websites. Or a list if the user can register for multiple websites.
Now it depends on the chosen strategy. You can wait to register the user in the API, but I think it is far more easy to register the user straight away. There are other options, but here's one where it is part of the IdentityServer configuration (without adding business logic to IdentityServer):
Extend IdentityServer to call the API after registering the user. For this I would add a table in the IdentityServer context with URLs to register per website. When the login user is created, call the configured API(s) to register the business user.
In the API you need to add the method that IdentityServer can call to create the user, linked to the sub claim and including the required user information. This way you can suffice with the sub claim to identify the login user and link this to the business user.
You can use a similar strategy for client apps. Extend IdentityServer with an API method to allow client apps to register users.
If you want to withdraw access, you can delete the login user without having to delete the business user. Which you don't want if you don't want to destroy historical information. You can also use claims to specify if the user has access to the website without having to delete the login user.
Logical Question
Backend implementation
I am implementing User Management Module in Web application. I have three table User, Role and UserInterce. The user table has ManyToMany relationship with role table and Role table has ManyToMany relationship with User Interface table. So whenever Server return user object, the system will verify it's role and that role has access right to which user interface.
this is background overview of backend implementation.
Front End implementation
Whenever user login into the system,server will return user object. I want to implement access control in form basis. e.g. emp role do not have access right to add button where admin role has access right to add button. To implement form based access control i would require to create another table at server side which has information about ui fields and that will be has relationshiop with User Interface table.
can some one provide better way of doing same thing logically ?
If you don't need to have possibility to edditing role's permissions in runtime, the best way is to use spring JSP tag library and build your frontend using spring security tags
http://docs.spring.io/spring-security/site/docs/3.0.x/reference/taglibs.html
Otherwise, using some table for storing your permisssions is the only option to do that
I want to create multiple levels of users in my application developed using django1.6 and python 3.2. I inserted the levels in auth_group table. but in the add user page of Django Admin I can assign one user to more than one group(multiselect Group values). Actually I want is one user to one Group only.
Please reply me.
Definitely change the django core is not an option. You shouldn't never do it because in the future you will have problems to update your system to the new django versions,
I can't see clearly why you want to do it but if you really think is a good implementation you should extend your Authentication model to implement what you need:
https://docs.djangoproject.com/en/dev/topics/auth/customizing/
This is more like a question for an advice rather than a precise answer...
In my CakePHP app, I will have backend users and frontend members. They have completely different roles and permissions (users are application managers, members are visitors that register on the website without any access to the application backend). Should I use different tables for these two authorization types, or should I just manage them with a role parameter and bind tables to their profiles depending on it, and why is one solution better than the other?
Use the same table and role or type field. You will have only one login and it will be easy to manage the accounts.
Use ACL or a custom permission system to allow them to different controllers/actions.
For permissions, I have 3 ways to do it :
The strict-role way :
Every role of your application has access to functions with their prefix, but not any other prefix.
Ex : admin has access to admin_edit, but not customer_edit
You add a role varchar or enum in your users table, the routing prefixes in Config/core.php and you allow the access in a AppController::beforeFilter : each role is allowed to access to his prefix only.
The hierarchical way:
Your application's roles are ordered in a hierarchical way, where a role has access to his prefix and every prefixes under him.
Ex : admin has access to admin_edit and customer_edit, but
customer has not access to admin_edit
You add a role varchar or enum in your users table, the routing prefixes in Config/core.php and you allow the access in a AppController::beforeFilter by checking for each $this->request->params['prefix'] which roles can has access to it.
The custom way:
You need your admin to access to some functions, but not all. You need another role to access some functions admin can access, and some functions admin cannot.
Ex : admin can access to admin_edit and customer_edit, but not
customer_create or user_stat. customer can have access to
customer_edit, customer_create and user_stat, but not admin_edit or
user_edit
Use ACL. It's not the easiest way to manage permissions into your application, but if you want specific permissions, it's the best way. So remember this : only use ACL if you really need it.
I agree with cornelb: one table only. Here are some additional reasons:
If you add foreign key constraints, it might be messy to make them refer to both the app managers table, and the visitors table. Always when you want to point to a user, you'd need 2 fields, instead of 1 (a field pointing to the managers table, and one to the visitors table — and exactly one of them has to be null). And what if you need 2 user id fields in a row, with foreign keys? Then you'd suddenly need 4 fields. Simper with all keys pointing to just one table (and user type decided by the above-mentioned field).
Sometimes you might want the user id be part of a primary key — but that's more complicated, if you have two different user id fields, one in each table. Because then the database cannot guarantee that each user id is unique — you'd have to do it yourself at the application level.