For those who are not aware, Lotus Notes is a cool system, which has very powerful database replication abilities, and very strong certificate management and signing.
However that strong certificate usage is itself one of Notes's downfalls.
When you log in to Lotus Notes via a Notes client, the password you use is not stored anywhere, except as the encrypt/decrypt key to the Private Key stored in the Notes ID file on your local workstation.
What this means is that you can have 15 copies of this file, with 15 different passwords, and each one is valid, as long as you have the matching password.
For Identity Management systems, this is pretty crippling, as there is no server side component to access the password change event, rather it is entirely client based, and the server can barely even tell it happened!
The rumours I hear is that in later releases of Lotus Notes/Domino, this ID file based authentication is starting to change.
I am having trouble finding clear cut explanations for what is changing, how, and in what version. (8.5? 9? Later?)
Second part to this question is, what is happening in terms of Active Directory integration? I heard it rumoured that AD authentication might be allowed instead of ID file authentication. My guess on that aspect is that the ID file stored on the server will still be used for authorization, but the successful Active Directory authentication will be used to unlock access to it? Or is it some other model?
Looking for someones perspective who has figured this out already!
On a side note, there is a second password (httpPassword) that is used when Notes's Webmail is accessed, since of course the server has no access to the local ID file when the user authenticates. One assumes this is the model they would move to for other forms of authentication, but as we all know, assuming is a bad plan!
Notes Domino 8.5 has the new ID Vault feature. It was released in early January.
ID Vault works by keeping a copy of the id securely on the server. It then provisions the id on demand to the user. This allows for a configuration where the user asks the server to reset the password and the server makes the change to the id file before downloading it the the user.
More info on ID Vault here:
A New Way to Manage Notes User IDs and Passwords (dominoblog.com)
Sneak peak - the Domino 8.5 id vault (pmooney.net)
Updated: 8.5 has been released.
Related
I wonder if I might ask for opinions on a simple authentication system I'm thinking about for a pet web site project where the overriding requirement is that the system should have no way to tell who the user is, i.e. have no way of identifying or contacting them.
The system does need to distinguish between these anonymous users of course, and prevent users pretending to be other users.
Perhaps in a strict sense it's not an authentication system at all, more like a distinguishing system.
A simple solution would be to assign a Guid to new users, which gets stored in a cookie/local storage/whatever and used to distinguish them.
Then give the user the facility to copy the Guid, and/or generate a URL that they can bookmark or otherwise store locally, which re-supplies the Guid to the site and stores it as a cookie again - to be used if the cookie is deleted or they want to authenticate from another machine - by using the generated URL or pasting the copied Guid into a 'login' page on the site.
This means there can be no 'I forgot my password' facility; if the user loses their credentials, they are forever lost, that's accepted.
Additionally, if the credentials are stolen, or the user's cookies are compromised, then the credential is stolen forever, there is no way for the real user to lock out the thief, that's also accepted.
Clearly the user would need to make damn sure they store this URL/Guid somewhere safe, that's accepted.
As an aside, there could be a feature that allows the user to regenerate the Guid, which might be used if they accidentally broadcast their Guid somehow, but that also means if somebody steals their Guid and uses the regenerate feature before the 'real' user realises, the real user will be locked out forever - maybe best it's unchangeable so at least if the Guid is compromised, the thief cannot lock out the real user - but this is an aside.
Given the requirement for complete anonymity / non-contactability, and accepting that losing the Guid is like losing a dollar bill, you lose it forever, it seems a reasonable and pleasantly simple solution.
This is essentially the same as having a user/password combination with no email address or other contact details, but more secure than user: sally123, password: mydogsname1968 or whatever just by virtue of it being a Guid, not something the user can remember or easily scribble on a post-it note and stick to a monitor.
It also has the advantage that a user who uses the same machine all the time (and doesn't delete cookies) never has to login or think about credentials at all.
The Guid could actually be two Guids stuck together or three of them interleaved byte by byte, whatever - a unique auto-generated chunk of data that reflects how unnecessarily paranoid the developer is feeling.
Can anyone tell me why this wouldn't be a good solution, given the anonymity/non-contactability requirements and the drawbacks accepted above, or perhaps suggest a better solution.
If it makes any difference to anything, it'll be a Net Core 5 / Blazor Web Assembly / MongoDb application, it's a pet project so doesn't have to pass muster with any client requirements or existing systems etc.
Thanks for any advice/help.
Main question:
Take your typical web application with login. Does it use a database to keep track of what users are currently logged in? (As opposed to remembering all users. I'm sure you need a database for that.)
I'm just starting to learn web development, and was wondering about the real-world way to remember users as logged in, as compared to simulated examples as on this Pyramid cookbook page. I could not yet find anything about the Pyramid-way of doing this, not by searching nor in the authentication-specific tutorials. Some tutorial compare the userid against a hard-coded list, others against a not-further-specified database. The question above is my guess after reading this post on correct practices of user authentication:
If you are unfamiliar with session data, here's how it works: A single randomly-generated string is stored in an expiring cookie and used to reference a collection of data - the session data - which is stored on the server. If you are using an MVC framework, this is undoubtedly handled already.
It would be cool if someone could clear this up!
Somewhat related: This question, about the same Pyramid example - it asks how secure the method is, while my question is about understanding the method.
...and was wondering about the real-world way to remember users as
logged in.
It's not the server (or not only the server) who needs to "remember the user as logged in", it's also the client who needs to remember.
Conceptually, it works like this: upon verifying the login credentials the server returns something which the client remembers. The client then needs to send that something with every request to the server. The server, on every request, checks that the provided value is correct, matches a user in the database, etc.
In a web application, the usual mechanism to store and automatically send that "key" to the server is via HTTP Cookies - basically, the server sends a Set-Cookie header and the browser stores the cookie and sends it back in the Cookie header on every request.
Regarding the actual payload of the cookie, there are two common approaches. One option is that upon login the server starts a "session" (which may be a row in some database table). The server then returns the ID of the session, which is a random unguessable string, to the client. To check that the particular session is active the server would need to consult the database on every request.
Another option, commonly used in Pyramid tutorials, is auth_tkt authentication: the server returns a cookie containing the actual user ID, cryptographically signed with a server-side secret. When the client sends the cookie back, the server can verify the signature and be sure the cookie hasn't been tampered with. In this case, there's nothing on the server side to keep track of "all logged in users" and no need to consult the session database.
I apologies in advance - for this question needs a bit of background, which is likely to be long winded:
I'm trying to build an app which works offline with PouchDb. PouchDb will sync with Cloudant.
Technologies used:
Hapi, SQL, Vue, Cloudant, PouchDb
I have built a little hapi.js service to sign up / authenticate users. When an "account owner" signs up - they are added as a new user to a SQL database.
Using Cloudants API, I provision a new database (with a random name), and set security on the database so the new user has access.
I save the security (DB name, User name, and password) as metadata back to the user in the SQL database.
A very similar approach to here: https://www.bennadel.com/blog/3208-provisioning-cloudant-couchdb-databases-from-auth0-for-a-database-per-user-architecture-in-angular-2-4-1.htm (indeed, I based the above on this).
When the "account owner" logs in, the SQL DB is queried - the MetaData retrieved and sent down to the client side vue app. The PouchDB remote string is then populated with the Cloudant DB name, User name, and password.
eg:
const remoteDB = new PouchDB(`https://${name}:${pass}#0000-0000-bluemix.cloudant.com/${DBname}`);
This all works: PouchDB can talk to Cloudant - and data is going to and from without issue.
The "Account owner" is able to give read/write access to other people ("Staff") to their cloudantDB. When they add a new Staff Member, the Staff Member is added to the SQL DB. Using cloudants API, I create new security credentials for this user so that they can access the DB- (I do NOT create a new DB) and save them to the Staff Member in the SQL db as metadata...
The new staff member is sent an email - they set their username and password on the SQL db, and can log in. The Cloudant meta stuff is picked up... etc etc... PouchDB / Couchdb talks to each other - this also works.
Initially I was a bit concerned about sending this meta / credentials down to the client - I wanted to use a JWT or something... But then I saw this answer to another question:
https://stackoverflow.com/a/30417620/714950
So passing credentials down seems to be how its done in Pouch/Couch/Cloudant etc. I've got to be honest - I find the whole thing works like 'magic' - like its too good to be true, and that worries me a bit as I don't really understand it. I might be doing something terribly wrong.
Now for my question(s):
I'm passing these credentials down - is this safe? How would I reset / time out the username and password.
When they log out, I wipe the data from Pouch?
Can a user be 'logged in' and lose connection? Will pouch sync when they reconnect?
If pouch has NOT synced - and they log out (and I wipe Pouch) that would mean they would lose their data? so I guess I would need to persist the data in Pouch for when they log in again?
But what if they are using a shared computer? This data would be sat in Pouch DB waiting for someone to log in?
I'm also unsure how I validate the data... making sure that which gets saved to the DB is valid etc...
I suppose I'm just trying to get my head around this - I've been googling and reading everything I can, but it doesn't quite answer my questions.
Thanks
[** Just had a thought...
Thinking about it, I don't actually need to create the staff user within the SQL DB.
The Account Owner is set up - the DB is created in Cloudant, and credentials applied.
Not just had a thought: Theoretically, when a staff member is added - I only need to set them up inside Cloudant, and write their ID to the "Account Owner" as meta data so that they can be removed etc.
This way, a staff member could log in directly to the Cloudant DB.
However, I generate the security credentials using Cloudants API - so the staff member won't know what their username and password is. I don't want to send the username and password in an email.
Is there a way I can handle this? Am I able to specify a username and password when creating the security credentials? How do I handle things like password resets on cloudant?]
Thanks
I'm passing these credentials down - is this safe?
If your site is served out over HTTPS, then a bad actor would find it difficult to glean the Cloudant username & password in flight. Your client-side app needs to retain the credentials for your app to be "logged in" (for it to retain the right to sync with the server). I like to retain the data in a PouchDB document (e.g. _local/auth - local documents are not replicated so reside only on the device you create them on). You are right to be concerned, however, about having database credentials floating about on a client-side computer. Some folks decide that that is not acceptable and implement their own middle layer. If you don't need sync (that is data can be altered at both client and server side), you might use PouchDB as a buffer for unsynced data and push it to your own API when you're online. You can then control authentication, timeout and access to the database from your own server-side code.
How would I reset / time out the username and password.
You can "log out" by:
deleting your client-side state e.g. deleting the _local/auth document.
making the key/password have no permissions on the client side. Without _reader/_writer/_replicator rights, a Cloudant api key and password is useless
Alternatively you could transmit the username & password to the client which could use them against the Cloudant POST /_session endpoint which gives the web browser a time-limited cookie. Your app could then "forget" the credentials until it needs them again.
When they log out, I wipe the data from Pouch?
Yes.
Can a user be 'logged in' and lose connection? Will pouch sync when they reconnect?
If you write your client side app correctly, it could function perfectly well with its local PouchDB data, whether it has an internet connection or not. This is known as an Offline First approach. As long as your credentials are still valid, your app can sync when a connection is re-established.
If pouch has NOT synced - and they log out (and I wipe Pouch) that would mean they would lose their data?
Correct. If you have only one copy of some data and delete it, you lose data :)
But what if they are using a shared computer? This data would be sat in Pouch DB waiting for someone to log in?
Correct. On a shared computer, another user's data may be visible to the second user. Just as if I left my Facebook session logged in on a shared computer.
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.