I am working on an application where I need to setup identity server 4. I have an api as resource. and a web forms application as client.I have few roles like teachers, students, parents in my database. How can I use this custom database and perform authentication and authorization without using identity?
Please suggest.
From your other question here I get a better idea of what you want.
I think one solution for what you want would be to setup identityserver4 in a seperate project with its own seperate database. I noticed the tag identityserver3, but I think it is quite safe to go for identityserver4. It shouldn't make a difference for the client/user since they are conceptually compatible.
1) Give your application a client/secret (which you configure in identityserver) in order to identify your application and grant access to the resource api. Here is some information: http://docs.identityserver.io/en/dev/quickstarts/1_client_credentials.html
You'll only need to configure one client to protect your resource from the outside. The only way to access the resource api is through your application, since your application is making the actual calls. This is also the drawback, you cannot expose the token to the outside world.
Since your client isn't the actual user, you'll need to identify the user. You can use any mechanism based on your current model as you like. A simple user/pass (with or without asp.net identity) could be enough to determine the roles. But please keep in mind that your application has full access to the resource api.
2) However, since identityserver is available, why not use it? Why don't you want to use the identitymodel? I think you should consider to seperate the identity information and your datamodel. Your datamodel shouldn't be aware of the security. And the security has nothing to do with your datamodel.
When you create a seperate database for identityserver you have one place to configure the identity users. All you need is a reference (sub) to the user in the datamodel. http://docs.identityserver.io/en/dev/quickstarts/2_resource_owner_passwords.html
Add claims or roles and everything is in place and you'll see there is no need to keep identity data in your custom database. The structure of your custom database stays intact, including the user table but without the identity data.
I think this is a safer solution and considering the good documentation and sample projects it may even turn out to be a quicker solution.
Related
I'm driving myself mad with this and hoping a better method exists.
The scenario is this: I have written a Blazor Web Assembly application with server hosting. The application needs to implement row-level security (using EF Core) but I need some access permission to be looked up in another database via an API (external supplier so have no control) to be used in the security.
Ideally I'd love the permissions to be managed in AAD but that isn't supported in the external application and is too much overhead to manage manually.
On the client side I use a custom AccountClaimsPrincipalFactory to lookup the correct permissions and create the user claims.
What I'm struggling with is to then to manage this server side, I've looked into using IClaimsTransformation to lookup the claims again but this produces too much overhead as it is called on every request.
I've (not imagining it would work) tried adding claims client side, adding a new identity client side and accessing on the server. All I've really got left I can think of is using the AuthorizationMessageHandler to encrypt values and pass to the server that way as a token, it works as a work around but probably not the best method.
Is there a way to somehow lookup the database values and maintain them within the identity/token so they can just be passed around?
If this is a stupid question, feel free to give me a slap, I've just exhausted my google search terms for it.
Thanks
So I was using a basic 'if authenticated user' placeholder rule for Firestore when I started using Geofirex. However, when I try to query/use the database with geofirex, my security blocked it. I'm currently running without any rules for the sake of development, so I know everything works, but I have no idea how to add rules to allow this library or have the library identified with the user. Is there even a way to do this?
If a library runs in the same process as the rest of your application code, there is no way to set up separate security for that library. All requests coming from the application are (and should be) treated equally, as there's nothing that inherently makes the library code more trusted than the code of your own application, or the code that malicious user may write.
What you can do is creating an additional collection that only contains the location of each object and its key. You could then point Geofirex to that collection and allow read-access to this data to all users, while securing access to the more sensitive other data about each object. This is what the original GeoFire libraries from Firebase did, and while it leads to more code (to read the additional data objects), it makes it much simpler to secure data access.
I'm part of a frontend project and I need some help to bring our authorization model into keycloak. We're building on node.js and the whole project uses stateless micro services - as well as our frontend middleware as the whole backend services we use. The frontend uses the standard JS adapter for session and token management.
So far we have identified four roles: travel agent, back office, configurator and data security officer. That's easy so far. My problem is how to model the next authorization layer we need.
For example: For the travel agents we want to be able to grant per person whether he can see specific customer data or is able to cancel orders. There are about 6-8 options for the travel agents. Thus, for the back office there shall be options for stock operations or different views on orders.
Like the backend we don't persist any data! That's why I have store all the things in keycloak and find a way to easily bring these information back to our middleware.
Here's what I tried / thought of so far:
* Use groups for the first layer and roles for the second one. --> doesn't work because the groups don't get exposed in the token.
* Use realm roles for the upper and attributes for the lower hierarchy. --> attributes are not included in the access token.
* Use realm roles for the upper and client roles on the lower hierarchy. --> works, but we have to make sure that roles on the second layer are definitely associated with only one role on the first layer. I don't know how yet.
* Use roles for the first layer and resources on the second one. --> That seems to get very close to what we need. But at the moment I can't figure out the correct approach with all these policies and permissions...
Discussions here at Stack Overflow seem very fruitful and I wanted to give it a try, although I don't have any code to offer.
Thanks for any help and please let me know, if I shall provide some further information.
Sven
Unlike the downvoter, I find this to be a legitimate question.
It looks like you're on the right path in terms of using Keycloak groups/roles/attributes. You can pick a combination that suits your needs. For example, if you need a hierarchy structure, you might use groups. Or you might want to use roles since these can be composite.
Regardless of which path you choose, your problem is how to expose these in the token. It can be done using mapper configurations.
For example, to expose Roles for the user, you'll want to create a "User Realm Role" mapper that adds your roles as a claim on the tokens. To do this:
click on "clients" in the left side menu
click on the client you're using
click on the "Mappers" tab
add a mapper of type "User Realm Role".
There are also mappers for "Group Membership" and "User Attribute" that can be used to add these two concepts as claims. If those aren't enough, or if you need more fine-grained control, you can roll your own custom mapper. See the Keycloak documentation and other questions here on Stack Overflow for how to do this.
I'm looking into how to integrate [Authorize] within my MVC 2 application... I'm reading articles about it and I've run the aspnet_regsql tool. I see that my database now containes a bunch of new tables and a whole hell of a lot of SPROCs.
Why is all of this necessary? I thought that I would be able to check login credentials in a table that I've already created for Party ... can't I just call a SPROC that checks the login credentials and then logs the user in? Why all of these new tables and SPROCs?
Because it is the way how it is works. If you using ASP.NET Membership by default you need to have database aspnetdb with lots of tables and stored procs. If you want you may customize that. In order to do that you need to implement custom membership provider.
The simple example how to do that you may find here http://msdn.microsoft.com/en-us/library/aa479048.aspx and here http://www.asp.net/general/videos/how-do-i-create-a-custom-membership-provider also source code available.
It sounds like you want to create a custom membership provider. For logging in I think you really only need to override the ValidateUser method:
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
For roles you may be able to get by with overriding only the IsUserInRole method:
http://msdn.microsoft.com/en-us/library/8fw7xh74.aspx
I need some opinions.
I'm going to develop a POS and inventory software for a friend. This is a one man small scale project so I want to make the architecture as simple as possible.
I'm using Winform to develop the GUI (web interface doesn't make sense for POS software). For the database, I am using Postgresql.
The program will control access based on user roles, so either I have to develop a middle tier, using a web server, to control user access or I can just set user priveleges directly in Postgresql.
Developing a middle tier will be time consuming, and the maintenance will be more complex. So I prefer to set access control directly in the database.
Now it appears that using database to control user access is troublesome. I have to set priveleges for each role. Not to mention that for some tables, the priveleges are at column level. This makes reasoning about the security very hard.
So what I'm doing now is to set all the tables to be inaccessible except by superusers. The program will connect to the database using public role. Because the tables are inaccessible by public, I'm going to make publicly accessible stored functions with SECURITY DEFINER (with superuser role). The only way to access the tables is by using these functions.
I'll put the user roles and passwords in a table. Because the user table itself is inaccessible by non-superuser, I'll make a login function, let's call it fn_login(username, password). fn_login will return a session key if login is successful.
To call other functions, we need to supply session key for the user, e.g.: fn_purchase_list(session_key), fn_purchase_new(session_key, purchase_id, ...).
That way, I'm treating the stored functions as APIs. Adding new user will be easier as I only need to add new rows in the user table rather than adding new Postgresql roles. I won't need to set priveleges at column level. All controls will be done programmatically.
So what do you think? Is this approach feasible and scalable? Is there a better way to do it?
Thanks!
I believe there is a better way to do it. But since you haven't discussed what type of security you need, I cannot elaborate on specifics.
Since you are developing the application code in .NET, that code needs to be trusted (unlike a web application). Therefore, why don't you simply implement your roles and permissions in the application code, rather than the database?
My concern with your stated approach is the human overhead of stored procedures. Would much rather see you write the stated functions in C#, rather than in PostgreSQL. Then, standard version control and software development techniques could apply.
If you wait until somebody has at your database to check security, I think you'll be too late. That's a client/server mentality that went out at the end of the 90s. It's part of the reason why n-tier architectures came into vogue. Client/server can't scale horizontally as well as an n-tier solution.
I'd advise that you take better advantage of the middle tier. Security should be a cross-cutting concern that's further up the stack than your persistence layer.
If the MANAGEMENT of the database security is the issue, then you should add the task of automating that management. That means that you can store higher level data with the database tables, and then your application can convert that data in to the appropriate details and artifacts that the database requires.
It sounds like the database has the detail that you need, you just need to facilitate the management of that detail, and roll that in to your app.
My honest advice: Do not invent POS and inventory software. Take one of existing projects and make it better.