As part of BC/DR readiness, I want to back up my Auth0 tenant regularly, and store this backup in a way it can be retrieved and restored later. I read here that the way to this is via the Auth0 management API. And so, I was wondering whether there is an endpoint that will provide me with the entirety of the data in the tenant (I know that password hashes and secret keys are not offered via the management API, I am ok with this data not being included) in a way that I can restore later (in a snapshot-like manner) into a tenant? As far as I investigated, the GET tenant endpoint does not provide the full data.
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 have a database with all my employee's information. Should I build an API or should I give direct access to the database?
The API could be built with Node.js and be a REST API. The database access could be given with different database users / different permission sets.
I'm confused because when I query an API, I usually get JSON data back which is awesome. So I wonder if only I can build an API that contains all the data I want and when I query it, I can have my employee's info back in JSON format.
There are reasons to use a REST API. For example you'll have a app, that will be available to the public, you might don't want to write your SQL queries directly in your code, as well as the credentials to connect to your server. Anyone with the knowledge could decompile your app and see your code and have access to the credentials to you database server. The good approach here is to write an REST API to handle the flow of data between your app and database, since REST API should be designed to be accessed publicly, you'll only have to pass in the data, or just call the api you need, you don't need the servers credentials to connect. If you are going local, then you could use the database approach of yours. Since your app will be used only by your clients.
I have some general/how-does-it-work-inside questions about WebAPI and OWIN (specifically, the default configuration which is set up when you create new WebAPI project in VS2013 and select Individual user account authentication). I did that, then I registered (using jQuery post) and even logged in (received token which I included in Authorization header, receiving access to protected resource. I just have some more questions about it:
Are my data stored inside authentication token? I know my password isn't, but is token containing encrypted data, or is just a random string? These are the only 2 options that I can think of: either token contains encrypted data (userId, expiration date, etc.) and server app deciphers it and grants me access to resources, or token is a random string and all user data are stored on server (token is used as a key to obtain correct user data entry). If the second theory is right, the token <-> userData lookup must be stored somewhere - is it session, cache or database maybe?
If i wanted to make a RESTful API, what about Roles, etc. (in general - data beyond simple who-are-you identification that I need for every request)? Again: first thing that comes to mind is to store them inside token. But if the data grows large isn't that too much overhead to send with each request (plus headers themselves probably are limited in size)? Second thing is using external OAuth service (like Facebook or Twitter) - if the user authenticates using external token, I can't control what information does it contain. Alternative is to get the data I need from the database each time, but isn't it bad practice? Every single request would need an extra database call to collect user's role and check if he even has access to this particular part of application. I could store it in session, but RESTful API is supposed to be stateless.
Thanks for any help as I'm just starting to dig into OAuth and WebAPI authentication. I know that I can customize everything to work as I want (so use session to store user data, etc.), but I wanted to know what the good practices are and which of them are provided out of the box with default WebAPI project in VS2013 and which need to be implemented manually.
(1) the latter is correct. The server verify token by machine key and can decipher and validate its contents.
(2) You got that correct. Its best to keep the token size min. tbh I am looking to see what others are doing about this. (+1 for the question.)
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?
Background research:
User Signup in Couchapp/CouchDB through jquery.couch.js or Otherwise
http://blog.couchbase.com/what%E2%80%99s-new-couchdb-10-%E2%80%94-part-4-security%E2%80%99n-stuff-users-authentication-authorisation-and-permissions
https://issues.apache.org/jira/browse/COUCHDB-1175 - specifically "Ari Najarian" 's posts
Question:
To paraphrase the SO question I posted above:
"Essentially I want to have a signup form for registering an account in couchdb for a couchapp. This would entail creation of a new user in the couchdb _users database, and the creation of a new database, with the new user assigned the role of database admin. All that requires server admin credentials."
The answer to the previous question involved using an external separate server that was logged in to couchdb as admin to monitor couchdb and modify couchdb as desired in response to certain data events coming from a client.
My question is - is that the only way? Doesn't that defeat the whole purpose of couchdb's 2-tier web stack? Is there some way to modify a couchdb database from within a validation function which checks for "type == user" document while "internally"/separately logged in as an admin maybe?
I apologize if there is some straightforward way to do this and I just didn't find the right documentation.
Extra Problem Clarification:
There is the couchdb instance sitting at an internet address.
This couch database serves to a random client an html page and embedded javascript script that contains a signup/login form.
The client enters signup info (name, password) and submits
The JS script uses the XMLHttpRequest object to open a connection to the couchdb instance and sends...PROBLEM!
Problem #1 - If the credentials are stored in the code (to be sent as verification for new user database), then anyone could "view html source" and take over the database.
-OR-
Problem #2 - If credentials are not supplied and the request is sent anonymously, then a new user will be created in the _users database and a success reply message will be sent. But no new database was created for the user (and can't be without admin credentials) which the user can interact with for application-specific purposes (e.g. add/delete data). And - from the above couchbase blog link - if you have secured your database with roles/names against anonymous readers and validation functions to prevent anonymous writes, then an anonymous-made user account (e.g. a client who wants to register database space to use the app) can not do anything because an anonymous user cannot, for obvious security reasons, specify whatever roles they wish to have. Which means that the only way to have -functional- users is to create user accounts + associated databases as admin beforehand and then hand out these user credentials - so like a private invite system, yes?
To reiterate, is there any way, using ONLY couchdb and some combination of couchdb's authentication handlers, design document functions, client-side ajax, etc. for a connecting client to register and get a personal database (and ONLY that database obviously) they have access to and can interact with?
This isn't a PURE couch solution, but it's couch + node, and solves your problem:
Hi I haven't been around in awhile and didn't realize this was edited / link removed (plus policy of links not being answers! sorry...). I have been using couchdb on a project very similar to what you are trying to do, and unfortunately there is no way to do what you want to accomplish without tacking on another service to handle the admin-level access and creation of user database. Syncpoint-API can be used to facilitate this, but it is actually a nodejs service handling the signup/login and dedicated database setup.
So far though, Syncpoint has proven to not be 100% reliable and it does appear to be an abandoned project, due to CouchBase sucking all the r+d resources away from CouchDB dev.
I'm now moving to nodejs + socket.io as a transport layer, using node to handshake and assign a DB, and then further watching the couch _changes api on the server (via yet another node process) to then forward _changes through socket.io to the client. Also I have some "pure" couchapps running that serve public data mixed in with the private data.
My conclusion? CouchDB is a great product and has some great features, but for the more complex login/authorization schemes and other general application needs required in real-world dev, it's just not ready yet.