I have an application that authenticates and authorizes the users within application. The application then connects to the database using a service ID. because of this, all actions on the database are run as the application and not the end user. I now have a requirement to tie all database actions to the end user. Can anyone tell me at a high level a couple of ways to solve this?
thanks
I know of two high level approaches. One is to use something like [Kerberos Delegation (Kerberos, delegation and how to do this correctly?) to actually take the user's authentication and log into the database as a user. The much more common approach is to store the end-user's ID in all created or updated rows and to trust the application to do this correctly.
Related
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 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.
I am creating a Web API service for an application with a single tenant database. Each company will have it's own database strictly controlled and created by us. I am aware of the maintenance implications of single-tenant databases compared to multi-tenant and we feel single-tenant best fits our needs. Users will be created by us only.
There will be a master database to "map" each user to their company database when authenticating based on only their username (email address). If there is a match on email the authentication will then continue within the client's company database which will contain the password hash.
This leaves the databases self contained which is needed for foreign keys for audit records. The master database simply acts as a mapping or routing based on username (email address).
I created a new Web API project and used the Individual Accounts template. I like the way it works but unfortunately I don't see how I can customize this enough to accommodate for my needs. Would this be possible? I need to use tokens. The only other alternative I can think of is a completely custom authentication procedure but security is not something I want to take lightly as I'm sure I will mess up somewhere along the line. I am aware that the user passes its username and password over SSL to the server which responds with a token which then gets included in the header of each subsequent request to an authorized resource. I just need to know if this is something I will have to completely implement myself? This whole thing may just be a silly model for an application in which case I am open to suggestions.
Any feedback would be helpful.
Thanks
After lots of searching I finally found the type of solution I was looking for. Dominick from Thinktecture has a blog post which details a nice embedded token authorization method which I can now extend upon. This is exactly the type of solution I was looking for as it is extremely simple.
Embedding a simple Username/Password Authorization Server in Web API v2
I need that in a Intranet application that is made with Play Framework 2, the credentials that the users have for authentication can also be used to authenticate to the database and that every statement sent to it also uses this credentials.
In other words, to each user of the application corresponds a database user and password.
Thanks in advance.
This means you won't be able to use the connection pool, and instead you will create a connection-per-request sort of, right? No built in support in play for this, but probably not very hard to do yourself.
The exact solution depends on how you will access your database (Slick, ANORM, something else?) but basically you will have to create some abstraction that takes auth and creates a database session that your database interacting code will use.
I wish to create a functionality that is very similar to facebook or pokerstars if you have used them before. Basically the apps require the user to login and their information can be accessed from both browsers and native and web apps.
How can I go about achieving this? Please advice on what services to research on to accomplish this. To my current understanding. I would be creating the website in html and php and creating a webservice using RESTful protocols and hosting them on amazon aws servers. I can then connect to these servers in the native apps? I am not very clear on how the native apps will interact with the servers
If you know of any particular protocol or a better server hosting service please let me know.
If I'm interpreting your question correctly, you are looking for something like this:
The user starts either your browser app or your native app (perhaps a mobile app)
Since the user does not have an account yet, you present them with the appropriate dialog to create said account.
You then ask the "Identity Service" to create a profile for that user
The identity service returns a token for access
This is something we do in the mobile network industry all the time. Technically, we have TAC/ACS or HSS profile services, but in either case, it's the same thing -- a dedicated service and network process that:
Accepts connections from various clients (web, mobile, desktop...)
Has various primitives along the database CRUD (Create, Read, Update, Delete) model
Answers requests the database
If you want a pre-configured solution, you could just use any networked database with a RESTstyle connector for example (MongoDB maybe?) But you could also just through this in a process that talks to a NoSQL or SQLLite database. The end result is the same.
For commercial solutions, I might like at OpenStack as you can run your code on it and they have identity brokers you might be able to CoOpt.
Personally, I'd just have a datastore running on a cloud somewhere like Amazon's EC2 which answers RESTful requests such as:
Create a user with a given profile set, return a unique token
Delete a user given a token
Update elements of the profile for a given token
I'm leaving out the necessary things like security here, but you get the idea.
This also has the advantage that you can have a single identity service for all of your applications/application services. The specifics for a given application element are just sub-fields in the profile. This gives you, not only a common identity broker for web, desktop and mobile, but a single-sign-on for all your applications. The user signs in once and is authenticated for everything you have. Moving from site to site, now just became seamless.
Lastly, you place your identity management, backup, security token management, etc OUTSIDE of your application. If you later want to add Google Authenticator for second-factor authentication, you don't have to add it to every application you have.
I should also add that you don't want to keep the identity database on the direct internet connection point. Someone could make your life difficult and get ahold it later on. Rather, you want your identity server to have a private link to it. Then do something like this:
When the account is created, don't store passwords, store hashes -- much safer
Have your application (web or otherwise) compute a key as the login
In this case, the user might enter a username and password, but the application or website would convert it into a token. THAT is what you send across.
Next, using that token (and suitable security magic), use THAT as the owner key
Send that key to the datastore and retrieve any needed values
Encrypt them back into a blob with the token
Send the block
THe application decrypts the blob to get at values
Why do we do this?
First, if someone were to try to get at your identity database, there's nothing useful. It contains only opaque tokens for logins, and blobs of encrypted data. Go ahead -- take the database. We don't care.
Second, sniffing the transport gets an attacker nothing -- again, it's all encrypted blobs.
This means later on, when you have five applications using the broker, and someone hacks the network and steals the database, you don't care, because your users never gave out logins and passwords in the first place, and even if they did, the data itself is garbage to anyone without the user key.
Does this help?